--QTprm0S8XgL7H0Dt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 17, 2005 at 09:42:00AM -0700, Greywolf wrote:
> [Thus spake Christos Zoulas ("CZ: ") 9:25am...]
>=20
> CZ: I am fine with disabling the optimization, but as I said, it will make
> CZ: our compiler different. I would rather convince the gcc team to consi=
der
> CZ: turning the bogus behavior off permanently.

I like that idea best, however the problem is that the current compiler=20
will be out there for a while, and so we will still need to do something=20
to deal with it.

> This egregious behaviour in a compiler is absurd; I think most any other
> standard of a language would classify such a compiler as "broken, not
> to be used until fixed, and to be fixed yesterday."
>=20
> To have puts/fputs spit out "(null)" would be a much better way to handle
> this than to dump core.  I don't think we should have to even cpp::#define
> this based on __gcc_version__ or whatever they call it these days -- when
> they fix the compiler, we revert the code.

I agree that "(null)" is much better than a core dump. As an application=20
programmer, it makes my life MUCH easlier. It also has an advantage of=20
making programs slightly smaller as we have one "(null)" string, not=20
perhaps a thousand.

Unfortunately, though, we can't just have a cpp define. The problem is we=
=20
need to test according to the gcc that compiled the program, not the one=20
that compiled libc. :-(

Take care,

Bill

--QTprm0S8XgL7H0Dt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCswk7Wz+3JHUci9cRAsz0AJ9uu0KsrUMJPw8gZyNviAnIlTH41gCfQLP9
Es8GWS6NjEFAF2jC+quV2B0=
=Nc9Z
-----END PGP SIGNATURE-----

--QTprm0S8XgL7H0Dt--