Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 06/23/2005 03:21:05
The following reply was made to PR port-xen/29887; it has been noted by GNATS.
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