Re: GCC headers and DJGPP port (OT)

Re: GCC headers and DJGPP port (OT)

[Mike Stump]

> Date: Sun, 23 Jul 2000 12:12:40 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: Phil Edwards <pedwards@disaster.jaj.com>

> I think the "enum is a normal integer" thing is a much bigger issue
> type-checking-wise.

What problem?  Oh, you mean the one in C that doesn't exist in C++,
yeah, almost forgot about it.  :-)

RE: GCC headers and DJGPP port (OT)

[Mike Stump]

> From: "Akbar A." <syedali011@earthlink.net>
> To: <gcc@gcc.gnu.org>
> Date: Sun, 23 Jul 2000 15:57:42 -0700

> sorry for me being so new at compiler development and learning about
> the design of programmign languages.  but, where can i info or the
> manual sheet about the new specfications?

You can join ANSI and write the new standards, if you want.  You can
read the comp.lang.c/comp.lang.c+ faqs, and probably have your
questions answered.  After that, discussion about languages below in
comp.lang.{c,c++}.  If you don't know what that is, try
www.dejanews.com.

Please post any follow up questions in the group that has the word
help in it, see the web site for details.  Just in case you've never
seen it, http://gcc.gnu.org/ .

Hope that helps.

Re: GCC headers and DJGPP port (OT)

[Anjul Srivastava]

I maintain that C++ is correct, and IN CONSONANCE with ANSI C, in not
allowing NULL to be defined as ((void *)0)

In support of this assertion, I am quoting three paragraphs, one from MODERN
ANSI/ISO STANDARDS for C and C++, one from an EQUIVALENTLY modern and ANSI
conforming book:

ISO/IEC 14882:1998(E) [ C++ Standard ]

"4.10 Pointer conversions

1 A null pointer constant is an integral constant expression (5.19) rvalue
of integer type that evaluates to zero. A null pointer constant can be
converted to a pointer type; the result is the null pointer value of that
type and is distinguishable from every other value of pointer to object or
pointer to function type. Two null pointer values of the same type shall
compare equal. The conversion of a null pointer constant to a pointer to
cv-qualified type is a single conversion, and not the sequence of a pointer
conversion followed by a qualification conversion (4.4)"

ANSI C Edition of "The C Programming Language" by Kernighan and Ritchie
Appendix A: Reference Manual

"A6.6 Pointers and integers

[third paragraph]

An integral constant expression with value 0, or such an expression cast to
type void *, may be converted, by a cast, by assignment, or by comparison,
to a pointer of any type. This produces a null pointer that is equal to
another null pointer of the same type, but unequal to any pointer to a
function or object."

same book p. 102
[paragraph near the center of the page]

"Pointers and integers are not interchangeable. Zero is the sole exception:
the constant zero may be assigned to a pointer, and a pointer may be
compared with the constant zero. The symbolic constant NULL is often used in
place of zero, as a mnemonic to indicate more clearly that this is a special
value for a pointer. ...."

------------

C++ legimately takes away the EXTRA PRIVILEGE of prepending (void *) to 0,
because it doesn't serve any purpose except to generate warnings when NULL
is assigned to non-pointer variables. There was a strong reason to take away
this "no sand in the gas tank" privilege -- as outlined in a mail by
somebody else on the subject, by allowing an implicit cast from (void *) to
(some-type *) we are allowing blind creation of type information (the
original author expresses the point better).

Both C and C++ (ANSI/ISO) give the special status to 0 and compile time
integer expressions evaluating to 0. That special status is that the rvalue
can be used as a null pointer.

So, why on earth would one want

However, Linus has pointed out a seemingly legitimate reason to be able to
prepend (void *) to 0. That is, overloading problems. Well, it is something
to be thought over in depth. The complaint is that you cannot get overload
resolution between "void foo(int);" and "void foo(int *);" if you call
"foo(NULL)". But then, what about the case where you have "void foo(char
*);" and "void foo(int *);"? Even if (void *)0 were allowed, how would the
C++ compiler distinguish between the two in a call to "foo(NULL)". Allowing
(void *) only postpones this problem. Whether it is solvable IN GENERAL
without the compiler reading the programmer's mind or not, is not clear to
me. In my (strong) opinion, the language design is more elegant without the
(void *) allowance.

