NetBSD Problem Report #29887
From juan@xtraeme.nopcode.org Tue Apr 5 03:20:38 2005
Return-Path: <juan@xtraeme.nopcode.org>
Received: from xtraeme.nopcode.org (91.Red-80-32-6.pooles.rima-tde.net [80.32.6.91])
by narn.netbsd.org (Postfix) with ESMTP id 31F7263B11F
for <gnats-bugs@gnats.NetBSD.org>; Tue, 5 Apr 2005 03:20:38 +0000 (UTC)
Message-Id: <20050405032037.4E49A598A@xtraeme.nopcode.org>
Date: Tue, 5 Apr 2005 05:20:37 +0200 (CEST)
From: juan@xtraeme.nopcode.org
Reply-To: juan@xtraeme.nopcode.org
To: gnats-bugs@netbsd.org
Subject: sysctl kern.consdev coredumps
X-Send-Pr-Version: 3.95
>Number: 29887
>Category: port-xen
>Synopsis: sysctl kern.consdev coredumps
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: port-xen-maintainer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Apr 05 03:21:00 +0000 2005
>Closed-Date: Wed Apr 06 21:09:12 +0000 2005
>Last-Modified: Fri Jun 24 07:21:00 +0000 2005
>Originator: Juan RP
>Release: NetBSD 3.99.3
>Organization:
>Environment:
System: NetBSD Mandylion 3.99.3 NetBSD 3.99.3 (XEN_GW_DOM0) #0: Tue Apr 5 01:00:27 CEST 2005 juan@Nocturno:/home/juan/build/obj/sys/arch/i386/compile/XEN_GW_DOM0 i386
Architecture: i386
Machine: i386
>Description:
Running sysctl kern.consdev in a domU results in a coredump:
[juan@XenU_0][~]> sysctl kern.consdev
zsh: segmentation fault (core dumped) sysctl kern.consdev
[juan@XenU_0][~]>
ktrace:
10711 sysctl RET pread 4096/0x1000
10711 sysctl CALL __sysctl(0xbfbfcd00,1,0x8068800,0xbfbfca8c,0xbfbfca90,0x60)
10711 sysctl RET __sysctl -1 errno 12 Cannot allocate memory
10711 sysctl CALL break(0x806b000)
10711 sysctl RET break 0
10711 sysctl CALL __sysctl(0xbfbfcd00,1,0x806a000,0xbfbfca8c,0xbfbfca90,0x60)
10711 sysctl RET __sysctl 0
10711 sysctl CALL break(0x806d000)
10711 sysctl RET break 0
This domU has 240MB and 512MB for swap space.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 21:23:03 +0200
On Tue, Apr 05, 2005 at 03:21:00AM +0000, juan@xtraeme.nopcode.org wrote:
>
> Running sysctl kern.consdev in a domU results in a coredump:
>
> [juan@XenU_0][~]> sysctl kern.consdev
> zsh: segmentation fault (core dumped) sysctl kern.consdev
> [juan@XenU_0][~]>
Hi,
Can you check if this is fixed by
cd /dev
sh MAKEDEV xencons
The default install doesn't create /dev/xencons, I have a patch to fix this.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Juan RP <juan@xtraeme.nopcode.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 21:36:10 +0200
On Wed, 6 Apr 2005 21:23:03 +0200
Manuel Bouyer <bouyer@antioche.eu.org> wrote:
> Hi,
> Can you check if this is fixed by
> cd /dev
> sh MAKEDEV xencons
>
> The default install doesn't create /dev/xencons, I have a patch to fix this.
[juan@XenUN][~]> ls -l /dev/xencons
crw------- 1 root wheel 143, 0 Apr 6 21:35 /dev/xencons
[juan@XenUN][~]> sysctl kern.consdev
zsh: segmentation fault (core dumped) sysctl kern.consdev
[juan@XenUN][~]>
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Juan RP <juan@xtraeme.nopcode.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 22:19:44 +0200
On Wed, Apr 06, 2005 at 09:36:10PM +0200, Juan RP wrote:
> On Wed, 6 Apr 2005 21:23:03 +0200
> Manuel Bouyer <bouyer@antioche.eu.org> wrote:
>
> > Hi,
> > Can you check if this is fixed by
> > cd /dev
> > sh MAKEDEV xencons
> >
> > The default install doesn't create /dev/xencons, I have a patch to fix this.
>
> [juan@XenUN][~]> ls -l /dev/xencons
> crw------- 1 root wheel 143, 0 Apr 6 21:35 /dev/xencons
> [juan@XenUN][~]> sysctl kern.consdev
> zsh: segmentation fault (core dumped) sysctl kern.consdev
> [juan@XenUN][~]>
Did you run dev_mkdb ?
Note that on my test box, without /dev/xencons I get:
comore# sysctl kern.consdev
kern.consdev = (null)
not a core dump
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc: port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 21:33:46 +0100
> Note that on my test box, without /dev/xencons I get:
> comore# sysctl kern.consdev
> kern.consdev = (null)
> not a core dump
but probably only because printf("%s", NULL) outputs "(null)" which
it isn't required to do at all - and arguably shouldn't.
David
--
David Laight: david@l8s.co.uk
From: "Juan RP" <juan@xtraeme.nopcode.org>
To: "Manuel Bouyer" <bouyer@antioche.eu.org>
Cc: <gnats-bugs@NetBSD.org>
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 22:33:31 +0200
----- Original Message -----
From: "Manuel Bouyer" <bouyer@antioche.eu.org>
To: "Juan RP" <juan@xtraeme.nopcode.org>
Cc: <gnats-bugs@NetBSD.org>
Sent: Wednesday, April 06, 2005 10:19 PM
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
> Did you run dev_mkdb ?
> Note that on my test box, without /dev/xencons I get:
> comore# sysctl kern.consdev
> kern.consdev = (null)
> not a core dump
Ahh, running dev_mkdb fixed the problem, now it works fine:
[juan@XenUN][~]> sysctl kern.consdev
kern.consdev = xencons
[juan@XenUN][~]>
Thanks.
From: christos@zoulas.com (Christos Zoulas)
To: Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, atatat@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 16:33:42 -0400
On Apr 6, 9:23pm, bouyer@antioche.eu.org (Manuel Bouyer) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| On Tue, Apr 05, 2005 at 03:21:00AM +0000, juan@xtraeme.nopcode.org wrote:
| >
| > Running sysctl kern.consdev in a domU results in a coredump:
| >
| > [juan@XenU_0][~]> sysctl kern.consdev
| > zsh: segmentation fault (core dumped) sysctl kern.consdev
| > [juan@XenU_0][~]>
|
| Hi,
| Can you check if this is fixed by
| cd /dev
| sh MAKEDEV xencons
|
| The default install doesn't create /dev/xencons, I have a patch to fix this.
|
This should be assigned to atatat@netbsd.org. It should not coredump anyway.
christos
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Juan RP <juan@xtraeme.nopcode.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 22:37:29 +0200
On Wed, Apr 06, 2005 at 10:33:31PM +0200, Juan RP wrote:
>
> ----- Original Message -----
> From: "Manuel Bouyer" <bouyer@antioche.eu.org>
> To: "Juan RP" <juan@xtraeme.nopcode.org>
> Cc: <gnats-bugs@NetBSD.org>
> Sent: Wednesday, April 06, 2005 10:19 PM
> Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
>
>
> >Did you run dev_mkdb ?
> >Note that on my test box, without /dev/xencons I get:
> >comore# sysctl kern.consdev
> >kern.consdev = (null)
> >not a core dump
>
> Ahh, running dev_mkdb fixed the problem, now it works fine:
>
> [juan@XenUN][~]> sysctl kern.consdev
> kern.consdev = xencons
> [juan@XenUN][~]>
>
> Thanks.
OK. I'm commiting the change to create /dev/xencons at install time.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, atatat@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Wed, 6 Apr 2005 23:07:19 +0200
On Wed, Apr 06, 2005 at 04:33:42PM -0400, Christos Zoulas wrote:
> On Apr 6, 9:23pm, bouyer@antioche.eu.org (Manuel Bouyer) wrote:
> -- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
>
> | On Tue, Apr 05, 2005 at 03:21:00AM +0000, juan@xtraeme.nopcode.org wrote:
> | >
> | > Running sysctl kern.consdev in a domU results in a coredump:
> | >
> | > [juan@XenU_0][~]> sysctl kern.consdev
> | > zsh: segmentation fault (core dumped) sysctl kern.consdev
> | > [juan@XenU_0][~]>
> |
> | Hi,
> | Can you check if this is fixed by
> | cd /dev
> | sh MAKEDEV xencons
> |
> | The default install doesn't create /dev/xencons, I have a patch to fix this.
> |
>
> This should be assigned to atatat@netbsd.org. It should not coredump anyway.
Agreed. I've opended another PR for this.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
State-Changed-From-To: open->closed
State-Changed-By: bouyer@netbsd.org
State-Changed-When: Wed, 06 Apr 2005 21:09:12 +0000
State-Changed-Why:
I changed MAKEDEV to create /dev/xencons at install time, and will request
a pullup.
From: Andrew Brown <atatat@atatdot.net>
To: Christos Zoulas <christos@zoulas.com>
Cc: Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 7 Apr 2005 09:06:38 -0400
On Wed, Apr 06, 2005 at 04:33:42PM -0400, Christos Zoulas wrote:
>On Apr 6, 9:23pm, bouyer@antioche.eu.org (Manuel Bouyer) wrote:
>-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
>
>| On Tue, Apr 05, 2005 at 03:21:00AM +0000, juan@xtraeme.nopcode.org wrote:
>| >
>| > Running sysctl kern.consdev in a domU results in a coredump:
>| >
>| > [juan@XenU_0][~]> sysctl kern.consdev
>| > zsh: segmentation fault (core dumped) sysctl kern.consdev
>| > [juan@XenU_0][~]>
>|
>| Hi,
>| Can you check if this is fixed by
>| cd /dev
>| sh MAKEDEV xencons
>|
>| The default install doesn't create /dev/xencons, I have a patch to fix this.
>
>This should be assigned to atatat@netbsd.org. It should not coredump anyway.
indeed! can someone explain this:
% cat > foo.c <<EOF
#include <stdio.h>
int
main(int argc, char *argv[])
{
const void *v;
const char *c;
v = c = NULL;
printf("%p\n", NULL);
printf("%p\n", v);
printf("%p\n", c);
printf("%s\n", NULL);
printf("%s\n", v);
printf("%s\n", c);
return (0);
}
EOF
% cc -O2 foo.c
% ./a.out
0x0
0x0
0x0
(null)
(null)
Segmentation fault (core dumped)
% cc -O1 foo.c
% ./a.out
0x0
0x0
0x0
(null)
(null)
Segmentation fault (core dumped)
% cc -O0 foo.c
% ./a.out
0x0
0x0
0x0
(null)
(null)
(null)
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
werdna@squooshy.com * "information is power -- share the wealth."
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: gnats-bugs@netbsd.org
Cc: port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 07 Apr 2005 22:22:04 +0900
> indeed! can someone explain this:
gcc converts printf to puts.
YAMAMOTO Takashi
From: Love <lha@netbsd.org>
To: Andrew Brown <atatat@atatdot.net>
Cc: Christos Zoulas <christos@zoulas.com>,
Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 07 Apr 2005 15:24:05 +0200
Andrew Brown <atatat@atatdot.net> writes:
> indeed! can someone explain this:
gcc the printf() into a puts()
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 7 Apr 2005 10:48:35 -0400
On Apr 7, 1:07pm, atatat@atatdot.net (Andrew Brown) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
I would say that the proper fix is to make puts(NULL), and fputs(fp, NULL)
behave like printf("%s\n", NULL) and fprintf(fp, "%s", NULL) respectively:
Index: fputs.c
===================================================================
RCS file: /cvsroot/src/lib/libc/stdio/fputs.c,v
retrieving revision 1.13
diff -u -u -r1.13 fputs.c
--- fputs.c 7 Aug 2003 16:43:24 -0000 1.13
+++ fputs.c 7 Apr 2005 14:47:13 -0000
@@ -61,11 +61,11 @@
struct __siov iov;
int r;
- _DIAGASSERT(s != NULL);
_DIAGASSERT(fp != NULL);
+ if (s == NULL)
+ s = "(null)";
- /* LINTED we don't touch s */
- iov.iov_base = (void *)s;
+ iov.iov_base = __UNCONST(s);
iov.iov_len = uio.uio_resid = strlen(s);
uio.uio_iov = &iov;
uio.uio_iovcnt = 1;
Index: puts.c
===================================================================
RCS file: /cvsroot/src/lib/libc/stdio/puts.c,v
retrieving revision 1.12
diff -u -u -r1.12 puts.c
--- puts.c 7 Aug 2003 16:43:29 -0000 1.12
+++ puts.c 7 Apr 2005 14:47:13 -0000
@@ -56,16 +56,15 @@
puts(s)
char const *s;
{
- size_t c = strlen(s);
+ size_t c;
struct __suio uio;
struct __siov iov[2];
int r;
- _DIAGASSERT(s != NULL);
-
- /* LINTED we don't touch the string */
- iov[0].iov_base = (void *)s;
- iov[0].iov_len = c;
+ if (s == NULL)
+ s = "(null)";
+ iov[0].iov_base = __UNCONST(s);
+ iov[0].iov_len = c = strlen(s);
iov[1].iov_base = "\n";
iov[1].iov_len = 1;
uio.uio_resid = c + 1;
From: Andrew Brown <atatat@atatdot.net>
To: Love <lha@NetBSD.org>
Cc: Christos Zoulas <christos@zoulas.com>,
Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 7 Apr 2005 19:07:27 -0400
On Thu, Apr 07, 2005 at 03:24:05PM +0200, Love wrote:
>
>Andrew Brown <atatat@atatdot.net> writes:
>
>> indeed! can someone explain this:
>
>gcc the printf() into a puts()
ick. okay, i'll do something ugly in retaliation...
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
werdna@squooshy.com * "information is power -- share the wealth."
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 08 Apr 2005 11:38:48 +0900
> I would say that the proper fix is to make puts(NULL), and fputs(fp, NULL)
> behave like printf("%s\n", NULL) and fprintf(fp, "%s", NULL) respectively:
i'd say the proper fix is:
- change the callers of printf not to expect printf("%s\n", NULL) work.
- and disable the optimization in gcc.
YAMAMOTO Takashi
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 00:56:09 +0900
if no one objects, i will:
- add some note to printf(3) to discourage the use of "(null)".
- remove code to produce the "(null)" from wprintf and friends.
- and disable the optimization in in-tree gcc.
YAMAMOTO Takashi
From: christos@zoulas.com (Christos Zoulas)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 16 Jun 2005 12:05:08 -0400
On Jun 17, 12:56am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| if no one objects, i will:
|
| - add some note to printf(3) to discourage the use of "(null)".
| - remove code to produce the "(null)" from wprintf and friends.
This has been historical practice since the mid 80's. People expect *printf(3)
to print (null) when you pass it a null string. It is a lot better to print
(null) than to core-dump... Trust me, I remember how it was back then.
| - and disable the optimization in in-tree gcc.
This will just muddle the waters even further. Imagine when a poor
sod compiles a new version of gcc and some code randomly core-dumps
with the new gcc where it works with the in-tree gcc. I.e. "Our"
gcc will be different than the rest of the world. I may disagree
with the optimization, but this is the de-facto gcc behavior.
In short, I oppose all three changes. I still think that changing
puts and fputs to behave like printf() is a saner choice. I would
prefer if core voted for it, and since I am in core, I will abstain
from this one.
christos
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 21:11:49 +0900
> | if no one objects, i will:
> |
> | - add some note to printf(3) to discourage the use of "(null)".
> | - remove code to produce the "(null)" from wprintf and friends.
>
> This has been historical practice since the mid 80's. People expect *printf(3)
> to print (null) when you pass it a null string. It is a lot better to print
> (null) than to core-dump... Trust me, I remember how it was back then.
>
> | - and disable the optimization in in-tree gcc.
>
> This will just muddle the waters even further. Imagine when a poor
> sod compiles a new version of gcc and some code randomly core-dumps
> with the new gcc where it works with the in-tree gcc. I.e. "Our"
> gcc will be different than the rest of the world. I may disagree
> with the optimization, but this is the de-facto gcc behavior.
because gcc's "optimization" conflicts with printf's histrical practice,
we need to give up at least either of them.
> In short, I oppose all three changes. I still think that changing
> puts and fputs to behave like printf() is a saner choice. I would
> prefer if core voted for it, and since I am in core, I will abstain
> from this one.
>
> christos
adding a hack to libc for the broken compiler is saner?
i don't think so.
the fundamental problem is that gcc ignores the well-known but non-standard
behaviour of printf. fixing gcc is the right fix.
IMO, changing puts is the worst choice because it introduces
another non-standard extension.
no surprise if a future version of gcc break it. :-)
YAMAMOTO Takashi
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 14:34:49 +0200
YAMAMOTO Takashi wrote:
> i'd say the proper fix is:
> - change the callers of printf not to expect printf("%s\n", NULL) work.
> - and disable the optimization in gcc.
I'd say the former is enough. Historical practise or not, good code should
not rely on NULL pointers passed to printf to work. Maybe a note in the man
page, explaining the historical practice and the depreciation.
Neither gcc nor printf need to be changed, if we fix all callers.
Martin
From: christos@zoulas.com (Christos Zoulas)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 09:25:56 -0400
On Jun 17, 9:11pm, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| adding a hack to libc for the broken compiler is saner?
| i don't think so.
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?
| the fundamental problem is that gcc ignores the well-known but non-standard
| behaviour of printf. fixing gcc is the right fix.
|
| IMO, changing puts is the worst choice because it introduces
| another non-standard extension.
| no surprise if a future version of gcc break it. :-)
I am fine with disabling the optimization, but as I said, it will make
our compiler different. I would rather convince the gcc team to consider
turning the bogus behavior off permanently.
christos
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 09:31:33 -0400
On Jun 17, 12:35pm, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| > i'd say the proper fix is:
| > - change the callers of printf not to expect printf("%s\n", NULL) work.
| > - and disable the optimization in gcc.
|
| I'd say the former is enough. Historical practise or not, good code should
| not rely on NULL pointers passed to printf to work. Maybe a note in the man
| page, explaining the historical practice and the depreciation.
|
| Neither gcc nor printf need to be changed, if we fix all callers.
No, this is not enough. You also need to fix all fprintf(fp, "%s", NULL);
which get converted to fputs(NULL, fp); Where does this stop? How can
you make sure that new code works? This is why you either need to fix the
compiler or the library or both.
christos
From: Greywolf <greywolf@starwolf.com>
To: Christos Zoulas <christos@zoulas.com>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 09:42:00 -0700 (PDT)
[Thus spake Christos Zoulas ("CZ: ") 9:25am...]
CZ: I don't think so either, but when you ask the compiler to call printf(),
CZ: and it calls puts() because it `knows' it is better, what else are you
CZ: left with?
It was once said that "programmers should avoid chumminess with the
compiler." Richie or Kernighan. I think it applies in parallel to the
compiler, in that the compiler should avoid chumminess with the programmer
by "knowing" what would be more efficient in this situation, UNLESS THE
PROGRAMMER EXPLICITLY REQUESTS SUCH OPTIMIZATION, say somewhere around
-O9 (IMO).
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 consider
CZ: turning the bogus behavior off permanently.
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."
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.
--*greywolf;
--
From: Bill Studenmund <wrstuden@netbsd.org>
To: Greywolf <greywolf@starwolf.com>
Cc: Christos Zoulas <christos@zoulas.com>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 10:32:43 -0700
--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--
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Sat, 18 Jun 2005 03:04:10 +0900
> I am fine with disabling the optimization, but as I said, it will make
> our compiler different. I would rather convince the gcc team to consider
> turning the bogus behavior off permanently.
i agree that it's ideal to convince the gcc team.
although i think it's difficult, reading the comment on the bug report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685
IMO, in this case, being different is fine.
if a user installs a broken compiler by himself,
he'll get a broken compiler. there is no difference from
the case of arbitrary broken software.
YAMAMOTO Takashi
From: James Chacon <jmc@NetBSD.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 13:20:39 -0500
On Sat, Jun 18, 2005 at 03:04:10AM +0900, YAMAMOTO Takashi wrote:
> > I am fine with disabling the optimization, but as I said, it will make
> > our compiler different. I would rather convince the gcc team to consider
> > turning the bogus behavior off permanently.
>
> i agree that it's ideal to convince the gcc team.
> although i think it's difficult, reading the comment on the bug report.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685
>
> IMO, in this case, being different is fine.
> if a user installs a broken compiler by himself,
> he'll get a broken compiler. there is no difference from
> the case of arbitrary broken software.
>
Being different is not fine if it changes gcc behavior. We don't provide
netbsd-cc on boxes. We provide something claiming to be "gcc". Therefore it
needs to behave as gcc does, warts and all. Any fix for us should be
in making puts deal w. NULL and marking it as XXGCC and then pursuing with
the gcc maintainers that printf->puts translations shouldn't happen unless
a user explicitly enables it with some -f option (ala not part of some -O).
The bug you cite doesn't discuss that. It's simply noting that
printf("%s", NULL) is undefined behavior so basically they're allowed to core
dump there even on translations to puts().
James
From: Greywolf <greywolf@starwolf.com>
To: Bill Studenmund <wrstuden@NetBSD.org>
Cc: Christos Zoulas <christos@zoulas.com>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 12:40:13 -0700 (PDT)
[Thus spake Bill Studenmund ("BS: ") 10:32am...]
BS: Unfortunately, though, we can't just have a cpp define. The problem is we
BS: need to test according to the gcc that compiled the program, not the one
BS: that compiled libc. :-(
Yeah, there's that, too. Note that I was NOT advocating a cpp::#define
(unless it's an "#if 0" that we could easily rip out) -- that's an
egregious hack to work around an egregious hack. I was merely suggesting
that we code around it pro tempore, reverting the code when the compiler
became unbroken.
It's not a bad thing to be able to request explicitly, but for
printf(literal-with-no-formatting) to "upgrade" itself to puts() WITHOUT
explicitly being requested, though, that's just wrong.
--*greywolf;
--
From: Greywolf <greywolf@starwolf.com>
To: James Chacon <jmc@NetBSD.org>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 12:49:00 -0700 (PDT)
[Thus spake James Chacon ("JC: ") 1:20pm...]
JC: The bug you cite doesn't discuss that. It's simply noting that
JC: printf("%s", NULL) is undefined behavior so basically they're allowed
JC: to core dump there even on translations to puts().
This is confusing: Why does printf("%s", NULL) attempt to translate
into puts() (or am I misreading something here)?
I can see it doing so on literals with no formatting...
If printf() with a NULL dumps core, AND f?puts() with a NULL dumps core,
well, this is certainly no different than it was when I was programming
for my CS class.
I also don't see what "(null)" really buys, as more often than not I run
into dereferencing objects which don't point to NULL, but rather to
someplace in West Hyperspace. I guess it's good for catching the id[10].t
cases where one forgets to assign/test values of pointers (although vars
in subroutines are not guaranteed to be initialised to zero...hence my
comment...).
Sorry for distracting.
--*greywolf;
--
From: Martin Husemann <martin@duskware.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 23:03:46 +0200
On Fri, Jun 17, 2005 at 01:20:39PM -0500, James Chacon wrote:
> The bug you cite doesn't discuss that. It's simply noting that
> printf("%s", NULL) is undefined behavior [..]
Which, IMHO, we should avoid in our code. How to catch it easily is an
open question.
Martin
From: James Chacon <jmc@NetBSD.org>
To: Martin Husemann <martin@duskware.de>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 16:10:55 -0500
On Fri, Jun 17, 2005 at 11:03:46PM +0200, Martin Husemann wrote:
> On Fri, Jun 17, 2005 at 01:20:39PM -0500, James Chacon wrote:
> > The bug you cite doesn't discuss that. It's simply noting that
> > printf("%s", NULL) is undefined behavior [..]
>
> Which, IMHO, we should avoid in our code. How to catch it easily is an
> open question.
I do agree w. Christos here that if historically our printf has returned
(null) here that should probably be the behavior we should continue. The
standard just says this is undefined behavior in that case, not that we have
to abort/core.
James
From: Martin Husemann <martin@duskware.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Sat, 18 Jun 2005 00:03:33 +0200
On Fri, Jun 17, 2005 at 04:10:55PM -0500, James Chacon wrote:
> I do agree w. Christos here that if historically our printf has returned
> (null) here that should probably be the behavior we should continue.
I did not say anything about changing printf. But I do hink that our code
should not rely on this behaviour.
Martin
From: Jason Thorpe <thorpej@shagadelic.org>
To: Greywolf <greywolf@starwolf.com>
Cc: James Chacon <jmc@NetBSD.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 15:28:57 -0700
On Jun 17, 2005, at 12:49 PM, Greywolf wrote:
> [Thus spake James Chacon ("JC: ") 1:20pm...]
>
> JC: The bug you cite doesn't discuss that. It's simply noting that
> JC: printf("%s", NULL) is undefined behavior so basically they're
> allowed
> JC: to core dump there even on translations to puts().
>
> This is confusing: Why does printf("%s", NULL) attempt to translate
> into puts() (or am I misreading something here)?
It is a valid optimization that the compiler is making -- puts() is
faster than printf() because it does not do format expansion.
-- thorpej
From: John Hawkinson <jhawk@MIT.EDU>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Sun, 19 Jun 2005 18:00:28 -0400
[ Reading the more recent discussion, I come back to this message
which I think is still the core point. ]
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Fri, 17 Jun 2005
at 21:11:49 +0900 in <1119010309.563302.4554.nullmailer@yamt.dyndns.org>:
(quoting Christos):
> > In short, I oppose all three changes. I still think that changing
> > puts and fputs to behave like printf() is a saner choice. I would
> > prefer if core voted for it, and since I am in core, I will abstain
> > from this one.
I agree with this -- it sounds like any justification for printing
"(null)" is based on the fact that it is actually used, and there
is no good reason for fputs() to not have the same checking, other than
that puts() is rarely called with NULL.
If this gcc cahnge results in fputs() frequently being called with
NULL, then there is now cause to apply the same checking
to puts().
> IMO, changing puts is the worst choice because it introduces
> another non-standard extension.
> no surprise if a future version of gcc break it. :-)
Anything that gcc rewrites puts() to that core dumps on NULLs is
probably something that should be producing "(null)" anyhow, and only
is not right now because we haven't thought about it.
i.e. a future gcc change that breaks this would be break it by
demonstrating a place where we should have been printing "(null)"
anyhow.
--jhawk
From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 12:03:49 +0200
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
similar option.
4. Make the programs identified in (1) pass appropriate flags to the
compiler fixed in (2) so that they do get the historical "(null)"
behaviour.
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)
From: James Chacon <jmc@NetBSD.org>
To: Alan Barrett <apb@cequrux.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 08:36:06 -0500
On Mon, Jun 20, 2005 at 12:03:49PM +0200, Alan Barrett wrote:
> 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.
Ummm....There's also an expectation from a programmer that when I say
"call function X" I actually meant "call that function" not "simulate calling
that function only to the degree the compiler considers acceptable"
Using your logic above, no implementation can ever extend any standard
defined function. A compiler by your logic could completely supply libc
internally and not call your system supplied one with extentions you may be
depending on.
James
From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 17:28:25 +0200
On Mon, 20 Jun 2005, James Chacon wrote:
> Ummm....There's also an expectation from a programmer that when I say
> "call function X" I actually meant "call that function" not "simulate
> calling that function only to the degree the compiler considers
> acceptable"
When function X is defined by some standard, and the programmer told
the compiler to use that standard, I think it's unreasonable for the
programmer to expect anything like what we conventionally refer to as
a "function call" to occur. Instead, the programmer should expect the
standard-defined effects to occur, and not care whether those effects
happen through compiler magic or through an actual "function call".
> Using your logic above, no implementation can ever extend any standard
> defined function.
No, by my logic, you are free to extend a standard-defined function,
provided you don't attempt to lie to the compiler. Telling the compiler
"This code expects to run in an environment like that defined in
standard A", when in reality the code expects to run in an extension of
that environment, is lying to the compiler. In other words, don't pass
"-std=c99" (or similar) to the compiler if you don't really mean it.
> A compiler by your logic could completely supply libc internally and
> not call your system supplied one with extentions you may be depending
> on.
Yes, a compiler could do that, to the extent permitted by the
standards that you tell the compiler to use. Again, don't tell the
compiler "-std=c99" if you are relying on printf("%s",NULL) to print
"(null)", or if you are relying on any other non-standard extensions to
standard-defined functions.
(Actually, the compiler and the system-supplied libraries are
intended to be tightly integrated, and to cooperate to provide the
execution environment specified by the standards.)
--apb (Alan Barrett)
From: Jachym Holecek <freza@liberouter.org>
To: Alan Barrett <apb@cequrux.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 18:18:05 +0200
Hello,
> > A compiler by your logic could completely supply libc internally and
> > not call your system supplied one with extentions you may be depending
> > on.
>
> Yes, a compiler could do that, to the extent permitted by the
> standards that you tell the compiler to use. Again, don't tell the
> compiler "-std=c99" if you are relying on printf("%s",NULL) to print
> "(null)", or if you are relying on any other non-standard extensions to
> standard-defined functions.
If the standard leaves behaviour as not-strictly-defined, then the compiler
should delegate behaviour to the implementation, ie. compiler is not free
to be smart in such case. So, unless 'fputs(NULL, x)' is defined to behave
the same as 'printf("%s", NULL)', then I'd call blind printf->fputs
substition "not good". IANAL though...
Regards,
-- Jachym Holecek
From: Jason Thorpe <thorpej@shagadelic.org>
To: Alan Barrett <apb@cequrux.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 10:35:22 -0700
On Jun 20, 2005, at 3:03 AM, Alan Barrett wrote:
> 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
> similar option.
GCC already has -ffreestanding to suppress this behavior. If you're
not freestanding, you're hosted, so there is no need for any other
option.
-- thorpej
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 14:27:13 -0400 (EDT)
> GCC already has -ffreestanding to suppress this behavior. If you're
> not freestanding, you're hosted, so there is no need for any other
> option.
I don't get it. You're saying that every hosted environment has
exactly the same set of extensions to standard libraries - the same set
of additional provisions, of semantics defined in cases where the
standard is silent or specifies undefined behaviour?
I can't really make myself believe that; you know better.
But if not, I don't see how you get to the "there is no need..."
conclusion from that premise.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From: Ignatios Souvatzis <is@netbsd.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 21:30:40 +0200
On Mon, Jun 20, 2005 at 06:18:05PM +0200, Jachym Holecek wrote:
> If the standard leaves behaviour as not-strictly-defined, then the compiler
> should delegate behaviour to the implementation, ie. compiler is not free
Ahem. The compiler is part of the implementation.
-is
--
seal your e-mail: http://www.gnupg.org/
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: jhawk@MIT.EDU
Cc: christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 07:17:11 +0900
> I agree with this -- it sounds like any justification for printing
> "(null)" is based on the fact that it is actually used, and there
> is no good reason for fputs() to not have the same checking, other than
> that puts() is rarely called with NULL.
i really think this kind of "suppress coredump" thing is a bad practice.
if you want explicit checks, _DIAGASSERT is for you.
YAMAMOTO Takashi
From: Bill Studenmund <wrstuden@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 15:28:42 -0700
--MfFXiAuoTsnnDAfZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 18, 2005 at 12:03:33AM +0200, Martin Husemann wrote:
> On Fri, Jun 17, 2005 at 04:10:55PM -0500, James Chacon wrote:
> > I do agree w. Christos here that if historically our printf has returned
> > (null) here that should probably be the behavior we should continue.
>=20
> I did not say anything about changing printf. But I do hink that our code
> should not rely on this behaviour.
Why? It's our stdio, and it's done this since before there was a NetBSD.=20
Why shouldn't our code make use of features in our printf()?
Take care,
Bill
--MfFXiAuoTsnnDAfZ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCt0MaWz+3JHUci9cRAiotAKCAb5T+/yt1AFi0lYjHXeR7hJTtywCbBHfA
X1+tbIrUfwafV/QTagmfh4Y=
=TQCW
-----END PGP SIGNATURE-----
--MfFXiAuoTsnnDAfZ--
From: Bill Studenmund <wrstuden@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 16:32:55 -0700
--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2005 at 07:17:11AM +0900, YAMAMOTO Takashi wrote:
> > I agree with this -- it sounds like any justification for printing
> > "(null)" is based on the fact that it is actually used, and there
> > is no good reason for fputs() to not have the same checking, other than
> > that puts() is rarely called with NULL.
>=20
> i really think this kind of "suppress coredump" thing is a bad practice.
> if you want explicit checks, _DIAGASSERT is for you.
I disagree. I think suppressing coredumpes is an excellent idea, where=20
reasonable.
My day job is working on a shipping product. Core dumps are bad. Core=20
dumps generate customer service issues, and impact the reliaility of the=20
product. I would much rather have customers reporting logs like "Error X=20
with client (null)" than passing back stack traces.
I agree that main-path coding shouldn't depend on this, and that it should=
=20
be detecting NULL (and other invalid values) on its own. The place though=
=20
that I find the "(null)" behavior VERY useful, though, is in diagnostic=20
log messages in case of an error. If I get a string I don't understand, I=
=20
can log "I didn't understand %s\n", return an error code, and move on.=20
Without a core dump.
If, however, we reverted this, I'd have to put a chunk of defensive code=20
in all of my error case handling. That would mean lots of duplicated=20
value checking code. And the value checking has, in the code where I=20
implemented it, made the code harder to follow and maintain. I'd rather=20
not make the error case handling code distract from the main flow of the=20
routine.
Take care,
Bill
--kfjH4zxOES6UT95V
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCt1InWz+3JHUci9cRAtB1AJ4gLklErKU0vQcTPvLWpFljAgFrwgCeMeTI
ucxc0m7h/gT5Wbnw4ZgVzAA=
=SGgZ
-----END PGP SIGNATURE-----
--kfjH4zxOES6UT95V--
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: wrstuden@netbsd.org
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 09:04:49 +0900
> > i really think this kind of "suppress coredump" thing is a bad practice.
> > if you want explicit checks, _DIAGASSERT is for you.
>
> I disagree. I think suppressing coredumpes is an excellent idea, where
> reasonable.
>
> My day job is working on a shipping product. Core dumps are bad. Core
> dumps generate customer service issues, and impact the reliaility of the
> product. I would much rather have customers reporting logs like "Error X
> with client (null)" than passing back stack traces.
yes, "(null)" can be useful or dangerous, depending on the calling context.
however, there is no way for a library to know which is the case.
fixing your product is appropriate because you know it's useful there.
YAMAMOTO Takashi
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 20:31:29 -0400
On Jun 21, 12:06am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| > My day job is working on a shipping product. Core dumps are bad. Core
| > dumps generate customer service issues, and impact the reliaility of the
| > product. I would much rather have customers reporting logs like "Error X
| > with client (null)" than passing back stack traces.
|
| yes, "(null)" can be useful or dangerous, depending on the calling context.
| however, there is no way for a library to know which is the case.
| fixing your product is appropriate because you know it's useful there.
I agree with Bill here. Having things core-dump for no reason is
counter-productive. It is one thing to fix all the known instances
of NULL arguments to %s (which one should try to do, but can never
be sure that he caught them all), and another to make puts() and fputs()
behave the same way as our printf/fprintf do in the presence of NULL
pointers. The changes to puts/fputs is for consistency. Of course it
would be nice if the (null) printing behavior was standardized, but
this is not going to happen anytime soon...
christos
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 09:47:29 +0900
> I agree with Bill here. Having things core-dump for no reason is
> counter-productive.
actually, there is a reason.
if your application passes NULL to puts, it has a bug.
IMO, it's a good enough reason to dump core.
continuing processing with unknown state is very dangerous in some cases.
YAMAMOTO Takashi
From: Bill Studenmund <wrstuden@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 17:51:52 -0700
--jCrbxBqMcLqd4mOl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2005 at 09:04:49AM +0900, YAMAMOTO Takashi wrote:
> > > i really think this kind of "suppress coredump" thing is a bad practi=
ce.
> > > if you want explicit checks, _DIAGASSERT is for you.
> >=20
> > I disagree. I think suppressing coredumpes is an excellent idea, where=
=20
> > reasonable.
> >=20
> > My day job is working on a shipping product. Core dumps are bad. Core=
=20
> > dumps generate customer service issues, and impact the reliaility of th=
e=20
> > product. I would much rather have customers reporting logs like "Error =
X=20
> > with client (null)" than passing back stack traces.
>=20
> yes, "(null)" can be useful or dangerous, depending on the calling contex=
t.
> however, there is no way for a library to know which is the case.
> fixing your product is appropriate because you know it's useful there.
But it's not broken.
While you are correct that the library has no way of knowing which of the
two choices it should use, our common practice for printf() has been to
not core dump. We have had that behavior since 4.4BSD, i.e. longer than
there has been a NetBSD. Thus BSD developers decided that not core dumping=
=20
was the better choice overall.
You are the one who is championing making printf() and puts() and friends
core dump when passed NULL. That's changing behavior for printf(). Thus I=
=20
believe you should be explaining to us how this will make our programs=20
better, rather than telling us to change our code.
I agree we should not make system libraries, by default, perform a lot of=
=20
extra input validation. I believe that _DIAGASSERT is fine for them.=20
However I believe that printf() for the '%s' format and puts() are=20
different. I believe we should retain the printf "(null)" behavior and,=20
especially in light of the gcc optimization, we should extend the behavior=
=20
to puts(). And that's it. I believe this as I see printf("%s") being used=
=20
in error-case-logging code in programs, and I feel it is much simpler to=20
let "%s" deal with NULL than to make EVERY caller be defensive.
Take care,
Bill
--jCrbxBqMcLqd4mOl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCt2SoWz+3JHUci9cRAjDWAJ9lxKJL9ftfky7jztf6CdNd02rypACfc/b3
AA7wXTypfd0rD+3hpbWqJp4=
=SZs0
-----END PGP SIGNATURE-----
--jCrbxBqMcLqd4mOl--
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: wrstuden@netbsd.org
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 10:28:00 +0900
> While you are correct that the library has no way of knowing which of the
> two choices it should use, our common practice for printf() has been to
> not core dump. We have had that behavior since 4.4BSD, i.e. longer than
> there has been a NetBSD. Thus BSD developers decided that not core dumping
> was the better choice overall.
>
> You are the one who is championing making printf() and puts() and friends
> core dump when passed NULL. That's changing behavior for printf(). Thus I
> believe you should be explaining to us how this will make our programs
> better, rather than telling us to change our code.
i think you are missing the context. my reply was about puts.
i didn't propose to change the historical behaviour of printf.
it's way too late to change. :(
> I agree we should not make system libraries, by default, perform a lot of
> extra input validation. I believe that _DIAGASSERT is fine for them.
> However I believe that printf() for the '%s' format and puts() are
> different. I believe we should retain the printf "(null)" behavior and,
> especially in light of the gcc optimization, we should extend the behavior
> to puts(). And that's it. I believe this as I see printf("%s") being used
> in error-case-logging code in programs, and I feel it is much simpler to
> let "%s" deal with NULL than to make EVERY caller be defensive.
if you follow gcc (ie. honor compiler's right to do
this kind of optimization), you can't use non-standard extensions anyway.
if you don't follow gcc (ie. disable the optimization),
you don't need to extend the extension to puts.
in either way, i don't see any good reason to propagate
the extention to puts.
YAMAMOTO Takashi
From: Jason Thorpe <thorpej@shagadelic.org>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 19:03:08 -0700
On Jun 20, 2005, at 11:27 AM, der Mouse wrote:
>> GCC already has -ffreestanding to suppress this behavior. If you're
>> not freestanding, you're hosted, so there is no need for any other
>> option.
>>
>
> I don't get it. You're saying that every hosted environment
Hosted environment, in the case of C, means "standard C", AFAIK.
-- thorpej
From: Jason Thorpe <thorpej@shagadelic.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 19:08:31 -0700
On Jun 20, 2005, at 3:17 PM, YAMAMOTO Takashi wrote:
> i really think this kind of "suppress coredump" thing is a bad
> practice.
> if you want explicit checks, _DIAGASSERT is for you.
I agree wholeheartedly.
-- thorpej
From: Bill Studenmund <wrstuden@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 21:11:42 -0700
--WlEyl6ow+jlIgNUh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2005 at 10:28:00AM +0900, YAMAMOTO Takashi wrote:
> > While you are correct that the library has no way of knowing which of t=
he
> > two choices it should use, our common practice for printf() has been to
> > not core dump. We have had that behavior since 4.4BSD, i.e. longer than
> > there has been a NetBSD. Thus BSD developers decided that not core dump=
ing=20
> > was the better choice overall.
> >=20
> > You are the one who is championing making printf() and puts() and frien=
ds
> > core dump when passed NULL. That's changing behavior for printf(). Thus=
I=20
> > believe you should be explaining to us how this will make our programs=
=20
> > better, rather than telling us to change our code.
>=20
> i think you are missing the context. my reply was about puts.
> i didn't propose to change the historical behaviour of printf.
> it's way too late to change. :(
Ahhh... Ok.
The problem though is that thanks to gcc, how puts() behaves is how=20
printf() behaves some of the time. So printf() no longer has its=20
historical behavior.
> > I agree we should not make system libraries, by default, perform a lot =
of=20
> > extra input validation. I believe that _DIAGASSERT is fine for them.=20
> > However I believe that printf() for the '%s' format and puts() are=20
> > different. I believe we should retain the printf "(null)" behavior and,=
=20
> > especially in light of the gcc optimization, we should extend the behav=
ior=20
> > to puts(). And that's it. I believe this as I see printf("%s") being us=
ed=20
> > in error-case-logging code in programs, and I feel it is much simpler t=
o=20
> > let "%s" deal with NULL than to make EVERY caller be defensive.
>=20
> if you follow gcc (ie. honor compiler's right to do
> this kind of optimization), you can't use non-standard extensions anyway.
>=20
> if you don't follow gcc (ie. disable the optimization),
> you don't need to extend the extension to puts.
>=20
> in either way, i don't see any good reason to propagate
> the extention to puts.
You've defined everything in a very black & white manner, and in such a=20
way that both scenarios support your opinion. That's not really a good=20
starting point for an exchange of ideas.
Exactly what puts() does is up to us in the areas of "standards undefined"=
=20
behavior, is it not? So we are free to add "(null)" support as I=20
understand it. I really don't see why we shouldn't. What do you think will=
=20
be broken or what will we lose?
The reality is we will probably have to live with gcc making assumptions=20
for us. And to be honest, if we change puts(), then the assumption gcc=20
makes (that printf("%s\n", x) yields the same effect as puts(x) for all x)=
=20
is once again true.
Take care,
Bill
--WlEyl6ow+jlIgNUh
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCt5N+Wz+3JHUci9cRAkYOAJ9BaCkN9J5FQzwg3xHh+VcoMGnTsACeIky0
3YX2vx8F5/FUSKg0SazsvYc=
=f9Wc
-----END PGP SIGNATURE-----
--WlEyl6ow+jlIgNUh--
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 00:17:17 -0400 (EDT)
> Exactly what puts() does is up to us in the areas of "standards
> undefined" behavior, is it not? So we are free to add "(null)"
> support as I understand it. I really don't see why we shouldn't.
> What do you think will be broken or what will we lose?
The only think I can think of is that it will encourage the gcc
maintainers to do the same thing again in the future.
However, since the consensus, insofar as there is one, seems to be that
this change is a Good Thing, that's probably something NetBSD wants to
encourage. Go for it.
> The reality is we will probably have to live with gcc making
> assumptions for us.
Not if they're curbed sharply now, when this sort of rewriting is still
in its infancy.
> And to be honest, if we change puts(), then the assumption gcc makes
> (that printf("%s\n", x) yields the same effect as puts(x) for all x)
> is once again true.
No...not the same effect. Just somewhat closer to the same.
It does mean you can't set a braekpoint at printf and expect it to
catch all your calls to printf. But I suppose that carries no more
weight than "it's how it's always worked".
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: wrstuden@netbsd.org
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 21:22:59 +0900
> > if you follow gcc (ie. honor compiler's right to do
> > this kind of optimization), you can't use non-standard extensions anyway.
> >
> > if you don't follow gcc (ie. disable the optimization),
> > you don't need to extend the extension to puts.
> >
> > in either way, i don't see any good reason to propagate
> > the extention to puts.
>
> You've defined everything in a very black & white manner, and in such a
> way that both scenarios support your opinion. That's not really a good
> starting point for an exchange of ideas.
i did so because they are only sane scenarios i can think of.
> Exactly what puts() does is up to us in the areas of "standards undefined"
> behavior, is it not? So we are free to add "(null)" support as I
> understand it. I really don't see why we shouldn't. What do you think will
> be broken or what will we lose?
yes, we are free to add it to our puts.
however, i think it's a bad idea as i wrote in my another mail.
besides, gcc is also free to optimize puts not to use our puts.
> The reality is we will probably have to live with gcc making assumptions
> for us. And to be honest, if we change puts(), then the assumption gcc
> makes (that printf("%s\n", x) yields the same effect as puts(x) for all x)
> is once again true.
you can't assume how gcc optimizes printf.
although it might happen to "fix" the problem at this point,
introducing another extention which is not recognized by gcc
just makes the situation worse.
YAMAMOTO Takashi
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 09:01:59 -0400
On Jun 21, 12:24pm, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
| yes, we are free to add it to our puts.
| however, i think it's a bad idea as i wrote in my another mail.
| besides, gcc is also free to optimize puts not to use our puts.
It is all a loss+benefit analysis. Adding the check to puts() seems
simple enough, we are allowed to by the standards, and makes the
gcc behavior consistent. It is also the least intrusive change. If
gcc decides to do something else in the future, we can examine the
problem when it happens.
|
| > The reality is we will probably have to live with gcc making assumptions
| > for us. And to be honest, if we change puts(), then the assumption gcc
| > makes (that printf("%s\n", x) yields the same effect as puts(x) for all x)
| > is once again true.
|
| you can't assume how gcc optimizes printf.
| although it might happen to "fix" the problem at this point,
| introducing another extention which is not recognized by gcc
| just makes the situation worse.
There is no extension here; it does not make a difference to gcc
how we implement puts.
christos
From: John Hawkinson <jhawk@MIT.EDU>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 09:13:10 -0400
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Tue, 21 Jun 2005
at 21:22:59 +0900 in <1119356579.718336.1241.nullmailer@yamt.dyndns.org>:
> > Exactly what puts() does is up to us in the areas of "standards undefined"
> > behavior, is it not? So we are free to add "(null)" support as I
> > understand it. I really don't see why we shouldn't. What do you think will
> > be broken or what will we lose?
>
> yes, we are free to add it to our puts.
> however, i think it's a bad idea as i wrote in my another mail.
"because it introduces another non-standard extension"? That does not
seem like a very compelling reason.
> besides, gcc is also free to optimize puts not to use our puts.
True. And then we are free to reconsider what to do about this problem
when the time comes. But it seems a relatively unlikely case that we
would be able to easily deal with, should the time come. So why worry?
> although it might happen to "fix" the problem at this point,
> introducing another extention which is not recognized by gcc
> just makes the situation worse.
I just don't see it making the situation worse. There are lots of
things our libc does that may not be specified explicitly in POSIX.
That's not a problem, and we don't worry about potential
future gcc optimizations each time we add or change one.
Changing puts() allows us to keep the behavior many find desirable at
a very low cost. We don't have to worry about getting our gcc out of
sync with the mainline, which is quite a big deal. We don't have to
worry about fighting a difficult battle with the gcc maintainers to
revert the change (it hardly seems like such a battle could be won
within the NetBSD community, so expecting to win it with the gcc
maintainers seems pretty tough).
--jhawk
From: Jason Thorpe <thorpej@shagadelic.org>
To: Bill Studenmund <wrstuden@netbsd.org>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 10:00:13 -0700
On Jun 20, 2005, at 9:11 PM, Bill Studenmund wrote:
> The problem though is that thanks to gcc, how puts() behaves is how
> printf() behaves some of the time. So printf() no longer has its
> historical behavior.
So what? It wasn't documented behavior, so anyone who depends on it
is being foolish anyway.
-- thorpej
From: Greywolf <greywolf@starwolf.com>
To: John Hawkinson <jhawk@MIT.EDU>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 10:14:29 +0000
John Hawkinson wrote:
>YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Tue, 21 Jun 2005
>at 21:22:59 +0900 in <1119356579.718336.1241.nullmailer@yamt.dyndns.org>:
>
>
>
>>>Exactly what puts() does is up to us in the areas of "standards undefined"
>>>behavior, is it not? So we are free to add "(null)" support as I
>>>understand it. I really don't see why we shouldn't. What do you think will
>>>be broken or what will we lose?
>>>
>>>
>>yes, we are free to add it to our puts.
>>however, i think it's a bad idea as i wrote in my another mail.
>>
>>
>
>"because it introduces another non-standard extension"? That does not
>seem like a very compelling reason.
>
>
>
>>besides, gcc is also free to optimize puts not to use our puts.
>>
>>
>
>True. And then we are free to reconsider what to do about this problem
>when the time comes. But it seems a relatively unlikely case that we
>would be able to easily deal with, should the time come. So why worry?
>
>
>
>>although it might happen to "fix" the problem at this point,
>>introducing another extention which is not recognized by gcc
>>just makes the situation worse.
>>
>>
>
>I just don't see it making the situation worse. There are lots of
>things our libc does that may not be specified explicitly in POSIX.
>That's not a problem, and we don't worry about potential
>future gcc optimizations each time we add or change one.
>
>
>Changing puts() allows us to keep the behavior many find desirable at
>a very low cost. We don't have to worry about getting our gcc out of
>sync with the mainline, which is quite a big deal. We don't have to
>worry about fighting a difficult battle with the gcc maintainers to
>revert the change (it hardly seems like such a battle could be won
>within the NetBSD community, so expecting to win it with the gcc
>maintainers seems pretty tough).
>
>--jhawk
>
>
It makes the situation worse because, as has been pointed out, what if
our puts()
does something we desire, and then gcc goes and inlines its own puts() which
routes around anything we might do?
Apply this scenario to any other function call outside
printf()/f*puts(). Would
it be considered acceptable there?
Granted, accessing outside the process space is something from which the
programmer should be protecting his programs, so that's not the issue, here.
The issue here is that the compiler seems to be given free license to
replace
an implemented function with known behaviour with its own inlined version.
In short, if the compiler is part of the implementation, as has been stated,
that gives the compiler license to completely supplant anything we do with
anything it wishes. And if that oversteps the bounds of "undefined
behaviour",
This Is Not Cool, Beavis.
With regard to "(null)" vs. "Bus error (Core dumped).", that doesn't matter
to me, other than being a potential nicety. What matters to me is the
compiler is pretending it knows what I want, even though I am not asking
for it. It's like walking into a shop and asking for a ham and jack
sandwich
and getting mortadella and mozzarella. Sure, it might be "better", but
it's not what I expected, much less what I asked for.
--
--*greywolf;
From: James Chacon <jmc@NetBSD.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Bill Studenmund <wrstuden@NetBSD.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 13:08:12 -0500
On Tue, Jun 21, 2005 at 10:00:13AM -0700, Jason Thorpe wrote:
>
> On Jun 20, 2005, at 9:11 PM, Bill Studenmund wrote:
>
> >The problem though is that thanks to gcc, how puts() behaves is how
> >printf() behaves some of the time. So printf() no longer has its
> >historical behavior.
>
> So what? It wasn't documented behavior, so anyone who depends on it
> is being foolish anyway.
>
That should only be true when gcc provides the complete implementation. It's
clear this isn't true here. Libc is provided from something else, yet gcc
is deciding "it's knows best" and substituting it's own rules in between.
Basically according to the logic above any stdc89/99 defined function cannot
have any extentions without the user using -ffreestanding. BEcause otherwise
gcc (from what you say) could just completely inline libc from it's own
implementation and by god...assuming it actually used the one installed on
my system is my own fault for assuming something so likely....
James
From: James Chacon <jmc@NetBSD.org>
To: Jason Thorpe <thorpej@shagadelic.org>,
Bill Studenmund <wrstuden@NetBSD.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 13:14:25 -0500
On Tue, Jun 21, 2005 at 01:08:12PM -0500, James Chacon wrote:
> On Tue, Jun 21, 2005 at 10:00:13AM -0700, Jason Thorpe wrote:
> >
> > On Jun 20, 2005, at 9:11 PM, Bill Studenmund wrote:
> >
> > >The problem though is that thanks to gcc, how puts() behaves is how
> > >printf() behaves some of the time. So printf() no longer has its
> > >historical behavior.
> >
> > So what? It wasn't documented behavior, so anyone who depends on it
> > is being foolish anyway.
> >
>
> That should only be true when gcc provides the complete implementation. It's
> clear this isn't true here. Libc is provided from something else, yet gcc
> is deciding "it's knows best" and substituting it's own rules in between.
>
> Basically according to the logic above any stdc89/99 defined function cannot
> have any extentions without the user using -ffreestanding. BEcause otherwise
> gcc (from what you say) could just completely inline libc from it's own
> implementation and by god...assuming it actually used the one installed on
> my system is my own fault for assuming something so likely....
BTW: -ffreestanding doesn't even imply it's what I would be using for
this:
-ffreestanding
Assert that compilation takes place in a freestanding environment.
This implies -fno-builtin. A freestanding environment is one in
which the standard library may not exist, and program startup may
not necessarily be at "main". The most obvious example is an OS
kernel. This is equivalent to -fno-hosted.
Obviously in the case being discussed this is a normal program depending on
the libc version of printf *on that system* to be called. There would be
no reason for any programmer to assume that in order to do that they have
to add -ffreestanding to their compile line based on that man page description.
James
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
netbsd-bugs@NetBSD.org, tech-userlevel@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 15:06:33 -0400 (EDT)
Sorry to inject some fact into a good squabble...
I was reading 2.0's gcc(1) for unrelated reasons and I found the
-fno-builtin-* options. It looks as though -fno-builtin-printf is TRT
for people who don't want this transformation, and -fno-builtin for
people who don't want any such for any function. (I see nothing for
people who want it off by default with an option to enable it, though.
Doable with a wrapper program that massages the arglist to gcc, I
suppose.)
This was the 2.0 gcc manpage. Looking at my -current sup tree, I see
src/gnu/dist/gcc/gcc/doc/gcc.1, which describes such options, and
src/gnu/dist/toolchain/gcc/gcc.1, which doesn't but which claims to be
for gcc 2.95.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: tech-userlevel@NetBSD.org
Cc: Jason Thorpe <thorpej@shagadelic.org>,
Bill Studenmund <wrstuden@NetBSD.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 20:46:47 +0200
On Tue, Jun 21, 2005 at 01:14:25PM -0500, James Chacon wrote:
> BTW: -ffreestanding doesn't even imply it's what I would be using for
> this:
>
> -ffreestanding
> Assert that compilation takes place in a freestanding environment.
> This implies -fno-builtin. A freestanding environment is one in
> which the standard library may not exist, and program startup may
> not necessarily be at "main". The most obvious example is an OS
> kernel. This is equivalent to -fno-hosted.
Actually, it does say all the necessary thing.
(a) The standard library may not exist. --> can't depend on the behaviour
(b) -fno-builtin is the more important part.
If you consider printf a partial builtin like e.g. sqrt under certain
circumstances, it makes a lot more sense.
Joerg
From: Jason Thorpe <thorpej@shagadelic.org>
To: Greywolf <greywolf@starwolf.com>
Cc: John Hawkinson <jhawk@MIT.EDU>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 12:49:46 -0700
On Jun 21, 2005, at 3:14 AM, Greywolf wrote:
> With regard to "(null)" vs. "Bus error (Core dumped).", that
> doesn't matter
> to me, other than being a potential nicety. What matters to me is the
> compiler is pretending it knows what I want, even though I am not
> asking
> for it. It's like walking into a shop and asking for a ham and
> jack sandwich
> and getting mortadella and mozzarella. Sure, it might be "better",
> but
> it's not what I expected, much less what I asked for.
When you called printf() (or puts(), for that matter), you have, by
definition, asked for the standards-described effect.
If you want to depend on extensions, then you should call an API that
explicitly provides them, period!
-- thorpej
From: Bill Studenmund <wrstuden@netbsd.org>
To: tech-userlevel@NetBSD.org, Jason Thorpe <thorpej@shagadelic.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
christos@zoulas.com, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org
Cc:
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 13:02:03 -0700
--2/5bycvrmDh4d1IB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2005 at 08:46:47PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 21, 2005 at 01:14:25PM -0500, James Chacon wrote:
> > BTW: -ffreestanding doesn't even imply it's what I would be using for
> > this:
> >=20
> > -ffreestanding
> > Assert that compilation takes place in a freestanding enviro=
nment.
> > This implies -fno-builtin. A freestanding environment is on=
e in
> > which the standard library may not exist, and program startu=
p may
> > not necessarily be at "main". The most obvious example is a=
n OS
> > kernel. This is equivalent to -fno-hosted.
>=20
> Actually, it does say all the necessary thing.
>=20
> (a) The standard library may not exist. --> can't depend on the behaviour
The problem, though, is that most of us consider the stdio code in libc to=
=20
be the "standard" library, it is present, and it is what we want. Thus=20
-ffreestanding is not what we want.
Take care,
Bill
--2/5bycvrmDh4d1IB
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCuHI7Wz+3JHUci9cRAtvAAJ48R7COreOU74DDiuY7MkbgiyWhmwCcCI4t
pvNes6h8mqzD00CoM4QNMyc=
=Lh+3
-----END PGP SIGNATURE-----
--2/5bycvrmDh4d1IB--
From: Greywolf <greywolf@starwolf.com>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: John Hawkinson <jhawk@MIT.EDU>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 13:15:12 -0700 (PDT)
[Thus spake Jason Thorpe ("JT: ") 12:49pm...]
JT: > and getting mortadella and mozzarella. Sure, it might be "better",
JT: > but
JT: > it's not what I expected, much less what I asked for.
JT:
JT: When you called printf() (or puts(), for that matter), you have, by
JT: definition, asked for the standards-described effect.
JT:
JT: If you want to depend on extensions, then you should call an API that
JT: explicitly provides them, period!
Ahhahah! Okay, I think we're on the same page, here! I stated that
I don't want said extensions, much less gratuitously shoved in without
me asking.
Just so we're clear. Glad to hear it!
--*greywolf;
--
From: James Chacon <jmc@NetBSD.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Greywolf <greywolf@starwolf.com>, John Hawkinson <jhawk@MIT.EDU>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 15:53:20 -0500
On Tue, Jun 21, 2005 at 12:49:46PM -0700, Jason Thorpe wrote:
>
> On Jun 21, 2005, at 3:14 AM, Greywolf wrote:
>
> >With regard to "(null)" vs. "Bus error (Core dumped).", that
> >doesn't matter
> >to me, other than being a potential nicety. What matters to me is the
> >compiler is pretending it knows what I want, even though I am not
> >asking
> >for it. It's like walking into a shop and asking for a ham and
> >jack sandwich
> >and getting mortadella and mozzarella. Sure, it might be "better",
> >but
> >it's not what I expected, much less what I asked for.
>
> When you called printf() (or puts(), for that matter), you have, by
> definition, asked for the standards-described effect.
So no implementation is ever allowed to extend any standards defined function?
>
> If you want to depend on extensions, then you should call an API that
> explicitly provides them, period!
I see. So there's either "completely standards conforming" calls or "other".
i.e. we should now have printfEx for anything printf related the standard
didn't cover...
James
From: Jason Thorpe <thorpej@shagadelic.org>
To: James Chacon <jmc@NetBSD.org>
Cc: Greywolf <greywolf@starwolf.com>, John Hawkinson <jhawk@MIT.EDU>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 14:06:44 -0700
On Jun 21, 2005, at 1:53 PM, James Chacon wrote:
> i.e. we should now have printfEx for anything printf related the
> standard
> didn't cover...
In the NetBSD case, it could even be a weak symbol that points to
printf! By doing this, you are telling the implementation that you
are explicitly relying on extensions (how is the implementation to
know otherwise that you expect NULL to really mean "(null)"?).
-- thorpej
From: James Chacon <jmc@NetBSD.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Greywolf <greywolf@starwolf.com>, John Hawkinson <jhawk@MIT.EDU>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 16:28:22 -0500
On Tue, Jun 21, 2005 at 02:06:44PM -0700, Jason Thorpe wrote:
>
> On Jun 21, 2005, at 1:53 PM, James Chacon wrote:
>
> >i.e. we should now have printfEx for anything printf related the
> >standard
> >didn't cover...
>
> In the NetBSD case, it could even be a weak symbol that points to
> printf! By doing this, you are telling the implementation that you
> are explicitly relying on extensions (how is the implementation to
> know otherwise that you expect NULL to really mean "(null)"?).
To (me at least) the "implementation" is the compiler + the libraries.
Gcc is assuming it's the complete implementation here, it knows best and how
everything was setup/provided. This is not a valid assumption. The standard
says how a certain class of operations *must* perform but doesn't disallow
for extensions either. Since the compiler in this cannot know what extensions
may/may not exist in the full implementation (since it's not also providing
the standard library) making assumptions about what it can do to the
implementation is an error (IMO).
If gcc provided these functions itself and knew absolutely there were no
side effects/differences between printf->puts substitutions then I'd have
no argument here. Certainly this is the case with libgcc provided calls.
The fact is, because gcc only provides 1 piece of the overall picture it
should not just assume the rest of the picture unless I've told it to (say
with std=c99, etc).
James
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: jhawk@MIT.EDU
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 23 Jun 2005 12:19:47 +0900
> > > Exactly what puts() does is up to us in the areas of "standards undefined"
> > > behavior, is it not? So we are free to add "(null)" support as I
> > > understand it. I really don't see why we shouldn't. What do you think will
> > > be broken or what will we lose?
> >
> > yes, we are free to add it to our puts.
> > however, i think it's a bad idea as i wrote in my another mail.
>
> "because it introduces another non-standard extension"?
no.
i meant "because the idea to produce (null) and suppress coredump is
fundamentally bad."
> > besides, gcc is also free to optimize puts not to use our puts.
>
> True. And then we are free to reconsider what to do about this problem
> when the time comes. But it seems a relatively unlikely case that we
> would be able to easily deal with, should the time come. So why worry?
because once we add such an adhoc extention,
we likely have to keep it forever.
YAMAMOTO Takashi
From: Martin Husemann <martin@duskware.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: jhawk@MIT.EDU, gnats-bugs@netbsd.org,
port-xen-maintainer@netbsd.org, netbsd-bugs@netbsd.org,
tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 23 Jun 2005 09:23:11 +0200
On Thu, Jun 23, 2005 at 12:19:47PM +0900, YAMAMOTO Takashi wrote:
> i meant "because the idea to produce (null) and suppress coredump is
> fundamentally bad."
I agree. We would not start mapping a userspace address at VA 0 again, to stop
dereferences of NULL pointers to core, right?
This does not mean that we should remove the "(null)" output from printf,
and maybe add it to puts as a stopgap fix.
But IMHO we should discourage passing NULL pointers as %s to *printf* in the
style doc and fix callers as we discover them.
Martin
From: Ignatios Souvatzis <is@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 23 Jun 2005 17:08:28 +0200
--Yylu36WmvOXNoKYn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2005 at 09:23:11AM +0200, Martin Husemann wrote:
> On Thu, Jun 23, 2005 at 12:19:47PM +0900, YAMAMOTO Takashi wrote:
> > i meant "because the idea to produce (null) and suppress coredump is
> > fundamentally bad."
>=20
> I agree. We would not start mapping a userspace address at VA 0 again, to=
stop
> dereferences of NULL pointers to core, right?
Maybe applications that want (null) to be printed should mmap a page
starting with the string "(null)" to that address. ;-)
-is
--Yylu36WmvOXNoKYn
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
iD8DBQFCutBpN4tiz3B8hB0RAs4yAJ9Ey5FogMimG22OVbCCg/cx/X0ROwCfVE9N
HUFa/jGokx1csJ/iOb7+dH4=
=rrGv
-----END PGP SIGNATURE-----
--Yylu36WmvOXNoKYn--
From: Roland Illig <rillig@NetBSD.org>
To: Ignatios Souvatzis <is@netbsd.org>
Cc: Martin Husemann <martin@duskware.de>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 23 Jun 2005 19:12:17 +0200
Ignatios Souvatzis wrote:
> On Thu, Jun 23, 2005 at 09:23:11AM +0200, Martin Husemann wrote:
>
>>On Thu, Jun 23, 2005 at 12:19:47PM +0900, YAMAMOTO Takashi wrote:
>>
>>>i meant "because the idea to produce (null) and suppress coredump is
>>>fundamentally bad."
>>
>>I agree. We would not start mapping a userspace address at VA 0 again, to stop
>>dereferences of NULL pointers to core, right?
>
>
> Maybe applications that want (null) to be printed should mmap a page
> starting with the string "(null)" to that address. ;-)
Cool. That really works (on i386). Never thought it would. :)
Roland
From: Bill Studenmund <wrstuden@netbsd.org>
To: Martin Husemann <martin@duskware.de>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Thu, 23 Jun 2005 15:48:39 -0700
--NKoe5XOeduwbEQHU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2005 at 09:23:11AM +0200, Martin Husemann wrote:
> On Thu, Jun 23, 2005 at 12:19:47PM +0900, YAMAMOTO Takashi wrote:
> > i meant "because the idea to produce (null) and suppress coredump is
> > fundamentally bad."
>=20
> I agree. We would not start mapping a userspace address at VA 0 again, to=
stop
> dereferences of NULL pointers to core, right?
Please actually listen to what folks are saying. No one is suggesting a
mapping at VA 0. I agree actually DOING (well, trying to do) something=20
with a NULL pointer should go boom.
> This does not mean that we should remove the "(null)" output from printf,
> and maybe add it to puts as a stopgap fix.
>=20
> But IMHO we should discourage passing NULL pointers as %s to *printf* in =
the
> style doc and fix callers as we discover them.
I agree that if we find code that explicitly passes NULL to printf(), we=20
should change it. Such code is really silly.
But why mention it in the style guide? If our printf() is fine with it,
why change code? If we really are ok with it (as evidenced by the fact we
changed man pages and code), then we shouldn't forbid it in the style
guide. Programs still have to be careful, because if they ever do more
than print such a thing, they get the big "Kaboom."
The reason why I object to such a change is that I've worked with code
that has strong-NULL-protection around printf(). I've written it. I've had
to maintain it. And it was irritating. It's no big deal if there's only
one parameter to the printf(). (val ? val : "") isn't too bad. But if you
have a printf() with multiple parameters, it can get messy. Now say your
multiple parameters aren't "val" but something more like
connection->session->client_name and it gets messier. Now start your
indentation about 40 characters in when you're keeping to 80 characters,
and it is really messy.
Libraries are supposed to make life easier and reuse code. That isn't.
Take care,
Bill
--NKoe5XOeduwbEQHU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFCuzxHWz+3JHUci9cRAiv3AJ9vwBdS1OK5DqE2nOmxHwgCoI4+igCfaxeZ
l9LbW3c8ja/e794UXA2oaAQ=
=smU6
-----END PGP SIGNATURE-----
--NKoe5XOeduwbEQHU--
From: Martin Husemann <martin@duskware.de>
To: Bill Studenmund <wrstuden@netbsd.org>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, jhawk@MIT.EDU,
gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
netbsd-bugs@netbsd.org, tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 24 Jun 2005 09:20:45 +0200
On Thu, Jun 23, 2005 at 03:48:39PM -0700, Bill Studenmund wrote:
> I agree actually DOING (well, trying to do) something
> with a NULL pointer should go boom.
Printing the string content pointed to by the NULL pointer is not "trying to
do something"? I realy don't understand this differentation, sorry.
> If we really are ok with it (as evidenced by the fact we
> changed man pages and code), then we shouldn't forbid it in the style
> guide.
Well, in the man pages I have it is not documented, and since this
discussion did not reach consensus I'm not sure we realy are ok with it.
> The reason why I object to such a change is that I've worked with code
> that has strong-NULL-protection around printf(). I've written it. I've had
> to maintain it. And it was irritating.
You have to be carefull about null pointer for every pointer operation. I do
not see the difference for printf.
Martin
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home