Re: linux libio status

Re: linux libio status

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

> We need to silence these warnings.  For the NULL, I suggest a global
> s/NULL/0/ in the C++ iostreams headers.  There is no reason to write
> NULL, it is just a source of problems like this (*especially* since
> we have changed C++ to be strict about void*).

But that won't help user code that uses NULL.

Jason

Re: linux libio status

[Joe Buck]

> >>>>> Joe Buck <jbuck@synopsys.com> writes:
> 
> > We need to silence these warnings.  For the NULL, I suggest a global
> > s/NULL/0/ in the C++ iostreams headers.  There is no reason to write
> > NULL, it is just a source of problems like this (*especially* since
> > we have changed C++ to be strict about void*).
> 
> But that won't help user code that uses NULL.

The comp.lang.c++ tells users "don't use NULL in C++ programming",
precisely for this reason.

The only other alternatives I can think of is to force a #define NULL 0,
or do some kind of mini-fixincludes on the existing libio.h header.
(The latter technique could solve the problems with the new lock functions
as well).

Re: linux libio status

[Per Bothner]

Joe Buck <jbuck@synopsys.com> writes:
> The comp.lang.c++ tells users "don't use NULL in C++ programming",
> precisely for this reason.

I am strongly opposed to any such advice, or to anything that
makes that advice necessary.

Using NULL instead of 0 makes programs clearer, and is strongly
to be encouraged.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: linux libio status

[Richard Henderson]

On Wed, Oct 15, 1997 at 08:51:29AM -0700, Joe Buck wrote:
> The only other alternatives I can think of is to force a #define NULL 0,
> or do some kind of mini-fixincludes on the existing libio.h header.
> (The latter technique could solve the problems with the new lock functions
> as well).

The problem with the fixincludes option is that I ran into the same
problem on RH Linux Alpha not because of <libio.h>, but one of the
kernel header files.

If we leave NULL in the installed C++ headers, redefining NULL is
the only successful option.  Which means in my mind: get it out.


r~

Re: linux libio status

[Joe Buck]

> Joe Buck <jbuck@synopsys.com> writes:
> > The comp.lang.c++ tells users "don't use NULL in C++ programming",
> > precisely for this reason.
> 
> I am strongly opposed to any such advice, or to anything that
> makes that advice necessary.
> 
> Using NULL instead of 0 makes programs clearer, and is strongly
> to be encouraged.

In that case, NULL must be defined to be 0, nothing else.

Re: linux libio status

[Peter Seebach]

In message < 199710151812.LAA15748@cygnus.com >, Per Bothner writes:
>Joe Buck <jbuck@synopsys.com> writes:
>> The comp.lang.c++ tells users "don't use NULL in C++ programming",
>> precisely for this reason.

>I am strongly opposed to any such advice, or to anything that
>makes that advice necessary.

Amen!

>Using NULL instead of 0 makes programs clearer, and is strongly
>to be encouraged.

It also makes a non-empty set of programs *correct*.