------------

Yes, I agree that whether one wants to use 0 in code, or use NULL defined as
0, is purely a matter of personal taste. The visual aid provided by NULL is
helpful but not sufficient to NECESSIATE its use. One cannot look at "1" and
say whether it is being passed to a short, int, char, or long? Reiterate: it
is okay to use NULL instead of 0 but it is purely a matter of taste.

------------

Unlike the ISO C++ standard, the C standard is prohibitively expensive for
me to keep on my desk, which is why I quoted from the ANSI edition of K&R
(which is quite different from K&R C). I would like to state that I have
NEVER written a non-prototyped C function. I endeavour to use the most
modern standardized editions of languages and software.

------------

No offense intended to anybody, it is easy and understandable to presume
that I am a complete novice or an old-timer sticking to prototypes. But then
I suppose being called silly and stupid (although in private) does allow me
to do a bit of uppercasing! :-)

Cheers,
Anjul.

-----Original Message-----
From: Linus Torvalds [ mailto:torvalds@transmeta.com ]
Sent: Sunday, July 23, 2000 1:37 PM
To: Anjul
Subject: Re: GCC headers and DJGPP port (OT)




On Sun, 23 Jul 2000, Anjul wrote:
>
> I personally hate using NULL anywhere in C/C++ code.

You're being silly.

> 0 has special status in C (and also I presume C++). I don't have K&R with
me
> now, but if you search the index (for NULL (?)), you will find a paragraph
> that goes like (can send you the exact pp. later if you wish):

Note that K&R C is broken. It doesn't have proper type-checking for
functions etc, and ANSI C is the only one that really makes sense to use
for the last 10 years or so.

But yes, 0 is special. However, it should NOT be used.

> Therefore, (void *)0 is quite unnecessary. 0 would serve the same purpose.

No.

Using a plain "0" is bad. It means that the following non-sensical code
will compile without warnings:

	int i = NULL;

And in the case of C++, the problem becomes even worse, as the type of the
operand determines what you should do with overloading etc.

Thus ((void *)0) is a _lot_ better than using 0.

And ANSI C has allowed it from the beginning.

> Perhaps, one use of (void *)0 would be to restrict its comparison or
> assignment to int, char, long, ... types. I don't see this advantage as
> significant or important. To try to stop programmers from writing "int
> i=NULL;" is in the direction of trying to stop car-owners from putting
sand
> in their gas-tanks.

Go on playing with your K&R compiler, go on not using prototypes and type
checking. Trust me, good programmers do NOT ignore the importance of
type-checking. They may know how to avoid it on purpose, but it should not
be avoided by stupidity.

		Linus

Re: GCC headers and DJGPP port (OT)

[Mark Mitchell]

>>>>> "Anjul" == Anjul Srivastava <anjul.srivastava@sanchez.com> writes:

Folks --
  
    Anjul> I maintain that C++ is correct, and IN CONSONANCE with ANSI
    Anjul> C, in not allowing NULL to be defined as ((void *)0)

  This list is for discussing GCC.  This discussion was originally
about DJGPP headers and G++'s __null and the interaction between the
two.  That was an appropriate use of the list.

  The debate has now shifted to whether or not the way the C and C++
standards handle NULL is good.  That's an interesting debate, but
belongs in another forum.

  Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC headers and DJGPP port (OT)

[Phil Edwards]

Linus Torvalds <torvalds@transmeta.com>:
> Off-topic: why is it exactly that C++ doesn't like the "((void *)0)"
> thing, which as far as I can tell has all the same advantages? Was it
> purely a "stupid standard" issue, or is there some actual real deeper
> reason for it?

Real reasons, which several people will probably have already explained
by the time this message makes it out...  Can't pass pointer-to-void into
a function taking pointer-to-foo without explicit casts.


