Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,>
From: Alan Barrett <email@example.com>
Date: 06/20/2005 12:03:49
On Fri, 17 Jun 2005, Christos Zoulas wrote:
> I don't think so either, but when you ask the compiler to call printf(),
> and it calls puts() because it `knows' it is better, what else are you
> left with?
In my opinion, the compiler should decide whether or not it is
allowed to convert printf("%s",foo) to puts(foo) [and similarly with
fprintf/fputs] depending on what standards you told the compiler that
the code was intended to conform to.
For example, if you tell the compiler that the code conforms to the
hosted environment defined in ANSI/ISO 9899:1989, then the compiler
can know that printf("%s",NULL) invokes undefined behaviour, and the
programmer shouldn't care whether the undefined behaviour results in a
core dump or in the string "(null)" being printed.
I suggest the following actions:
1. Accept the fact that programs that expect printf("%s", NULL)
to print "(null)" are relying on a particular historical
interpretation of behaviour that is undefined by recent standards.
2. As a temporary hack, change gcc to never perform the printf/puts
conversion that is causing trouble for the programs identified in
(1). Alternatively, change gcc to perform the conversion only if
it can prove to itself that the string will not be null.
3. Fix gcc to make it perform or not perform the printf/puts
conversion depending on what combination of "-std=<standard>",
"-ansi", "-pedantic", "-ffreestanding" and similar options were
specified. Possibly also add a "-fno-convert-printf-to-puts" or
4. Make the programs identified in (1) pass appropriate flags to the
compiler fixed in (2) so that they do get the historical "(null)"
5. Once (4) has been done, the temporary hack in (2) can be removed.
6. In the long term, change the programs identified in (1) so that
they do not attempt to invoke undefined behaviour from printf.
--apb (Alan Barrett)