Subject: Re: fork(2) vs. pthread_create() (fwd)
To: Nathan J. Williams <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/11/2004 11:35:27
Content-Type: text/plain; charset=us-ascii
On Fri, Jun 11, 2004 at 12:51:47PM -0400, Nathan J. Williams wrote:
> Bill Studenmund <firstname.lastname@example.org> writes:
> >> We are able to output error messages...
> > From a library? No. You can't.
> Emmanuel is pointing out that we do, in fact, print messages to stderr
> in the various mutex error-detecting conditions that normally
> abort. They can be configured to just print the message and not abort,
> or to do neither.
> Perhaps we "shouldn't", but it's wrong to say that we "can't".
Yes, it was "can't" as in "that's really bad," not as in "can not be=20
> > The fact that libraries sometimes output to stderr is actually a securi=
> > issue. Consider a daemon that has hooked something other than stderr to=
> > 2. If you can trigger the program to call a routine that outputs an err=
> > (and/or you can trigger the conditions of the error), you can get=20
> > arbitrary data send down whatever's hooked to fd2.
> Does this mean you think that libraries should never use assert(3)?
I was under the (perhapse mistaken) understanding that we sprinkled=20
assert(3) calls in our libraries, but didn't actually compile them into=20
assert calls in our normal libraries. You can build a debug version and=20
have all the assertions turned on.
Also, assert(3) is a little different than what I believed had been=20
suggested, in that it aborts if it is triggered. Thus it is obvious=20
_something_ happened, even if no message is visible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----