linux libio status

linux libio status

[Joe Buck]

Well, it looks like we *really* need to clean out the old 
$prefix/include/g++ before doing make install, because it seemed
that everyone missed this problem ('cause they all had leftover
headers that were getting used).

Thanks to Mumit's suggestion, I blew away everything under $prefix
and re-installed on my Linux Red Hat 4.2 box -- 971008 plus HJ's
patch adding weak symbols.  The good news is that the failing
test posted here recently now passes.  The problem is that we now get a
number of warnings, even for "hello world".

The problem is this: we are now using the /usr/include/libio.h
rather than the one from egcs.  The version included with Red Hat
(libc 5.3.12) has the text

#ifndef NULL
#if !defined(__cplusplus) || defined(__GNUC__)
#define NULL ((void*)0)
#else
#define NULL (0)
#endif
#endif

Now, egcs has been fixed so that C++ no longer freely casts (void *)0
to other pointers, so this now gives lots of warnings.

e.g. for "hello world", or
-----
#include <iostream.h>

main () {
        cout << "Hello, world\n";
}
-----

In file included from /usr/local/egcs/include/g++/iostream.h:31,
                 from hello.cc:1:
/usr/local/egcs/include/g++/streambuf.h:394: warning: invalid type `void
*' for default argument to `ios *'
In file included from hello.cc:1:
/usr/local/egcs/include/g++/iostream.h:50: warning: invalid type `void *'
for default argument to `ostream *'
/usr/local/egcs/include/g++/iostream.h: In method `int ostream::opfx()':
/usr/local/egcs/include/g++/iostream.h:53: warning: implicit declaration
of function `int _IO_flockfile(...)'
/usr/local/egcs/include/g++/iostream.h: In method `void ostream::osfx()':
/usr/local/egcs/include/g++/iostream.h:54: warning: implicit declaration
of function `int _IO_funlockfile(...)'
/usr/local/egcs/include/g++/iostream.h: At top level:
/usr/local/egcs/include/g++/iostream.h:123: warning: invalid type `void *'
for default argument to `ostream *'
/usr/local/egcs/include/g++/iostream.h:230: warning: invalid type `void *'
for default argument to `ostream *'

If we force NULL to be 0 as in
c++ -DNULL=0 hello.cc

we are down to

/usr/local/egcs/include/g++/iostream.h: In method `int ostream::opfx()':
In file included from hello.cc:1:
/usr/local/egcs/include/g++/iostream.h:53: warning: implicit declaration
of function `int _IO_flockfile(...)'
/usr/local/egcs/include/g++/iostream.h: In method `void ostream::osfx()':
/usr/local/egcs/include/g++/iostream.h:54: warning: implicit declaration
of function `int _IO_funlockfile(...)'

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*).

I don't know where the missing declarations should go; perhaps HJ has
an idea.  One possibility is to just define them to null when the
older library is in use.  The new libio.h could have its locking
functions split off into a new header, which always gets installed.
Or something; I'm sure HJ and/or Ulrich have better ideas.

Joe

Re: linux libio status

[Richard Henderson]

On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
> We need to silence these warnings.  For the NULL, I suggest a global
> s/NULL/0/ in the C++ iostreams headers.

That's a reasonable solution.  In my version of the libio patches, 
I make _G_config.h undef and redefine NULL to avoid this problem.

> I don't know where the missing declarations should go; perhaps HJ has
> an idea.

I worked around this for Linux/Alpha by providing versions of 
libc-lock.h and stdio-lock.h to install with the newly built library.
Perhaps we do the same thing for Intel?


r~

Re: linux libio status

[Olivier Galibert]

On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
> 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*).

Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
when int=32b and pointer=64b.

  OG.

Re: [ECGS] linux libio status

[chip]

According to Olivier Galibert:
> On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
> > 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*).
> 
> Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
> when int=32b and pointer=64b.

