Re: linux libio status

[Alexandre Oliva <oliva at dcc dot unicamp dot br>]

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