Subject: Re: fork(2) vs. pthread_create() (fwd)
To: Nathan J. Williams <>
From: Bill Studenmund <>
List: tech-userlevel
Date: 06/11/2004 11:35:27
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 11, 2004 at 12:51:47PM -0400, Nathan J. Williams wrote:
> Bill Studenmund <> 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
physically done."

> > 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.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)