> That was one of my pet peeves about C++: I always considered the
> historical "#define NULL 0" to be complete braindamage due to lack of
> even the simplest kind of type-checking (and matching to a pointer type
> is just one small portion of that type-checking - getting sane and
> appropriate warnings is quite important). 

Funny, that's always been one of my pet peeves about C.  :-)


> And C++ made the ANSI-C-approved "((void *)0)" define illegal for some
> reason that I still haven't quite grasped.

It's legal only in the absence of strong(er) typechecking.  It's arguable
that special exceptions should have been made in the case of zero (however
you spell it), but it's also arguable that special cases lead to bigger
problems, namely in the field of teaching new programmers.


Phil

Re: GCC headers and DJGPP port (OT)

[Linus Torvalds]

On Sun, 23 Jul 2000, Phil Edwards wrote:
> 
> > That was one of my pet peeves about C++: I always considered the
> > historical "#define NULL 0" to be complete braindamage due to lack of
> > even the simplest kind of type-checking (and matching to a pointer type
> > is just one small portion of that type-checking - getting sane and
> > appropriate warnings is quite important). 
> 
> Funny, that's always been one of my pet peeves about C.  :-)

Hmm.. In C you _can_ avoid type-checking, but it's not that hard to make
it reasonably strongly typed: using gcc the magic flags are "-Wall
-Wstrict-prototypes", and some simple rules.

You still get all the implicit integer and FP conversions done, and that
can be occasionally painful, but not doing them is even more painful, so..

I don't think "void *" is a problem. It just should be used with extreme
caution. I think the "enum is a normal integer" thing is a much bigger
issue type-checking-wise.

		Linus

RE: GCC headers and DJGPP port (OT)

[Akbar A.]

sorry for me being so new at compiler development and learning about the
design of programmign languages.
but, where can i info or the manual sheet about the new specfications?

>I think the "enum is a normal integer" thing is a much bigger
>issue type-checking-wise.
?

thanks in advance.
akbar A.

-----Original Message-----
From: gcc-owner@gcc.gnu.org [ mailto:gcc-owner@gcc.gnu.org]On Behalf Of
Linus Torvalds
Sent: Sunday, July 23, 2000 12:13 PM
To: Phil Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: GCC headers and DJGPP port (OT)




On Sun, 23 Jul 2000, Phil Edwards wrote:
>
> > That was one of my pet peeves about C++: I always considered the
> > historical "#define NULL 0" to be complete braindamage due to lack of
> > even the simplest kind of type-checking (and matching to a pointer type
> > is just one small portion of that type-checking - getting sane and
> > appropriate warnings is quite important).
>
> Funny, that's always been one of my pet peeves about C.  :-)

Hmm.. In C you _can_ avoid type-checking, but it's not that hard to make
it reasonably strongly typed: using gcc the magic flags are "-Wall
-Wstrict-prototypes", and some simple rules.

You still get all the implicit integer and FP conversions done, and that
can be occasionally painful, but not doing them is even more painful, so..

I don't think "void *" is a problem. It just should be used with extreme
caution. I think the "enum is a normal integer" thing is a much bigger
issue type-checking-wise.

		Linus

Re: GCC headers and DJGPP port (OT)

[Linus Torvalds]

In article < 200007222029.QAA29095@disaster.jaj.com >,
Phil Edwards  <pedwards@disaster.jaj.com> wrote:
>
>Having __null magically only match pointer types is an extremely froody
>solution, and I'm glad that g++ went that route.

Off-topic: why is it exactly that C++ doesn't like the "((void *)0)"
thing, which as far as I can tell has all the same advantages? Was it
purely a "stupid standard" issue, or is there some actual real deeper
reason for it?

That was one of my pet peeves about C++: I always considered the
historical "#define NULL 0" to be complete braindamage due to lack of
even the simplest kind of type-checking (and matching to a pointer type
is just one small portion of that type-checking - getting sane and
appropriate warnings is quite important). 

And C++ made the ANSI-C-approved "((void *)0)" define illegal for some
reason that I still haven't quite grasped. Gcc used to have the "don't
complain" extension for some time, and now we've moved to "__null". What
were the issues, just out of morbid curiosity?

