--kXdP64Ggrk/fb43R
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 <wrstuden@netbsd.org> writes:
>=20
> >> We are able to output error messages...
> >
> > From a library? No. You can't.
>=20
> 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.
>=20
> 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=
ty=20
> > issue. Consider a daemon that has hooked something other than stderr to=
 fd=20
> > 2. If you can trigger the program to call a routine that outputs an err=
or=20
> > (and/or you can trigger the conditions of the error), you can get=20
> > arbitrary data send down whatever's hooked to fd2.
>=20
> 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,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAyftvWz+3JHUci9cRAnx0AJ9Oe2b4qKVdKw2287lnsX3CqTJQpgCeJuFA
/QGDDsasHxcGJAhfZ40vTU0=
=kdVa
-----END PGP SIGNATURE-----

--kXdP64Ggrk/fb43R--