However, correctness aside, it is good to use NULL for null pointers,
for the same reason it is good to use "hello, world" rather than
{ 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd' }
to initialize arrays of characters.

(One point extra credit for spotting the difference, two points
extra credit for spotting the case where the two are not different.)

-s

Re: linux libio status

[Per Bothner]

> In that case, NULL must be defined to be 0, nothing else.

I can live with that, but it would be nice to a warning if NULL
is used in an int context.

Currently, __null is mapped into null_node, which (when -ansi is not
specified) is basically basically (void*)0.  I missed the early
context of this discussion, but I gather this causes some problems,
some of which are related to overloading.

I suggest instead that null_node be 0 - the same value and type as
integer_zero_node, but a different tree node.  Then NULL would work
identically to the literal 0.  However, we can add a check when
null_node is treated as an integer (such as assigning to a int
function parameter), and print a warning in those cases.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: linux libio status

[Jason Merrill]

>>>>> Per Bothner <bothner@cygnus.com> writes:

> Currently, __null is mapped into null_node, which (when -ansi is not
> specified) is basically basically (void*)0.  I missed the early
> context of this discussion, but I gather this causes some problems,
> some of which are related to overloading.

I'm not aware of any problems with __null.  If anyone has any overloading
bugs involving __null, please send them in.  There were certainly problems
with making (void*)0 magic in general, which is why I replaced that with
__null.

I believe that NULL should be retrieved from stddef.h, as I outlined
earlier.  This will get the __null definition, which should work for
everyone.  Does anyone have any practical problems with this?

Jason

Make Money Fast (was: Re: linux libio status)

[Branko Cibej]

Peter Seebach wrote:

> However, correctness aside, it is good to use NULL for null pointers,
> for the same reason it is good to use "hello, world" rather than
> { 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd' }
> to initialize arrays of characters.
>
> (One point extra credit for spotting the difference, two points
> extra credit for spotting the case where the two are not different.)

Here you are, then:

    /* sizeof(diff1) == sizeof(diff2) + sizeof('\0') */

    char diff1[] = "hello, world";
    char diff2[] = { 'h', 'e', 'l', 'l', 'o', ',',
                     ' ', 'w', 'o', 'r', 'l', 'd' };

    /* sizeof(same1) == sizeof(same2) == sizeof(diff2) */

    char same1[12] = "hello, world";
    char same2[12] = { 'h', 'e', 'l', 'l', 'o', ',',
                       ' ', 'w', 'o', 'r', 'l', 'd' };


(Who said you couldn't get free credit over the Net? :-)

--
Branko Cibej   <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
phone: (++386 61) 186 53 49  fax: (++386 61) 186 52 70

Re: linux libio status

[Alexandre Oliva]

Jason Merrill writes:

>>>>>> Per Bothner <bothner@cygnus.com> writes:
>> Currently, __null is mapped into null_node, which (when -ansi is not
>> specified) is basically basically (void*)0.  I missed the early
>> context of this discussion, but I gather this causes some problems,
>> some of which are related to overloading.

> I'm not aware of any problems with __null.  If anyone has any overloading
> bugs involving __null, please send them in.  There were certainly problems
> with making (void*)0 magic in general, which is why I replaced that with
> __null.

There may not be overloading bugs related with that, because NULL is
an implementation defined null pointer constant.  However, since CD2
suggests that 0 and 0L are valid definitions of NULL, other compilers
might prefer to use NULL as an integer value instead of using it as a
null pointer constant.  I mean:

bool foo(void*) { return true; }
bool foo(int) { return false; }
bool bar() { return foo(NULL); }

Should bar() return true or false?  This is implementation defined.
If an implementation defines NULL as 0 or even 0L, foo(int) would be
selected, and the result would be false.  However, if __null is
implemented in g++ the way I think it is, foo(void*) would be
selected.  Both results might be surprising.

Worse yet, sometimes overload resolution should fail.  Suppose:

void foo(void*);
void foo(int *);

Shouldn't calling foo(NULL) produce a compile-time error due to
ambiguity?  And what if the following declarations are given instead?

void foo(bool);
void foo(int*);

This is all implementation defined, AFAIK.  Maybe overload resolution
should warn users if __null might have affected the result of the
resolution.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: linux libio status

[Joe Buck]

> I'm not aware of any problems with __null.  If anyone has any overloading
> bugs involving __null, please send them in.

__null isn't a problem, though I don't know what it helps, because it is
g++-specific.  Since much of the code I write has to go through about four
different C++ compilers, only one of which is g++, it's not something I
could make use of.  Since I never use NULL in my code, I don't care how
you define it -- *unless* you use NULL in the standard headers in a way
that breaks if some user defines NULL the wrong way.

> I believe that NULL should be retrieved from stddef.h, as I outlined
> earlier.  This will get the __null definition, which should work for
> everyone.  Does anyone have any practical problems with this?

We can't guarantee that some other header will not attempt to define NULL.
On Red Hat Linux 4.2 (with libc 5.3.12+patches), several do; worse, they
define it as (void *)0.  True, they do '#ifndef NULL' -- but you have to
make sure the headers appear in the right order.

This all started when we tried to solve the problem of running on current
Linux systems.  Current Linux systems define NULL as (void*)0 .  The only
safe solution is to remove all use of NULL from all the libstdc++ headers.
User code can safely use NULL if they get your stddef.h definition.

Re: linux libio status

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

> We can't guarantee that some other header will not attempt to define
> NULL.

No, but we can override any such definition with an #undef, so it doesn't
matter.

Jason