That's not helpful in C++, because all functions must be properly
prototyped.  In any case, any programs that need NULL to be defined
to 0L are just plain broken, and in a fairly insidious way; the one
case in C++ where it might make a difference (variadic functions)
requires a cast of the NULL before it is standard-compliant anyway.
-- 
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Re: linux libio status

[Peter Seebach]

In message < 19971015095211.03621@renaissance.loria.fr >, Olivier Galibert writes
:
>On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
>> 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*).

>Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
>when int=32b and pointer=64b.

Assuming, of course, that 0L is 64 bits.  Rumor has it that some
implementations chose to make int and long 32, pointer 64, and
(cough) "long long" 64.

Further, what of an implementation where long is *larger* than a
pointer, but int is the same size?  Then you need 0, not 0L...

The only correct way to pass null pointers to stdarg functions
is with a cast to the type of pointer the function will be looking
for.  Probably a misfeature, but history doesn't always favor
elegance.

It would have been a little easier if C89 had ruled that NULL must
actually have pointer type, then you could just use it for anything
that would be taking arguments as (void *), and, if you're feeling
courageous and not-quite-perfectly-portable, you could just use it
for all the pointers...

-s

Re: linux libio status

[Joe Buck]

> It would have been a little easier if C89 had ruled that NULL must
> actually have pointer type, then you could just use it for anything
> that would be taking arguments as (void *), and, if you're feeling
> courageous and not-quite-perfectly-portable, you could just use it
> for all the pointers...

The problem is that C didn't think out this pointer stuff well enough.
The main breakage was to say that (void *) can be assigned to any pointer
type.  But that confuses several types of pointers together into one mishmash.
There are certain distinguished pointer types not directly reflected in
the language:

	-- the null pointer
	-- a "maximally aligned" pointer, as returned by malloc

Such objects can be legally assigned to any pointer type.  Then there is
another beast, the pointer to unknown data object.  We can't say anything
about its alignment.  The problem is that C decided to make all of these
beasts (void *) and permit free casting.

What if there were a new type, aligned_pointer_t.  malloc would return
one of these.  We can safely convert an aligned_pointer to any type of
pointer, so no cast is needed.  Any cast in the reverse direction would
be system-dependent, so a cast is needed.  Similarly, any pointer can
be converted to void *, but neither C nor C++ would allow conversion of
(void *) to another type of pointer without a cast.  Then NULL could
be (aligned_pointer_t)0, and this could work in C or C++.

Re: linux libio status

[Joe Buck]

> 
> On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
> > 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*).
> 
> Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
> when int=32b and pointer=64b.

And you'll be broken on platforms where sizeof(long) != sizeof(pointer),
or at least you would if it weren't for the fact that C++ requires
prototypes for all functions.  Remember, we are talking about C++ here,
not C.

Stroustrup says (The C++ Programming Language, 3rd Edition, p. 88)
"Because of C++'s tighter type checking, the use of plain 0, rather than
any suggested NULL macro, leads to fewer problems.  If you feel that you
must define NULL, use

const int NULL = 0;

..."

There is a similar discussion in the comp.lang.c++ FAQ.

In C++, there are always prototypes.  Thus 0 or 0L makes no difference,
and in fact the "standard null pointer" is essentially 0 in C++.  The
argument is coerced to the proper pointer.  However, standard C++ does
not let you convert (void *) to (T *) without a cast, so defining NULL
as (void *)0 is completely broken in C++.  It used to work in g++, but
that was an extension (furthermore this extension prevented g++ from
implementing the standard overloading rules correctly).  Hence

The only exception is functions with ... in their spec.  Here, neither 0
nor 0L will result in portable code.  Your suggestion switches the
erroneous assumption that sizeof(T *) == sizeof(int) with another
erroneous assumption, that sizeof(T *) == sizeof(long).  Worse, you leave
users with the idea that they can safely use NULL for any null pointer
type, even in variadic functions.  Sorry, you can't do that in standard
C++.  For variadic functions, users must declare any optional arguments
correctly, period.

Conclusion: we should deprecate the use of NULL in C++ code.  If we
must define NULL for C++ code, it must be 0.  Nothing else.

Re: linux libio status

