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]

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]

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]

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

 

[Richard Heathfield]

Neil Cerutti wrote:

global_array = malloc(x * *global_array);

ITYM

global_array = malloc(x * sizeof *global_array);

<snip>

 

[Martin Ambuhl]

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

 

[Neil Cerutti]

Neil Cerutti wrote:



ITYM

global_array = malloc(x * sizeof *global_array);

Oops!

 

[hercules]

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

 

[Morris Dovey]

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]

\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]

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.

 

[Kevin Easton]

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]

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

 

[Martien Verbruggen]

[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

 

[Morris Dovey]

On Wed, 02 Jul 2003 21:09:25 -0500,


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]

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

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.

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

 

[Mark McIntyre]

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