how to define global variable in main()

[Davor]

How to define global variable in main()?
I'm asking because I have an array in main, whose size is determined by
input, so the definition has to be in main ( or in some other funcion ).
And I need to use that array in my other functions, so I want it to be
global. I tryed using extern keyword, but I gut some error, so I supose
that's not it.
thanks in advance
Davor :-)

[Jeff]

Davor wrote:

How to define global variable in main()?
I'm asking because I have an array in main, whose size is determined by
input, so the definition has to be in main ( or in some other funcion ).
And I need to use that array in my other functions, so I want it to be
global. I tryed using extern keyword, but I gut some error, so I supose
that's not it.
thanks in advance
Davor :-)

Is there a reason why you don't just past that array to every function
that needs to access it?

[Jeff]

Jeff wrote:

Davor wrote:

How to define global variable in main()?
I'm asking because I have an array in main, whose size is determined
by input, so the definition has to be in main ( or in some other
funcion ). And I need to use that array in my other functions, so I
want it to be global. I tryed using extern keyword, but I gut some
error, so I supose that's not it.

thanks in advance Davor :-)

Is there a reason why you don't just past that array to every function
that needs to access it?

s/past/pass/g

Ugh!

[Neil Cerutti]

In article <3F************@yahoo.com>, Davor wrote:

How to define global variable in main()? I'm asking because I
have an array in main, whose size is determined by input, so
the definition has to be in main ( or in some other funcion ).
And I need to use that array in my other functions, so I want
it to be global. I tryed using extern keyword, but I gut some
error, so I supose that's not it.

#include <stdlib.h>

int *global_array;

int get_user_input(void);
void go(void);

int main(void)
{
int x = get_user_input();
global_array = malloc(x * *global_array);
if (global_array != 0) {
go();
}
return 0;
}
/* etc... */

--
Neil Cerutti

[Richard Heathfield]

Neil Cerutti wrote:

<snip>

global_array = malloc(x * *global_array);

ITYM

global_array = malloc(x * sizeof *global_array);

<snip>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Martin Ambuhl]

Davor <da*********@yahoo.com> wrote (02 Jul 2003) in
news:3F************@yahoo.com / comp.lang.c:

How to define global variable in main()?
main() is a function. Any variable declared in main will have block
scope. Variables with file scope and external linkage should be
declared *outside* of any function.
I'm asking because I have an array in main, whose size is determined
by input, so the definition has to be in main ( or in some other
funcion ).
Not true. A pointer can be declared outside a function, as can a
variable holding size information. The allocation occurs in a function,
but so what?
And I need to use that array in my other functions, so I want it to be
global.

If you have a good reason to avoid passing the array name as an
argument, then declare it as file scope. Try to avoid the word
"global", since it could have several meanings. Use the words for which
there is a clear meaning in C (scope, linkage, duration).

--
Martin Ambuhl
Returning soon to the
Fourth Largest City in America

[Neil Cerutti]

In article <bd**********@hercules.btinternet.com>, Richard Heathfield wrote:

Neil Cerutti wrote:

<snip>

global_array = malloc(x * *global_array);

ITYM

global_array = malloc(x * sizeof *global_array);

Oops!

--
Neil Cerutti

[hercules]

The size of an array must be determined at compliled session!
it can't be determined at running session!

"Davor" <da*********@yahoo.com> ??????:3F************@yahoo.com...

How to define global variable in main()?
I'm asking because I have an array in main, whose size is determined by
input, so the definition has to be in main ( or in some other funcion ).
And I need to use that array in my other functions, so I want it to be
global. I tryed using extern keyword, but I gut some error, so I supose
that's not it.
thanks in advance
Davor :-)

[Morris Dovey]

hercules wrote:

The size of an array must be determined at compliled session!
it can't be determined at running session!

Hercules...

Not true. See http://www.iedu.com/mrd/c/tokenize.c for an
example; then see http://www.iedu.com/mrd/c/tokfile.c for an
example (that uses the code from the first example) that
dynamically produces an array of pointers to dynamically produced
arrays.

Neither of these pieces of code know the size of the arrays being
produced until discovering that the final element has been
processed - at which time the memory for the entire array is
allocated and the element values stored.

Both sources contain a short test program with which you're
welcome to play to convince yourself that it really does work as
I describe. :)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Morris Dovey]

Martien Verbruggen wrote:

On Wed, 02 Jul 2003 21:09:25 -0500,
Morris Dovey <mr*****@iedu.com> wrote:

hercules wrote:

The size of an array must be determined at compliled session!
it can't be determined at running session!

Hercules...

Not true. See http://www.iedu.com/mrd/c/tokenize.c for an

\begin{pedantry}

There are no arrays in that program. There are pointers and
allocations with malloc, but that doesn't make an array.

\end{pedantry}

