Initial values of File scoped and Block level variables

Discussion in 'C Programming' started by Madhav, Jan 6, 2006.

  1. Madhav

    Madhav Guest

    Hi all,

    I did not understand why do the global vars are
    initialized to NULL where as the block level variables have random
    values? I know that the C standard requires this as was mentioned in a
    recent thread.

    I want to know why this descrimination is in place. Can't all the
    variables be initialised to NULL automatically by the compiler? This
    would make programming a little easier.

    Regards,
    Madhav.
    Madhav, Jan 6, 2006
    #1
    1. Advertising

  2. Madhav

    Guest

    Madhav <> wrote:
    > I did not understand why do the global vars are
    > initialized to NULL where as the block level variables have random
    > values? I know that the C standard requires this as was mentioned in a
    > recent thread.
    >
    > I want to know why this descrimination is in place. Can't all the
    > variables be initialised to NULL automatically by the compiler? This
    > would make programming a little easier.


    No, the data for automatic variables can not be initialized to NULL by
    the compiler.

    Before main() is called, a system-specific piece of code runs, which
    prepares the environment for your C program to run in. One of it's tasks
    is to clear the .bss section, e.g. setting all global and static
    variables to zero.

    Automatic variables are allocated on the stack, and do not have a fixed
    address. The same memory locations will often be re-used when entering
    and leaving functions. To clean all automatic variables every time a
    function or block is entered, your compiler would have to insert a piece
    of code at the beginning of *every function* to do that.

    --
    :wq
    ^X^Cy^K^X^C^C^C^C
    , Jan 6, 2006
    #2
    1. Advertising

  3. Madhav said:

    > Hi all,
    >
    > I did not understand why do the global vars are
    > initialized to NULL where as the block level variables have random
    > values? I know that the C standard requires this as was mentioned in a
    > recent thread.


    The Standard requires that all static and file scope objects that are not
    explicitly initialised by the program are given default static initialiser
    values, viz. 0, 0.0, NULL (recursively for aggregates).

    The Standard makes no such demands for automatic objects, except in the case
    of partial initialisation of aggregate objects (where the partial
    initialisation is honoured, and the rest of the object initialised as
    mentioned earlier).

    > I want to know why this descrimination is in place.


    I don't know why statics and file scope objects get a default
    initialisation. I know why automatics don't. It's a programmer choice. If
    the programmer wishes the program to spend time assigning 0-values to
    automatic objects, the programmer can choose that behaviour by writing:

    int i = 0;

    and if he doesn't wish that, he can simply write:

    int i;

    which indicates that, at this stage, he isn't fussed about i's value.

    > Can't all the
    > variables be initialised to NULL automatically by the compiler?


    Yes, a compiler is free to do that if it wishes (NULL for pointers, 0 for
    integers, 0.0 for floating point numbers, and the obvious for structs,
    unions, and arrays), but it is not /required/ to do that.

    > This would make programming a little easier.


    I'm tempted to agree, but it would diminish programmer choice. I like my
    objects to start off with known values, in the interests of determinism, so
    your proposal would suit my style of programming. But other programmers
    prefer it the way it is now, and whilst it is possible for me to get the
    effect I want by taking the current strategy and adding code (typically as
    simple as = {0} in my case), the reverse would not be true.

    I am not (yet) so monumentally egomaniacal as to insist that every C
    compiler writer in the world should change their product just to suit my
    coding style. But I'm working on it.


    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jan 6, 2006
    #3
  4. said:

    > No, the data for automatic variables can not be initialized to NULL by
    > the compiler.


    Not so. They could be. They just aren't.

    > Automatic variables are allocated on the stack, and do not have a fixed
    > address. The same memory locations will often be re-used when entering
    > and leaving functions. To clean all automatic variables every time a
    > function or block is entered, your compiler would have to insert a piece
    > of code at the beginning of *every function* to do that.


    See? I told you it was possible!

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jan 6, 2006
    #4
  5. Richard Heathfield <> wrote:

    [snip discussion about initialization of automatic variables]

    > I'm tempted to agree, but it would diminish programmer choice.


    I don't want to be too broad, but I think programmer choice is one of
    the central qualities that endears C to those who use it. I imagine
    that programmers for embedded platforms are in any case perfectly happy
    to go on exercising their freedom of choice in this area, given that
    not every environment has the luxury of CPU cycles to burn.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Jan 6, 2006
    #5
  6. Christopher Benson-Manica said:

    > Richard Heathfield <> wrote:
    >
    > [snip discussion about initialization of automatic variables]
    >
    >> I'm tempted to agree, but it would diminish programmer choice.

    >
    > I don't want to be too broad, but I think programmer choice is one of
    > the central qualities that endears C to those who use it.


    Hence the "but".

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jan 6, 2006
    #6
  7. Madhav

    tmp123 Guest

    Madhav wrote:
    > Hi all,
    >
    > I did not understand why do the global vars are
    > initialized to NULL where as the block level variables have random
    > values? I know that the C standard requires this as was mentioned in a
    > recent thread.
    >
    > I want to know why this descrimination is in place. Can't all the
    > variables be initialised to NULL automatically by the compiler? This
    > would make programming a little easier.
    >
    > Regards,
    > Madhav.


    Probably, the origin was only a speed problem. Init the globals at
    start of program is not very expensive, just a fill with 0 (at start of
    program lots of things are done).
    However, init locals each time a function call is done means an
    important overwork, not necessary most part of time.

    Kind regards.

    PS: In some places, a trick is used:
    - at first testing stages the globals, stack ... are filled not with
    cero but with a very strange value, like H'C5. Reason: if something has
    not been init, better to crash as soon as possible, to detect and fix.
    - at final version, init is done with cero for the oposite reason.
    tmp123, Jan 6, 2006
    #7
  8. writes:
    > Madhav <> wrote:
    >> I did not understand why do the global vars are
    >> initialized to NULL where as the block level variables have random
    >> values? I know that the C standard requires this as was mentioned in a
    >> recent thread.
    >>
    >> I want to know why this descrimination is in place. Can't all the
    >> variables be initialised to NULL automatically by the compiler? This
    >> would make programming a little easier.

    >
    > No, the data for automatic variables can not be initialized to NULL by
    > the compiler.


    It certainly could be. In fact, a compiler that did so would be
    perfectly legal (but it would encourage lazy programmers to depend on
    its behavior).

    > Before main() is called, a system-specific piece of code runs, which
    > prepares the environment for your C program to run in. One of it's tasks
    > is to clear the .bss section, e.g. setting all global and static
    > variables to zero.
    >
    > Automatic variables are allocated on the stack, and do not have a fixed
    > address. The same memory locations will often be re-used when entering
    > and leaving functions. To clean all automatic variables every time a
    > function or block is entered, your compiler would have to insert a piece
    > of code at the beginning of *every function* to do that.


    As far as the C language is concerned, there's no such thing as a
    ".bss section", or even a "stack"; they're just particular ways to
    implement the semantics required for the language. (Automatic
    variables are allocated in a stack-like last-in/first-out fashion, but
    there are ways to implement that other than a contiguous linear stack
    in memory.)

    But I believe the motivation for implicitly initializing global
    variables but not automatic variables is based on the kind of
    implementation details you're talking about. Global variables are
    initialized to 0 converted to the appropriate type; that could be 0,
    0L, '\0', 0.0, NULL, etc. In many (most?) implementations, all those
    values are represented as all-bits-zero, making it easy to initialize
    all the globals by zeroing a contiguous block of memory when the
    program is loaded. (If a NULL pointer or a floating-point 0.0 isn't
    represented as all-bits-zero, the implementation has to go to some
    extra effort, but it already has to handle explicit initializations to
    non-zero values anyway.)

    Initializing local variables, as you point out, would require some
    extra work. The burden on the compiler would be fairly trivial, but
    the cost at run-time could be significant -- and it would typically
    have been even more significant back when the language was being
    designed.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 6, 2006
    #8
  9. Madhav

    jacob navia Guest

    Richard Heathfield a écrit :
    > said:
    >
    >
    >>No, the data for automatic variables can not be initialized to NULL by
    >>the compiler.

    >
    >
    > Not so. They could be. They just aren't.
    >
    >
    >>Automatic variables are allocated on the stack, and do not have a fixed
    >>address. The same memory locations will often be re-used when entering
    >>and leaving functions. To clean all automatic variables every time a
    >>function or block is entered, your compiler would have to insert a piece
    >>of code at the beginning of *every function* to do that.

    >
    >
    > See? I told you it was possible!
    >


    The lcc-win32 compiler will init all locals to zero when
    called with:
    lcc -stackinit 0

    By default, lcc-win32 initializes all stack to
    0xFFFA5A5A
    This provokes many program that use uninitialized variables and run
    with other compilers to break down with lcc-win32, what has led
    to MANY false bug reports.

    Still I think this is worth doing.

    jacob
    jacob navia, Jan 6, 2006
    #9
  10. Madhav

    jacob navia Guest

    tmp123 a écrit :
    > Madhav wrote:
    >
    >>Hi all,
    >>
    >> I did not understand why do the global vars are
    >>initialized to NULL where as the block level variables have random
    >>values? I know that the C standard requires this as was mentioned in a
    >>recent thread.
    >>
    >> I want to know why this descrimination is in place. Can't all the
    >>variables be initialised to NULL automatically by the compiler? This
    >>would make programming a little easier.
    >>
    >>Regards,
    >>Madhav.

    >
    >
    > Probably, the origin was only a speed problem. Init the globals at
    > start of program is not very expensive, just a fill with 0 (at start of
    > program lots of things are done).
    > However, init locals each time a function call is done means an
    > important overwork, not necessary most part of time.
    >
    > Kind regards.
    >
    > PS: In some places, a trick is used:
    > - at first testing stages the globals, stack ... are filled not with
    > cero but with a very strange value, like H'C5. Reason: if something has
    > not been init, better to crash as soon as possible, to detect and fix.
    > - at final version, init is done with cero for the oposite reason.
    >


    lcc-win32 will initialize the stack to
    0xFFFA5A5A
    This is a nan, and provokes crashes when used as a pointer.
    If you want another value (include zero)
    you call it with
    lcc -stackinit 0

    jacob
    jacob navia, Jan 6, 2006
    #10
  11. Madhav

    Default User Guest

    Keith Thompson wrote:

    > writes:
    > > Madhav <> wrote:
    > >> I did not understand why do the global vars are
    > >> initialized to NULL where as the block level variables have random
    > >> values? I know that the C standard requires this as was mentioned

    > in a >> recent thread.
    > >>
    > >> I want to know why this descrimination is in place. Can't all

    > the >> variables be initialised to NULL automatically by the
    > compiler? This >> would make programming a little easier.
    > >
    > > No, the data for automatic variables can not be initialized to NULL
    > > by the compiler.

    >
    > It certainly could be. In fact, a compiler that did so would be
    > perfectly legal (but it would encourage lazy programmers to depend on
    > its behavior).




    Some compilers do so, in some modes, notably debug mode. This leads to
    the complaint seen sometimes, "my program runs fine in debug mode, but
    crashes when I compile in release mode!!!!"




    Brian
    Default User, Jan 6, 2006
    #11
  12. "Default User" <> writes:

    > Keith Thompson wrote:
    >
    >> writes:
    >> > Madhav <> wrote:
    >> >> I did not understand why do the global vars are
    >> >> initialized to NULL where as the block level variables have random
    >> >> values? I know that the C standard requires this as was mentioned

    >> in a >> recent thread.
    >> >>
    >> >> I want to know why this descrimination is in place. Can't all

    >> the >> variables be initialised to NULL automatically by the
    >> compiler? This >> would make programming a little easier.
    >> >
    >> > No, the data for automatic variables can not be initialized to NULL
    >> > by the compiler.

    >>
    >> It certainly could be. In fact, a compiler that did so would be
    >> perfectly legal (but it would encourage lazy programmers to depend on
    >> its behavior).

    >
    >
    >
    > Some compilers do so, in some modes, notably debug mode. This leads to
    > the complaint seen sometimes, "my program runs fine in debug mode, but
    > crashes when I compile in release mode!!!!"


    Or they can initialise to a deliberately large non-zero value so as to
    more likely provoke an obvious failure.

    --

    John Devereux
    John Devereux, Jan 7, 2006
    #12
  13. Madhav wrote:
    > Hi all,
    >
    > I did not understand why do the global vars are
    > initialized to NULL where as the block level variables have random
    > values? I know that the C standard requires this as was mentioned in a
    > recent thread.
    >
    > I want to know why this descrimination is in place. Can't all the
    > variables be initialised to NULL automatically by the compiler? This
    > would make programming a little easier.
    >
    > Regards,
    > Madhav.
    >


    Technically, global variables are not "initialized" by the compiler. Program
    globals, data segment, variables are either initialized by the programmer, or
    by the program loader as it is copied into ram and it's code/data space is
    allocated.

    There are two exceptions, partially initialized structures and arrays.

    For example the compiler will add the initialized data to the program machine
    code image emitted to disk padding with NULL all elements you do NOT
    initialize in source code.

    struct {
    int ii;
    long ll;
    char a[32];
    } gvar = { 1 };

    In the above, ii will be set to (int)1, with ll and a[] set to NULL.

    char a[32] = "hi";

    In the above, a[0] = 'h' a[1] = 'i' and a[2-31] == 0

    For uninitialized global variables, the loader(LD) allocates data segment
    memory using calloc() which does the "initialization" to NULL for all
    elements, and only a reference to type of memory and how many elements are
    needed are emitted to the machine code image emitted to disk by the compiler.

    So ...

    struct {
    int ii;
    long ll;
    char a[32];
    } gvar;

    creates an entry in the disk program image that the compiler emits to disk
    that informs the loader to allocate 1 element of sizeof(gvar) memory.

    Memory "allocated" between braces "{}" is actually stack memory which retains
    the data from the last function to use that stack memory. This memory
    can/will change from call to call being altered by the "other" functions that
    are called in between.

    For the "compiler" to accomplish what you perceive as a failing, it will need
    to insert machine code that runs BEFORE your code does to initialize the
    variables declared. This extra code will consume time and may not be needed
    if your code simply assigns a value prior to use, such as the initialization
    in a for(;;) loop.

    Joseph
    Joseph Dionne, Jan 7, 2006
    #13
  14. Joseph Dionne <> writes:
    > Madhav wrote:
    >> Hi all,
    >> I did not understand why do the global vars are
    >> initialized to NULL where as the block level variables have random
    >> values? I know that the C standard requires this as was mentioned in a
    >> recent thread.
    >> I want to know why this descrimination is in place. Can't all
    >> the
    >> variables be initialised to NULL automatically by the compiler? This
    >> would make programming a little easier.

    >
    > Technically, global variables are not "initialized" by the compiler.
    > Program globals, data segment, variables are either initialized by the
    > programmer, or by the program loader as it is copied into ram and it's
    > code/data space is allocated.


    Technically, global variables are implicitly initialized; the
    implementation (of which the compiler is a part) can accomplish this
    in any convenient manner. Data segments and program loaders are
    implementation details that may be used to implement the semantics
    required by the language; they're outside the scope of the langauge
    and of this newsgroup.

    > There are two exceptions, partially initialized structures and arrays.
    >
    > For example the compiler will add the initialized data to the program
    > machine code image emitted to disk padding with NULL all elements you
    > do NOT initialize in source code.
    >
    > struct {
    > int ii;
    > long ll;
    > char a[32];
    > } gvar = { 1 };


    NULL is a macro that expands to a null pointer constant; it doesn't
    apply to non-pointer types.

    > In the above, ii will be set to (int)1, with ll and a[] set to NULL.


    No, ll will be set to 0L, and each element of a will be set to '\0'
    (more generally, to zero converted to the appropriate type).

    > char a[32] = "hi";
    >
    > In the above, a[0] = 'h' a[1] = 'i' and a[2-31] == 0
    >
    > For uninitialized global variables, the loader(LD) allocates data
    > segment memory using calloc() which does the "initialization" to NULL
    > for all elements, and only a reference to type of memory and how many
    > elements are needed are emitted to the machine code image emitted to
    > disk by the compiler.


    An implementation could use calloc() to initialize globals that aren't
    initialized explicitly, but only for types where zero (or 0.0, or a
    null pointer value) is represented as all-bits-zero. Also, it's
    unlikely that an implementation would use either calloc() or malloc()
    to allocate the space used for global variables, though I suppose it's
    possible. (The "heap" is typically distinct from the memory space
    used for global and static variables.)

    > So ...
    >
    > struct {
    > int ii;
    > long ll;
    > char a[32];
    > } gvar;
    >
    > creates an entry in the disk program image that the compiler emits to
    > disk that informs the loader to allocate 1 element of sizeof(gvar)
    > memory.


    Maybe. There may not be a disk at all.

    > Memory "allocated" between braces "{}" is actually stack memory which
    > retains the data from the last function to use that stack memory.
    > This memory can/will change from call to call being altered by the
    > "other" functions that are called in between.


    A stack (in the sense of a contiguously allocated region of memory
    that grows and shrinks linearly, typically with a CPU register
    dedicated as a top-of-stack pointer) is one way to implement automatic
    variables. It's not the only way. I don't believe the word "stack
    even appears in the standard.

    [snip]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 7, 2006
    #14
  15. Keith Thompson wrote:
    > Joseph Dionne <> writes:
    >
    >>Madhav wrote:
    >>
    >>>Hi all,
    >>> I did not understand why do the global vars are
    >>>initialized to NULL where as the block level variables have random
    >>>values? I know that the C standard requires this as was mentioned in a
    >>>recent thread.
    >>> I want to know why this descrimination is in place. Can't all
    >>>the
    >>>variables be initialised to NULL automatically by the compiler? This
    >>>would make programming a little easier.

    >>
    >>Technically, global variables are not "initialized" by the compiler.
    >>Program globals, data segment, variables are either initialized by the
    >>programmer, or by the program loader as it is copied into ram and it's
    >>code/data space is allocated.

    >
    >
    > Technically, global variables are implicitly initialized; the
    > implementation (of which the compiler is a part) can accomplish this
    > in any convenient manner. Data segments and program loaders are
    > implementation details that may be used to implement the semantics
    > required by the language; they're outside the scope of the langauge
    > and of this newsgroup.
    >


    Now you are just being flippant. This group is for discussing c language
    programming, and what a compiler does to create the executable object is
    pertinent to the OP's post. As I read what he "thought" should happen would
    not be a function of compilation, but a feature added in 4th generation languages.

    C is considered a 3rd generation, however IMHO it is more like a 2.5
    generation language because reserved words of c translate one to one to
    assembler instructions, with few exceptions.

    The "advantages" of c standard libraries make it easier for one to write
    software, but one could write their own function libraries in the c lexicon
    without third party libraries, providing they had an expert understanding of
    the target hardware.

    >
    >>There are two exceptions, partially initialized structures and arrays.
    >>
    >>For example the compiler will add the initialized data to the program
    >>machine code image emitted to disk padding with NULL all elements you
    >>do NOT initialize in source code.
    >>
    >>struct {
    >> int ii;
    >> long ll;
    >> char a[32];
    >>} gvar = { 1 };

    >
    >
    > NULL is a macro that expands to a null pointer constant; it doesn't
    > apply to non-pointer types.
    >
    >


    NULL is "#define NULL 0" in every c compiler I have used, and I code regularly
    on ten different *nix operating systems. NULL, the macro, is neither a
    "pointer," int, long, or char, but can be assigned to all.


    >>In the above, ii will be set to (int)1, with ll and a[] set to NULL.

    >
    >
    > No, ll will be set to 0L, and each element of a will be set to '\0'
    > (more generally, to zero converted to the appropriate type).
    >
    >


    You say potato, I say NULL -- most c developers think zero when reading NULL.

    >>char a[32] = "hi";
    >>
    >>In the above, a[0] = 'h' a[1] = 'i' and a[2-31] == 0
    >>
    >>For uninitialized global variables, the loader(LD) allocates data
    >>segment memory using calloc() which does the "initialization" to NULL
    >>for all elements, and only a reference to type of memory and how many
    >>elements are needed are emitted to the machine code image emitted to
    >>disk by the compiler.

    >
    >
    > An implementation could use calloc() to initialize globals that aren't
    > initialized explicitly, but only for types where zero (or 0.0, or a
    > null pointer value) is represented as all-bits-zero. Also, it's
    > unlikely that an implementation would use either calloc() or malloc()
    > to allocate the space used for global variables, though I suppose it's
    > possible. (The "heap" is typically distinct from the memory space
    > used for global and static variables.)
    >
    >
    >>So ...
    >>
    >>struct {
    >> int ii;
    >> long ll;
    >> char a[32];
    >>} gvar;
    >>
    >>creates an entry in the disk program image that the compiler emits to
    >>disk that informs the loader to allocate 1 element of sizeof(gvar)
    >>memory.

    >
    >
    > Maybe. There may not be a disk at all.
    >
    >
    >>Memory "allocated" between braces "{}" is actually stack memory which
    >>retains the data from the last function to use that stack memory.
    >>This memory can/will change from call to call being altered by the
    >>"other" functions that are called in between.

    >
    >
    > A stack (in the sense of a contiguously allocated region of memory
    > that grows and shrinks linearly, typically with a CPU register
    > dedicated as a top-of-stack pointer) is one way to implement automatic
    > variables. It's not the only way. I don't believe the word "stack
    > even appears in the standard.
    >
    > [snip]
    >
    Joseph Dionne, Jan 7, 2006
    #15
  16. Madhav

    Jordan Abel Guest

    On 2006-01-07, Joseph Dionne <> wrote:
    > Keith Thompson wrote:
    >> Joseph Dionne <> writes:
    >>
    >>>Madhav wrote:
    >>>
    >>>>Hi all,
    >>>> I did not understand why do the global vars are
    >>>>initialized to NULL where as the block level variables have random
    >>>>values? I know that the C standard requires this as was mentioned in a
    >>>>recent thread.
    >>>> I want to know why this descrimination is in place. Can't all
    >>>>the
    >>>>variables be initialised to NULL automatically by the compiler? This
    >>>>would make programming a little easier.
    >>>
    >>>Technically, global variables are not "initialized" by the compiler.
    >>>Program globals, data segment, variables are either initialized by the
    >>>programmer, or by the program loader as it is copied into ram and it's
    >>>code/data space is allocated.

    >>
    >>
    >> Technically, global variables are implicitly initialized; the
    >> implementation (of which the compiler is a part) can accomplish this
    >> in any convenient manner. Data segments and program loaders are
    >> implementation details that may be used to implement the semantics
    >> required by the language; they're outside the scope of the langauge
    >> and of this newsgroup.
    >>

    >
    > Now you are just being flippant. This group is for discussing c
    > language programming, and what a compiler does to create the
    > executable object is pertinent to the OP's post. As I read what he
    > "thought" should happen would not be a function of compilation, but a
    > feature added in 4th generation languages.
    >
    > C is considered a 3rd generation, however IMHO it is more like a 2.5
    > generation language because reserved words of c translate one to one
    > to assembler instructions, with few exceptions.
    >
    > The "advantages" of c standard libraries make it easier for one to
    > write software, but one could write their own function libraries in
    > the c lexicon without third party libraries, providing they had an
    > expert understanding of the target hardware.


    More than that... Other than basic things like fopen(), fputc(), etc, or
    more primitive C-callable functions used by them (nearly all of which
    are in stdio.h - and a _lot_ of stdio.h can still be written in C) which
    require knowledge of how to access operating system services directly,
    the C library can be written entirely in "standalone" C - that is, in
    the subset of C which is permitted in programs that are strictly
    conforming for freestanding implementation, except without the
    restrictions on the identifiers used. More precisely, with said
    restrictions turned upside down, since if you're writing the C library,
    you're part of the implementation, and thus should be using identifiers
    reserved to the implementation rather than those belonging to the user.

    >> NULL is a macro that expands to a null pointer constant; it doesn't
    >> apply to non-pointer types.
    >>
    >>

    >
    > NULL is "#define NULL 0" in every c compiler I have used, and I code regularly
    > on ten different *nix operating systems. NULL, the macro, is neither a
    > "pointer," int, long, or char, but can be assigned to all.


    However, you _should_ not assign it to non-pointer types, since it can
    be ((void*)0)

    Here's part of <sys/_null.h> (#included on my system, FreeBSD 6.0, by
    any header which is expected to provide a definition for NULL)

    #if defined(_KERNEL) || !defined(__cplusplus)
    #define NULL ((void *)0)
    #else /* !defined(_KERNEL) && defined(__cplusplus)
    ....

    glibc appears to do something similar.

    > You say potato, I say NULL -- most c developers think zero when
    > reading NULL.


    Yes, but good ones follow "zero" with ", possibly cast to pointer to
    void".
    Jordan Abel, Jan 7, 2006
    #16
  17. Jordan Abel wrote:
    > On 2006-01-07, Joseph Dionne <> wrote:
    >
    >>Keith Thompson wrote:
    >>
    >>>Joseph Dionne <> writes:
    >>>
    >>>
    >>>>Madhav wrote:
    >>>>
    >>>>
    >>>>>Hi all,
    >>>>> I did not understand why do the global vars are
    >>>>>initialized to NULL where as the block level variables have random
    >>>>>values? I know that the C standard requires this as was mentioned in a
    >>>>>recent thread.
    >>>>> I want to know why this descrimination is in place. Can't all
    >>>>>the
    >>>>>variables be initialised to NULL automatically by the compiler? This
    >>>>>would make programming a little easier.
    >>>>
    >>>>Technically, global variables are not "initialized" by the compiler.
    >>>>Program globals, data segment, variables are either initialized by the
    >>>>programmer, or by the program loader as it is copied into ram and it's
    >>>>code/data space is allocated.
    >>>
    >>>
    >>>Technically, global variables are implicitly initialized; the
    >>>implementation (of which the compiler is a part) can accomplish this
    >>>in any convenient manner. Data segments and program loaders are
    >>>implementation details that may be used to implement the semantics
    >>>required by the language; they're outside the scope of the langauge
    >>>and of this newsgroup.
    >>>

    >>
    >>Now you are just being flippant. This group is for discussing c
    >>language programming, and what a compiler does to create the
    >>executable object is pertinent to the OP's post. As I read what he
    >>"thought" should happen would not be a function of compilation, but a
    >>feature added in 4th generation languages.
    >>
    >>C is considered a 3rd generation, however IMHO it is more like a 2.5
    >>generation language because reserved words of c translate one to one
    >>to assembler instructions, with few exceptions.
    >>
    >>The "advantages" of c standard libraries make it easier for one to
    >>write software, but one could write their own function libraries in
    >>the c lexicon without third party libraries, providing they had an
    >>expert understanding of the target hardware.

    >
    >
    > More than that... Other than basic things like fopen(), fputc(), etc, or
    > more primitive C-callable functions used by them (nearly all of which
    > are in stdio.h - and a _lot_ of stdio.h can still be written in C) which
    > require knowledge of how to access operating system services directly,
    > the C library can be written entirely in "standalone" C - that is, in
    > the subset of C which is permitted in programs that are strictly
    > conforming for freestanding implementation, except without the
    > restrictions on the identifiers used. More precisely, with said
    > restrictions turned upside down, since if you're writing the C library,
    > you're part of the implementation, and thus should be using identifiers
    > reserved to the implementation rather than those belonging to the user.
    >
    >
    >>>NULL is a macro that expands to a null pointer constant; it doesn't
    >>>apply to non-pointer types.
    >>>
    >>>

    >>
    >>NULL is "#define NULL 0" in every c compiler I have used, and I code regularly
    >>on ten different *nix operating systems. NULL, the macro, is neither a
    >>"pointer," int, long, or char, but can be assigned to all.

    >
    >
    > However, you _should_ not assign it to non-pointer types, since it can
    > be ((void*)0)
    >
    > Here's part of <sys/_null.h> (#included on my system, FreeBSD 6.0, by
    > any header which is expected to provide a definition for NULL)
    >
    > #if defined(_KERNEL) || !defined(__cplusplus)
    > #define NULL ((void *)0)
    > #else /* !defined(_KERNEL) && defined(__cplusplus)
    > ...
    >
    > glibc appears to do something similar.
    >
    >
    >>You say potato, I say NULL -- most c developers think zero when
    >>reading NULL.

    >
    >
    > Yes, but good ones follow "zero" with ", possibly cast to pointer to
    > void".


    I surrender! Since I never use NULL in my code, choosing to use a (cast)0
    where cast is "int *", "char *", etc, you win.

    Furthermore, "int ii = NULL" in C99 compilers and above (at least) started to
    generate a warning about type violations, you hold the higher ground in the
    argument.
    Joseph Dionne, Jan 7, 2006
    #17
  18. Joseph Dionne <> writes:
    > Keith Thompson wrote:
    >> Joseph Dionne <> writes:

    [...]
    >>>Technically, global variables are not "initialized" by the compiler.
    >>>Program globals, data segment, variables are either initialized by the
    >>>programmer, or by the program loader as it is copied into ram and it's
    >>>code/data space is allocated.

    >> Technically, global variables are implicitly initialized; the
    >> implementation (of which the compiler is a part) can accomplish this
    >> in any convenient manner. Data segments and program loaders are
    >> implementation details that may be used to implement the semantics
    >> required by the language; they're outside the scope of the langauge
    >> and of this newsgroup.

    >
    > Now you are just being flippant.


    Not at all.

    > This group is for discussing c
    > language programming, and what a compiler does to create the
    > executable object is pertinent to the OP's post. As I read what he
    > "thought" should happen would not be a function of compilation, but a
    > feature added in 4th generation languages.


    The specific methods that particular compilers use to implement the
    required semantics of the C language are mostly off-topic, though a
    general discussion of how those semantics are implemented could be
    topical. It's appropriate (IMHO) to mention that stacks, heaps, data
    segments, ".bss" segments, program loaders and so forth are common
    techniques, but asserting that they are *the* way the language is
    implemented is both inapproprate and inaccurate.

    > C is considered a 3rd generation, however IMHO it is more like a 2.5
    > generation language because reserved words of c translate one to one
    > to assembler instructions, with few exceptions.


    I don't think that's particularly accurate, but it's beside the point.

    [...]

    >> NULL is a macro that expands to a null pointer constant; it doesn't
    >> apply to non-pointer types.
    >>

    >
    > NULL is "#define NULL 0" in every c compiler I have used, and I code
    > regularly on ten different *nix operating systems. NULL, the macro,
    > is neither a "pointer," int, long, or char, but can be assigned to all.


    There's a big difference between "every C compiler you've used" and
    "every C compiler". NULL is defined to expand to a null pointer
    constant. I commonly use implementations where NULL expands to
    ((void*)0). Using NULL for anything other that a pointer is wrong,
    though it may happen to "work" in some implementations.

    You really need to understand that pointers and integers are two
    different things.

    > You say potato, I say NULL -- most c developers think zero when reading NULL.


    No.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 7, 2006
    #18
  19. On Sat, 07 Jan 2006 23:32:53 GMT, in comp.lang.c , Joseph Dionne
    <> wrote:

    (and didn't snip any of 101 lines)

    >I surrender!


    Can you also please learn to trim posts a little? You can remove
    anything not relevant to your reply.

    Mark McIntyre
    --

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Jan 7, 2006
    #19
  20. Mark McIntyre wrote:
    > On Sat, 07 Jan 2006 23:32:53 GMT, in comp.lang.c , Joseph Dionne
    > <> wrote:

    [..]
    >
    > Mark McIntyre


    Yes
    Joseph Dionne, Jan 8, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andy Fish

    block scoped variables

    Andy Fish, Aug 15, 2003, in forum: Java
    Replies:
    3
    Views:
    410
    Chris Uppal
    Aug 16, 2003
  2. pabbu
    Replies:
    8
    Views:
    711
    Marc Boyer
    Nov 7, 2005
  3. Madhav
    Replies:
    4
    Views:
    301
    Kenny McCormack
    Jan 8, 2006
  4. Pavel Smerk
    Replies:
    1
    Views:
    120
    Logan Capaldo
    Aug 3, 2006
  5. Replies:
    3
    Views:
    107
Loading...

Share This Page