Also return "1" rather than "-1". According to bde: -1 is unrepresentable.
Exit statuses must be >= 0 and <= 255, at least if chars are 8 bits and
shorts are 16 bits. This seems to only be documented indirectly in exit.2
by referring to wait.2. WEXITSTATUS() throws away all except the low 8 bits
of the status returned by _exit(), and the kernel actually only stores 8
bits of it (if chars are 8 bits, etc.), so wait() can't return any more bits.
Obtained from: rev 1.4 of contrib/gcc/gcc.c
if compiling with -fformat-extensions). Gcc's format checker never
actually supported %q length specifiers. It treats %q as an alias
for %ll, which is correct if quad_t is long long (e.g., on i386's)
and broken otherwise (e.g., on alphas).
quad_t's currently should be printed in the same way that they
already need to be printed to avoid compiler warnings on all
supported systems: cast them to a standard type that is at least
as large (long or long long) and use the length specifier for that
(%l or %ll). This is problematic since long long isn't standard
yet. C9x's intmax_t should be implemented soon.
Don't accept %L length specifiers in the kernel either. The only
legitimate ones are for long doubles, but the kernel doesn't even
support plain doubles. (gcc bogusly accepts %Ld as an alias for
%lld, and it sometimes prints "q" in error messages about "ll" and
"L" length specifiers, becauses it represents all these specifiers
as 'q'.)
Submitted by: bde
- plain %r and %z were disallowed. The hard NULs in the warnings were
hopefully caused by disallowing of plain formats being nonsense.
- new formats for shortening to a byte were allowed, but even the libc
printf doesn't support them.
- old %hr and %hz formats were allowed, but the kernel printf doesn't
support them. The kernel doesn't support %hd either, but this is
harder to fix.
Submitted by: bde
* Consistantly put spaces after "," in macro param lists
* Consistantly align continuation characters.
* Don't need to supply all variations of __FOO__ in CPP_PREDEFINES,
gcc will do that for us.
Our malloc can allocte pagesized blocks efficiently and the EGCS default size
of 4072 bytes is not optimal.
Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
in libstdc++.
Until I have a chance to look at what that problem is and to carefully consider
the upgrade issues of turning it back on at a later date if we leave it turned
off for any extended peroid of time.
While I have yet to hear of any problems with us using thunks. The EGCS
mailing list notes some have problems with it and not using them are a
safer default. People wanting to use them, can set the appropiate
compiler flag.
* Turn on DEFAULT_VTABLE_THUNKS. (it is the default anyway, I'm just being
explicit about it, in case it causes us trouble it might be easier for
someone to notice it this way)
David E. O'Brien
Hidetoshi Shimokawa
John Polstra
Bruce Evans
cvs2svn
Poul-Henning Kamp
Peter Wemm
Martin Cracauer