I suspect that hercules was talking about real arrays, and in c89 the
size of those does need to be known at compile time.

(more pedantic 8-)

C99: 7.20.3.1

"The order and contiguity of storage allocated by successive
calls to the calloc, malloc, and realloc functions is
unspecified. The pointer returned if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any
type of object and then used to access such an object or an array
of such objects in the space allocated (until the space is
explicitly deallocated)." [remainder of paragraph dropped]

(less pedantic)

Looks like an array to me.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Morris Dovey]

E. Robert Tisdale wrote:

Don't do that. Instead, do something like this: #endif//GUARD_RAMP_H

But not exactly like that. C99:6.10 specifies a syntax requiring
that #endif be followed by the new-line character.

While it's true that at least some implementations don't issue
diagnostics for intervening comments; it's probably not in the
OP's best interest to be given examples with syntax errors.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Kevin Easton]

Morris Dovey <mr*****@iedu.com> wrote:

E. Robert Tisdale wrote:

Don't do that. Instead, do something like this:

#endif//GUARD_RAMP_H

But not exactly like that. C99:6.10 specifies a syntax requiring
that #endif be followed by the new-line character.

6.10 applies in translation phase 4 - comments are replaced by single
spaces in translation phase 3, and 6.10 allows space and horizontal-tab
characters between preprocessing tokens (in this case, between endif and
new-line).
While it's true that at least some implementations don't issue
diagnostics for intervening comments; it's probably not in the
OP's best interest to be given examples with syntax errors.

I suspect you are thinking of the older practice of

#endif TEXT_HERE_NOT_COMMENTED

- Kevin.

[Dan Pop]

In <Xn********************************@207.217.77.2 3> Martin Ambuhl <ma*****@earthlink.net> writes:

argument, then declare it as file scope. Try to avoid the word
"global", since it could have several meanings. Use the words for which
there is a clear meaning in C (scope, linkage, duration).

Most of the time, we can figure out what a newbie means by "global",
but most newbies don't have the slightest clue about the clear meaning
of "scope, linkage, duration" in C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Martien Verbruggen]

On 3 Jul 2003 11:04:10 GMT,
Dan Pop <Da*****@cern.ch> wrote:

In <3F**************@iedu.com> Morris Dovey <mr*****@iedu.com> writes:

Martien Verbruggen wrote:
[in response to link to code posted, with reference to arrays]

\begin{pedantry}

There are no arrays in that program. There are pointers and
allocations with malloc, but that doesn't make an array.

\end{pedantry}

(more pedantic 8-)

C99: 7.20.3.1

"The order and contiguity of storage allocated by successive
calls to the calloc, malloc, and realloc functions is
unspecified. The pointer returned if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any
type of object and then used to access such an object or an array
of such objects in the space allocated (until the space is
explicitly deallocated)." [remainder of paragraph dropped]

(less pedantic)

Looks like an array to me.
Nope, Martien is right. Look up the definition of "array type":

[snip]
OTOH, the standard is loosely using the term "array", so both parties can
invoke their arguments.

I came to the same conclusion when I started rereading the standard
(C99). While array type is precisely defined, the term array is used
much more fuzzily. That's when I decided I'd wait until someone else
voiced an opinion on the matter.

I was obviously thinking of the strictly defined "array type", while
Morris was thinking of the more fuzzy "array".

Martien
--
|
Martien Verbruggen | Make it idiot proof and someone will make a
Trading Post Australia | better idiot.
|

[Morris Dovey]

Dan Pop wrote:

In <3F**************@iedu.com> Morris Dovey <mr*****@iedu.com> writes:

Martien Verbruggen wrote:

On Wed, 02 Jul 2003 21:09:25 -0500,
Morris Dovey <mr*****@iedu.com> wrote:
hercules wrote:
>The size of an array must be determined at compliled session!
>it can't be determined at running session!

Hercules...

Not true. See http://www.iedu.com/mrd/c/tokenize.c for an
\begin{pedantry}

There are no arrays in that program. There are pointers and
allocations with malloc, but that doesn't make an array.

\end{pedantry}

I suspect that hercules was talking about real arrays, and in c89 the
size of those does need to be known at compile time.

(more pedantic 8-)

C99: 7.20.3.1

"The order and contiguity of storage allocated by successive
calls to the calloc, malloc, and realloc functions is
unspecified. The pointer returned if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any
type of object and then used to access such an object or an array
of such objects in the space allocated (until the space is
explicitly deallocated)." [remainder of paragraph dropped]

(less pedantic)

Looks like an array to me.

Nope, Martien is right. Look up the definition of "array type":

* An array type describes a contiguously allocated set of objects
with a particular member object type, called the element type. Array
types are characterized by their element type and by the number of
members of the array. ^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^
Ignoring C99 VLAs, if you don't know the number of members of the array,
you can't have a (complete) array type.