[Olivier Galibert]

On Wed, Oct 15, 1997 at 09:04:20AM -0700, Joe Buck wrote:
> > Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
                                                                 ^^^^^^^
> > when int=32b and pointer=64b.

I was explicitely talking about functions with '...' in them.


> The only exception is functions with ... in their spec.  Here, neither 0
> nor 0L will result in portable code.  Your suggestion switches the
> erroneous assumption that sizeof(T *) == sizeof(int) with another
> erroneous assumption, that sizeof(T *) == sizeof(long).  Worse, you leave
> users with the idea that they can safely use NULL for any null pointer
> type, even in variadic functions.  Sorry, you can't do that in standard
> C++.  For variadic functions, users must declare any optional arguments
> correctly, period.
> 
> Conclusion: we should deprecate the use of NULL in C++ code.  If we
> must define NULL for C++ code, it must be 0.  Nothing else.


You say "make sure that current code works but randomly crashes when the
users upgrade to new 64bits architectures". I don't call that being
fair to the user. The current existing architectures I know about are:
- 32bits int, 32bits long, 64bits long long, 32bits ptr
- 32bits int, 64bits long, 64bits long long, 64bits ptr

The first one concerns almost all unixes. The second is relevant in Irix 6
and on alphas. Other probably exist but are an order of magnitude less
present. Besides, the probability is high that most of the code works
if sizeof(T *)<=sizeof(NULL). This depends on parameter-passing conventions.
Code can't work with sizeof(T *)>sizeof(NULL).

If your vision of "deprecating NULL" is "let users having their code working
right now but crashing randomly when they eventually have the money to buy
a 64bits processor" then yes, define NULL as 0. If you want to be as nice as
possible to the user while not changing the compiler, define it as 0L. If you
really want to deprecate it define it at __null, make it behave the right way
w.r.t type conversions and warn when used as parameter in a varadic function
or in constructions like "int a=NULL;".

  OG.

Re: [ECGS] linux libio status

[chip]

According to Olivier Galibert:
> The current existing architectures I know about are:
> - 32bits int, 32bits long, 64bits long long, 32bits ptr
> - 32bits int, 64bits long, 64bits long long, 64bits ptr

You're deluding yourself if you're making decisions based on this
limited idea of what constitutes a reasonable set of int sizes.
-- 
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Re: linux libio status

[Joe Buck]

> > Conclusion: we should deprecate the use of NULL in C++ code.  If we
> > must define NULL for C++ code, it must be 0.  Nothing else.
> 
> 
> You say "make sure that current code works but randomly crashes when the
> users upgrade to new 64bits architectures". I don't call that being
> fair to the user.

Stop putting words in my mouth.  Since my C++ code has to run with
multiple compilers, I never use NULL and, on those rare occasions where
I must use a variadic function, I pass a null pointer of the right type.

What's unfair to the user is to tell the user he/she can use NULL in
any position where a pointer is required in C++ code.  The problem is
that there is no definition that will work correctly and portably with
variadic functions.  (But then, variadic functions are a bad idea, as
their arguments can't be type-checked at compile time except by special
means, like the gcc printf hack.  Furthermore, they are rare except for
the printf family, and gcc has a special check for those).

> If your vision of "deprecating NULL" is "let users having their code working
> right now but crashing randomly when they eventually have the money to buy
> a 64bits processor" then yes, define NULL as 0.

So Stroustrup doesn't know what he's talking about?  So every C++ author
in the book doesn't know either?  For variadic functions that want a
pointer, 0L is just as broken as 0; on certain memory models for 16-bit
PC code, you will corrupt your stack (a near pointer, only 16 bits, is
expected and you push a four-byte quantity).

There's no substitute for programming correctly.

Re: linux libio status

[Olivier Galibert]

On Wed, Oct 15, 1997 at 11:43:02AM -0700, Joe Buck wrote:
> There's no substitute for programming correctly.

I think I wasn't clear enough.

I completely agree with 95% of what you said. The only point
I disagree with is "we must #define NULL 0 because Stroustrup
said so".

