# how to define global variable in main()

Discussion in 'C Programming' started by Davor, Jul 2, 2003.

1. ### DavorGuest

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.

Davor
Davor, Jul 2, 2003

2. ### JeffGuest

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.
>
>
> Davor
>

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

3. ### JeffGuest

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.
>>
>>

>
> 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!
Jeff, Jul 2, 2003
4. ### Neil CeruttiGuest

In article <>, 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
Neil Cerutti, Jul 2, 2003
5. ### Richard HeathfieldGuest

Richard Heathfield, Jul 2, 2003
6. ### Martin AmbuhlGuest

Davor <> wrote (02 Jul 2003) in
news: / 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
Martin Ambuhl, Jul 2, 2003
7. ### Neil CeruttiGuest

In article <bdv50m$jve$>, Richard Heathfield wrote:
> Neil Cerutti wrote:
>
><snip>
>
>> global_array = malloc(x * *global_array);

>
> ITYM
>
> global_array = malloc(x * sizeof *global_array);

Oops!

--
Neil Cerutti
Neil Cerutti, Jul 2, 2003
8. ### herculesGuest

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

"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.
>
>
> Davor
>
hercules, Jul 3, 2003
9. ### Morris DoveyGuest

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
Morris Dovey, Jul 3, 2003
10. ### Morris DoveyGuest

Martien Verbruggen wrote:
> On Wed, 02 Jul 2003 21:09:25 -0500,
> Morris Dovey <> 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

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
Morris Dovey, Jul 3, 2003
11. ### Morris DoveyGuest

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
Morris Dovey, Jul 3, 2003
12. ### Kevin EastonGuest

Morris Dovey <> 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.
Kevin Easton, Jul 3, 2003
13. ### Dan PopGuest

In <Xns93AC83477812mambuhlearthlinknet@207.217.77.23> Martin Ambuhl <> 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:
Dan Pop, Jul 3, 2003
14. ### Martien VerbruggenGuest

On 3 Jul 2003 11:04:10 GMT,
Dan Pop <> wrote:
> In <> Morris Dovey <> 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
>>
>>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.
|
Martien Verbruggen, Jul 4, 2003
15. ### Morris DoveyGuest

Dan Pop wrote:
> In <> Morris Dovey <> writes:
>
>
>>Martien Verbruggen wrote:
>>
>>>On Wed, 02 Jul 2003 21:09:25 -0500,
>>> Morris Dovey <> 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
>>
>>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
Morris Dovey, Jul 4, 2003
16. ### Morris DoveyGuest

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
Morris Dovey, Jul 4, 2003
17. ### Morris DoveyGuest

Mark McIntyre wrote:
> On Thu, 03 Jul 2003 21:26:08 -0500, in comp.lang.c , Morris Dovey
> <> 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 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
Morris Dovey, Jul 5, 2003
18. ### Mark McIntyreGuest

On Sat, 05 Jul 2003 08:13:29 -0500, in comp.lang.c , Morris Dovey
<> 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>