From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Espie To: Linus Torvalds Cc: gcc@gcc.gnu.org Subject: Re: GCC headers and DJGPP port (OT) Date: Sun, 23 Jul 2000 16:50:00 -0000 Message-id: <20000724015025.A25478@quatramaran.ens.fr> References: <200007231412.QAA10673@quatramaran.ens.fr> X-SW-Source: 2000-07/msg00745.html 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.