This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC headers and DJGPP port (OT)
On Sun, Jul 23, 2000 at 12:03:38PM -0700, Linus Torvalds wrote:
> On Sun, 23 Jul 2000, Marc Espie wrote:
> > The reverse is not true, for obvious reasons: you're recreating information
> > about a type that you don't have.
> This is true in general.
> It is absolute and utter crap when it comes to the constant magical
> pointer that everybody agrees must exist: NULL.
> Any cast of a (type-less pointer) NULL pointer to another pointer is
> obviously not "creating information". It's taking the source code as
> written by the programmer, using the implicit pointer information in the
> assignment to advantage. It's shorthand.
Historically, NULL was not a pointer. NULL was not anything.
> Whether you like the C notion of a "generic" type-less pointer (ie the C
> "void *") or not is irrelevant. You obviously don't like it. I personally
> think that the C++ anal behaviour wrt "void *" is just silly and rude. It
> results in casts that shouldn't be there, which in turn can hide real
> bugs. But that's a matter of personal opinion, and to all his own.
C is missing whole chunks of a type-system. Special-casing (void *) is a bad
idea. The presence of (void *) itself means that something fishy is
going on. Casts are a tell-tale... Yes, they can hide bugs, but not very
often. A proper compiler should be able to warn when you're casting
non pointers to pointer types (which is about the only bug this cast can
hide).
What I don't like is that this is probably THE single most annoying case
when you want to take C code and compile it as C++...
And changing C++ type system, which is weird, but at least clean, is out of
the question.
This is yet another example in a long history of the C committee taking
C++ chunks and making stuff incompatible (after the C++ people spent quite
a long time trying to make C++ as compatible with C as they could)...
> But NULL is not a "generic" type-less pointer. It's a very specific one.
> As exemplified by the fact that historically there's been this silly
> special case about casting the _integer_ 0 to a pointer. Which is truly
> horrendous.
The ANSI C committee could have just magically decreed that NULL was a null
pointer, and be done with it forever... Ignore #define NULL, assume it's
always defined, issue a warning if NULL is used in a non pointer context,
deprecate that usage, and be done with it with the next revision of the
standard.
> Basically I was just wondering why in the world gcc couldn't just
> recognize the "((void *)0)" construct as equivalent to the new __null? Why
> introduce a new keyword instead of just using accepted practice from C?
__null is needed for C++. In C++, you need to issue a diagnostic if
(void *)0 is encountered and assigned to another pointer type.
You could get smart and recognize that the (void *)0 comes from a #define NULL,
but the standard mandates the warning for plain (void *)0, there's just no
way around it.
Knowing you, I know that special-casing (void *)0 is the kind of things
you would like because it's Cool :-).
However, it doesn't quite work, and is probably more intricate than simply
adding __null in the long run. __null is safe. I wouldn't be surprised if
the wording of the C++ standard was chosen specifically so that this
solution would be about the only reasonable one.
Personally, I have seen enough gcc problems that I am happy when the
gcc team chooses comparatively simple solutions over positively wacky stuff.