Re: struct initilization via memset

From: Jack Klein (jackklein_at_spamcop.net)
Date: 02/14/05 

Date: Mon, 14 Feb 2005 01:05:57 -0600

On Mon, 14 Feb 2005 15:54:25 +1000, "Vince Morgan"
<vir@optusnet.com.au> wrote in alt.comp.lang.learn.c-c++:

>
> "David White" <no@email.provided> wrote in message
> news:CjWPd.8173$i6.82338@nasal.pacific.net.au...
> > "Vince Morgan" <vir@optusnet.com.au> wrote in message
> > news:42102d8d$0$17338$afc38c87@news.optusnet.com.au...
> > >
> > > Zeroing the function pointer wouldn't be a bad thing, I would think.
> >
>
> David, I read a preceding post yesterday.
>
> "Jack Klein" <jackklein@spamcop.net> wrote in message
> news:6f8t01df721iklo8jnj9mp4a7uv4coi7hl@4ax.com...
>
> >In both C and C++ today, you can initialize pointers with NULL, or 0,
> >or even '\0' although I don't recommend that for pointers, and they
> >will all initialize the pointer to a null pointer.
>
> >In the early days of C++, a long, long time ago, when C++ compilers
> >were preprocessors that output C code that had to be compiled with C
> >compiler, some implementations had a problem with the way NULL was
> >defined in C compiler headers.
>
> I think I am mildly confused, of course there is the chance that it isn't
> mild :)
>
> Vince Morgan

Vince, since I've helped to confuse you, I'll try to help straighten
you out. That takes a little bit of history.

By the time of the first ANSI C standard, C had been around for well
over 10 years and C compilers were developed for quite a few different
computer platforms.

Because there was no standard, and because C was supposed to be a
small, fast, efficient systems programming language, many of those
compilers generated code that was most efficient for their particular
platform/processor.

When the first standard was written, there were certain features of
the language which were just plain different on some compilers than on
others, and there was code written for those platforms that depended
on these features working a certain way. Examples are whether plain
char is signed or unsigned, whether right shift of a negative signed
integer sign-extends or not, and the definition of the macro NULL.

If the C standard required one particular behavior for all compilers,
working code on some platforms would break. And one of the mandates
of the original standard committee was not to break existing working
programs without a very good reason.

The end result was that some things in the C standard are
implementation defined, and most of them also in C++.

By the time the committee was putting together the first C standard,
there were two common definitions for the macro NULL, either an
integer constant expression with a value of 0, or an integer constant
expression with a value of 0 cast to pointer to void. Here are the
two simplest examples:

   #define NULL 0

...or:

   #define NULL ((void *)0)

The C standard committee decided to leave the selection of which
definition to use up to the compiler, so as not to break existing
code. C compilers are still allowed to use either definition of NULL
today under the latest version of the standard.

Now consider this simple definition with an initializer:

   int *int_ptr = NULL;

So after macro substitution by the preprocessor, the compiler sees:

   int *int_ptr = 0; /* 1 */

...or:

   int *int_ptr = ((void *)0); /* 2 */

Either one of these works in C. Assigning an integer literal with the
value 0 produces a null pointer. And in C you can assign a void* to a
pointer to any other object type without a cast.

But C++ has different definitions for what pointer types can be
assigned to others without a cast, so expansion /* 1 */ is valid C++,
but expansion /* 2 */ is not. You can't assign a pointer to void to
any other object pointer type in C++ without a cast.

In the early days of C++, the C++ compilers were actually
source-to-source translators. They read the C++ source code and
output a C source code file, which was then compiled by the computer's
C compiler. And in at least some cases, the C++ front end used the C
compiler's headers.

That's when it became a problem, if the C++ translator included one of
the C headers that defined NULL as (void *)0, and then ran across a
statement that used NULL to initialize or assign to a pointer. This
caused an error in the C++ translator.

So it became common practice in C++ to always use '0' instead of NULL.
The resulting code is valid in both C and C++, and never has a problem
with the definition of NULL.

The first ANSI/ISO C++ language standard was approved in 1998, and it
requires that C++ compilers define NULL as plain old 0, and absolutely
not as ((void *)0).

These days C++ is standardized and well supported by compilers, and
there is a standard way to handle problems like this, so the same
headers can be included by both C and C++ compilers.

Every C++ compiler internally defined a macro __cplusplus, and the C
standard forbids C compilers from defining that macro. Some compiler
suppliers want to keep the old C definition of NULL for backwards
compatibility to the days when there were only C compilers, so they do
something like this, copied from a very popular compiler's <string.h>
header:

#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif

And that's all there is to it. Even if the compiler, compiling C
code, sees the second definition, when it is compiling C++ code is
sees the first.

It has been at least 10 years since a C++ compiler has had a problem
with using the NULL macro with any type of pointer. 

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Relevant Pages

  • Re: NULL in variadic function calls
    ... >> Standard. ... >> It is true that on most modern compilers and architectures, ... value is a null pointer: ... valid pointer value, representing an actual, valid memory ...
    (comp.unix.programmer)
  • Re: Another String reversal question
    ... With some hardware, the higher 16 bits would be unchanged. ... (For some compilers, only the low 16 bits took part in pointer ... but the C++ standard requires that the compiler make it ...
    (comp.lang.cpp)
  • Re: struct initilization via memset
    ... > By the time of the first ANSI C standard, C had been around for well ... > compilers generated code that was most efficient for their particular ... and the definition of the macro NULL. ... > expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: class variables: scoping
    ... >> standard, though there are variations you can try. ... > with other compilers as well. ... But you can't convert a pointer to member function into a void*, ... > that problems may arise in multithreaded applications. ...
    (comp.lang.cpp)
  • Re: legality of forward declaration
    ... a special case for compilers conforming to the 1999 or later version ... how do you interpret the following paragraph from the C99 Standard ... void foo; ... is this a bug in Code Warrior (incorrectly ...
    (comp.lang.c)
Loading