Or am I better off not knowing?

		Linus

Re: GCC headers and DJGPP port (OT)

[Oleg Zabluda]

On Thu, 28 Aug 2036, Linus Torvalds wrote:
> 
> Off-topic: why is it exactly that C++ doesn't like the "((void *)0)"
> thing, which as far as I can tell has all the same advantages? Was it
> purely a "stupid standard" issue, or is there some actual real deeper
> reason for it?
> 
> That was one of my pet peeves about C++: I always considered the
> historical "#define NULL 0" to be complete braindamage due to lack of
> even the simplest kind of type-checking (and matching to a pointer type
> is just one small portion of that type-checking - getting sane and
> appropriate warnings is quite important). 

For the purpose of this discussion, it's enough to know that a "null pointer
constant" can be used to initialize or assign to a pointer, despite the fact
that their types do not match.

In both C and C++ ((int)0) was always a "null pointer constant". C additionally
allowed ((void*)0) to be a "null pointer constant". It was more acceptable in C
then in C++ because of the weaker typesystem. In C++ there is no implicit
conversion from void* to pointers-to-object, say int*.

Still, it's not a showcase of elegance. For example, in ANSI C there is
no conversion, implicit or otherwise, from void* to pointer-to-function. 

In C++ inelegance would be even worse, because there are two more incompatible
pointer types: pointer-to-member-variable and pointer-to-member-function.

Oleg.

Re: GCC headers and DJGPP port (OT)

[Marc Espie]

In article < Pine.LNX.4.10.10007222131230.1315-100000@penguin.transmeta.com > you write:

>And C++ made the ANSI-C-approved "((void *)0)" define illegal for some
>reason that I still haven't quite grasped. Gcc used to have the "don't
>complain" extension for some time, and now we've moved to "__null". What
>were the issues, just out of morbid curiosity?

C type system is brain-dead.
C++ type system is complicated, but at least, it offers some safety.
Specifically, conversions that increase knowledge about a pointer are
safe, so that you may safely pass an 'int *' to a function that takes a
'void *'.  

The reverse is not true, for obvious reasons: you're recreating information
about a type that you don't have.

So, char *p = malloc(15); is invalid in C++, you must put the cast.
(In fact, you will rather use char *p = new char[15]  in C++)

Defining NULL to (void *)0   does not work: char *p = NULL; is then illegal.

...and you want a pointer type for NULL so that you will be able to 
distinguish f(0) from f(NULL)...

It's C that is completely broken here.

Historically, void is a C++ invention. I don't know what the guys who brought
void to C were thinking (as in, completely clueless).  This is one of the
very few cases where C code is not valid C++ code...

Side-note: C's NULL definition is fuzzy enough that var args functions that
want to use NULL as a delineating, null pointer argument can't. For 
portability, the logical null pointer in C, when you are not in a typed
context, is (void *)0.

Re: GCC headers and DJGPP port (OT)

[Linus Torvalds]

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.

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.

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.

I think the __null approach of gcc is laudable and fine: it solves the
problem. I'm not arguing against it.

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?

(Yes, I know some old-timers don't accept the "void *" thing, and think
NULL should be always defined to plain "0", but they should have the same
exact complaints about __null, and they can rot in hell anyway).

I assume it's some silly standard rule. I don't see that it makes any
technical difference, it just looks unnecessary..

		Linus

Re: GCC headers and DJGPP port (OT)

[Marc Espie]

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.

Re: GCC headers and DJGPP port (OT)

[Alexandre Oliva]

On Jul 23, 2000, Linus Torvalds <torvalds@transmeta.com> wrote:

> Basically I was just wondering why in the world gcc couldn't just
> recognize the "((void *)0)" construct as equivalent to the new
> __null?

Because then we wouldn't be able to warn about the potential mis-use
of NULL in a code snippet like:

void foo(void *);
void foo(char *);
void foo(int);
void foo(long);
...
  foo(NULL);

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me