Without adding special support for a __null keyword or whatever,
we have only two reasonable possibilities for NULL which are 0
and 0L.

The choice between them is without a real impact except in the
case of passing NULL in a varadic function call with the old
C meaning (void *)0. Telling "Thou shan't use NULL in such calls"
is irrelevant. I know better than using them, but we're in the
real world and anyway it was perfectly valid one or two
years ago when implicitely converting from (void *) wasn't yet
ruled out. Which means we have a lot of code floating around
which requires passing such a NULL to work. Just for the record
xemacs was in this case some months ago.

Now, what should we do ? We can't without additional support warn
for such code. Besides, would we be able to warn that we could be
_sure_ to do the Right Thing in all cases, i.e. implicitely use
a (void *)0. I don't think gcc supports multisized pointers anyway.
We can't even make a choice which will lend to crashes in most of
the current platforms since they are 32/32/32 (int/long/pointer)
and the distinction between int and long doesn't exist in our case.

Given this situation I really think that the only fair approach is
the ensure that for most of the people the code will keep working
in the future.

Now, the new architectures are 32/32/64, 32/64/32 and 32/64/64.
32/32/64 is hosed, both choices will lend to crashes.
32/64/32 will almost always work with NULL=0, and will work on
         a lot of architectures with NULL=0L.
32/64/64 (which are the irix 6 and dec alpha cases, I know no
         real-world implementations of the previous two) will
         almost always work with NULL=0L and never work with
         NULL=0.

The "almost always" comes from the fact that some calling conventions
separate "data" and "pointers" and so no integer type will do for
a pointer.

This means we have the choice between using 0 and crashing badly
on current 64bits architectures but working on some weird ones,
or using 0L and working on these real architectures while keeping
a fair chance to work on the weird ones.

Conclusion: we're here to help people make programs, not implementing
            language non-normative politics.

  OG.

Re: linux libio status

[Pal Engstad]

Olivier Galibert wrote:
> Conclusion: we're here to help people make programs, not implementing
>             language non-normative politics.
> 

Following this thread, the discussion is on the macro NULL. From the 
Draft working paper it is said:

C.4.2.3 Macro NULL

1 The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, 
<cstring>, <ctime>t, or <cwchar>, is an implementation-defined C++ 
null-pointer constant in this International Standard (18.1) 254)

254) Possible definitions include 0 and 0L, but not (void *)0.

Given this, it is evident that the choise is either 0 or 0L. I believe
it should be given in accordance with what fits best with the 
architecture it is on. I.e.: If the target has 32 bit int and 32 bit
pointers, it should be 0. If the target has 64 bit longs and 64 bit 
pointers it should be 0L, and so on.

PKE.

Re: linux libio status

[Jason Merrill]

>>>>> Peter Seebach <seebs@monolith.solon.com> writes:

> In message < 19971015095211.03621@renaissance.loria.fr >, Olivier Galibert writes
> :
>> On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote:
>>> 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*).

>> Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
>> when int=32b and pointer=64b.

> Assuming, of course, that 0L is 64 bits.  Rumor has it that some
> implementations chose to make int and long 32, pointer 64, and
> (cough) "long long" 64.

> Further, what of an implementation where long is *larger* than a
> pointer, but int is the same size?  Then you need 0, not 0L...

This is why we have a NULL macro.  The gcc stddef.h provides an appropriate
definition, so we can put

#undef NULL
#define __need_NULL
#include <stddef.h>
#undef __need_NULL

somewhere strategic, and that should do the trick.

> It would have been a little easier if C89 had ruled that NULL must
> actually have pointer type, then you could just use it for anything
> that would be taking arguments as (void *), and, if you're feeling
> courageous and not-quite-perfectly-portable, you could just use it
> for all the pointers...

C89 may not have, but gcc defines it that way.

Jason

Re: linux libio status

[Peter Seebach]

In message < u9zpoarh0w.fsf@yorick.cygnus.com >, Jason Merrill writes:
>This is why we have a NULL macro.  The gcc stddef.h provides an appropriate
>definition, so we can put