OTOH, the standard is loosely using the term "array", so both parties can
invoke their arguments.

Hmm. I hardly ever malloc space for an array without knowing the
number of members.

I guess I just don't do pedantic very well (although I'm pleased
to report that the code is highly portable and seems to function
as intended); and that I find it helpful to think of the mallc'd
region as an array. It doesn't bother me that the number of
members wasn't known at compile time and that the size needed to
be "discovered" during execution.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Morris Dovey]

Mark McIntyre wrote:

<mode pedantic = extreme>
It may smell like an array, and it may even look like one, but it
aint.

6.2.5(20)
.... Array types are characterized by their element type and by the
number of elements in the array....

The object returned by *alloc has neither of these characteristics.

</mode>

In static char *chars(void), n is an unsigned int used to count
characters, and x is a pointer to char. When the function has
found all of the characters in a word, it does:

x = malloc((n+1) * sizeof(char));

Assuming the allocation succeeds (and assuming the programmer
isn't spoofing anywhere), x now points to an array of n+1 members
of type char. Using "sizeof(char)" in the expression wasn't
necessary, but was intended to emphasize the element type.

The following statement

x[n] = '\0';

emphasizes the array nature of x. I could have written

*(x+n) = '\0';

to de-emphasize x's array nature.

In the function static char **words(void), n is an unsigned int
used to count the words (NUL-terminated arrays of type char)
produced by chars(); and x is a pointer to pointer(s) to chars.
When the function has found all of the words in a line, it does

x = malloc((n+1) * sizeof(char *));

Again, assuming the allocation succeeds, x points to an array of
pointers to words. The following statement,

x[n] = NULL;

emphasizes the array nature of x. I would have coded

*(x+n) = NULL;

if I'd wanted to downplay the array aspect.

In both functions, the number and type of members /is/ known. The
type is known (and specified) at compile time; and the number is
determined at execution time.

If we decide that in order for there to be an array, we must
inform the compiler of the number of elements, then there is a
great deal of corrective work to be done on the standard; and we
should probably drop all references to VLAs. I'm of the opinion
that while the number of elements does need to be known, it
doesn't need to be known at compile time.

BTW, Mark, have you completed your relocation? (Sorry I couldn't
contribute a bottle of wine for your housewarming!)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Morris Dovey]

Mark McIntyre wrote:

On Thu, 03 Jul 2003 21:26:08 -0500, in comp.lang.c , Morris Dovey
<mr*****@iedu.com> wrote:

Mark McIntyre wrote:

6.2.5(20)
.... Array types are characterized by their element type
and by the number of elements in the array....

The object returned by *alloc has neither of these characteristics.
x = malloc((n+1) * sizeof(char));

Assuming the allocation succeeds (and assuming the
programmer isn't spoofing anywhere), x now points to an
array of n+1 members of type char.

My problem is that x knows neither the type of the element,
nor the number of them.

Not sure how you can say that, given that x was declared and
defined as a pointer to char (so that both programmer and
compiler know the type of the element); and the exact number of
elements (known to the program, if not the compiler) is specified
in the malloc call.

The following statement

x[n] = '\0';

emphasizes the array nature of x.

Well I reckon it emphasises that the C standard requires
malloc to give the appearance that it contiguously allocated
memory, so that you can by good fortune use array style
notation on such memory blocks !!

It's hardly a matter of good fortune. It's the straightforeward
application of the C language's array access mechanism; where
a[i] is defined as equivalent to *(a + i). The pointer returned
by malloc is /required/ to be suitable for use as a pointer to
the array of char.

In both functions, the number and type of members /is/ known.

By you, yes, Not by the compiler tho. Pass that "array" to another
function, wrapped in a struct to preserve its array-ness, and you
don't also pass over its size.

True - but where in the standard is this specific behavior
required for dynamically allocated objects? It's not news that
it's inappropriate to, for example, apply /sizeof/ to them. As we
tell the newbies (again and again): "It's the programmer's
responsibility to remember."
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Mark McIntyre]

On Sat, 05 Jul 2003 08:13:29 -0500, in comp.lang.c , Morris Dovey
<mr*****@iedu.com> wrote:

My problem is that x knows neither the type of the element,
nor the number of them.
Not sure how you can say that, given that x was declared and
defined as a pointer to char (so that both programmer and
compiler know the type of the element);

we know that the variable is a pointer to a char. But it doesn't have
any elements (since its not an array), so we can't know the type of
them... *
and the exact number of
elements (known to the program, if not the compiler) is specified
in the malloc call.

but x doesn't cart that info around with it.

// the 12 is part of the definition of x
double x[12];

// not only is the 12 not part of x, but its wrong
double *x = malloc(12 * sizeof (int));

(yes, yes, I know the common CLC idiom, and agree with it)

* this is either tautology or psephology, I forget which... :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---