Re: struct initilization via memset

ma740988_at_pegasus.cc.ucf.edu
Date: 02/14/05 

Date: 14 Feb 2005 09:54:45 -0800

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

Interesting. Appreaciate the feedback.

Relevant Pages

  • Re: struct initilization via memset
    ... >>will all initialize the pointer to a null pointer. ... 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 ... expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)
  • 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: Cant understand this! (Help required please)
    ... Yes and some online courses NETG does not seem to understand what ... > New to programming: ... I have heard of comeau don't they make compilers too? ... An argument I have used many times myself, I want to learn standard C++, ...
    (alt.comp.lang.learn.c-cpp)
  • 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: GCC
    ... The header names changed explicitly to ... The Standard says that the standard ... that did not put iostream into the std namespace. ... and compilers change along with them. ...
    (Debian-User)
Loading