>#undef NULL
>#define __need_NULL
>#include <stddef.h>
>#undef __need_NULL

>somewhere strategic, and that should do the trick.

Well, strictly speaking, I don't think that's correct - I *believe* a
user who has not included <stddef.h> is allowed to assume that not everything
in it is defined.  I think an implementation is obliged to have the common
declaration of NULL, if there is one, be in some other header included by
<stddef.h> and friends.

>C89 may not have, but gcc defines it that way.

Well, yeah, but that's not very useful to a person writing code not
exclusively for use with one compiler... :)

-s

Re: linux libio status

[Jason Merrill]

>>>>> Peter Seebach <seebs@monolith.solon.com> writes:

> In message < u9zpoarh0w.fsf@yorick.cygnus.com >, Jason Merrill writes:

>> This is why we have a NULL macro.  The gcc stddef.h provides an appropriate
>> definition, so we can put

>> #undef NULL
>> #define __need_NULL
>> #include <stddef.h>
>> #undef __need_NULL

>> somewhere strategic, and that should do the trick.

> Well, strictly speaking, I don't think that's correct - I *believe* a
> user who has not included <stddef.h> is allowed to assume that not everything
> in it is defined.

That's why we define __need_NULL.  That tells the gcc stddef.h that we only
want the definition of NULL, and nothing else.

Jason

Re: linux libio status

[Peter Seebach]

In message < u9oh4q46ox.fsf@yorick.cygnus.com >, Jason Merrill writes:
>That's why we define __need_NULL.  That tells the gcc stddef.h that we only
>want the definition of NULL, and nothing else.

Isn't that an order of magnitude more complicated than providing
<null.h>, and having everything that needs NULL include it?

-s

Re: linux libio status

[Jason Merrill]

>>>>> Peter Seebach <seebs@monolith.solon.com> writes:

> In message < u9oh4q46ox.fsf@yorick.cygnus.com >, Jason Merrill writes:
>> That's why we define __need_NULL.  That tells the gcc stddef.h that we only
>> want the definition of NULL, and nothing else.

> Isn't that an order of magnitude more complicated than providing
> <null.h>, and having everything that needs NULL include it?

Do you also want to provide <size_t.h>, <ptrdiff_t.h>, <wchar_t.h> and
<wint_t.h>?  It doesn't seem excessively complicated to me, since the user
doesn't have to deal with it and we only have to do it once.

Jason

Re: linux libio status

[Peter Seebach]

In message < u9iuux4tpv.fsf@yorick.cygnus.com >, Jason Merrill writes:
>> Isn't that an order of magnitude more complicated than providing
>> <null.h>, and having everything that needs NULL include it?

>Do you also want to provide <size_t.h>, <ptrdiff_t.h>, <wchar_t.h> and
><wint_t.h>?  It doesn't seem excessively complicated to me, since the user
>doesn't have to deal with it and we only have to do it once.

Hmm.  I would have to actually go look up where else each of those is
defined...

In general, I think at least half of it isn't even the namespace, but
just intrinsic distrust of a scheme where one header makes use of a
clearly magic internal of another header... Dangerous magic, that.

(It's probably also mildly inefficient, but on modern machines, who
cares if one compiler is three times as slow as another?)

-s

Re: linux libio status

[Paul Koning]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

>>>>> Peter Seebach <seebs@monolith.solon.com> writes:
Peter >> It would have been a little easier if C89 had ruled that NULL must
Peter >> actually have pointer type, then you could just use it for
Peter >> anything that would be taking arguments as (void *), and, if
Peter >> you're feeling courageous and not-quite-perfectly-portable, you
Peter >> could just use it for all the pointers...

 Jason> C89 may not have, but gcc defines it that way.

Hm...  I have seen some "code" that contains statements of the form:

	int i = NULL;

and while I wouldn't want to work anywhere near the "programmer" who
wrote that, it does appear to compile with some of the compilers that
are currently out in the world...

	paul