Re: mandoc strlcat
On Thu, May 23, 2013 at 09:38:57PM -0600, Theo de Raadt wrote: On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote: I was looking at mandoc and noticed it has too many strlcats (a common affliction affecting quite a few programs.) It's faster and simpler to use snprintf. In glibc snprintf has a memory allocation failure mode. In OpenBSD, snprintf is designed to be thread and signal-handler safe, as long as you don't use certain dangerous features. I'm afraid I can't find documentation which defines which are dangerous or not, but remember auditing our tree to improve the situation. From what I remember, the unsafe extensions were the $# positional markers, that allow one to swap arguments around.
Re: mandoc strlcat
From: Theo de Raadt dera...@cvs.openbsd.org Date: Thu, 23 May 2013 21:38:57 -0600 On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote: I was looking at mandoc and noticed it has too many strlcats (a common affliction affecting quite a few programs.) It's faster and simpler to use snprintf. In glibc snprintf has a memory allocation failure mode. In OpenBSD, snprintf is designed to be thread and signal-handler safe, as long as you don't use certain dangerous features. I'm afraid I can't find documentation which defines which are dangerous or not, but remember auditing our tree to improve the situation. But the reason we did this was to reduce the amount of damage badly written signal handlers could do. Not to encourage people to actually use the *printf(3) family of functions in signal handlers.
Re: mandoc strlcat
But the reason we did this was to reduce the amount of damage badly written signal handlers could do. Not to encourage people to actually use the *printf(3) family of functions in signal handlers. Well... we had to use something..
Re: mandoc strlcat
On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote: I was looking at mandoc and noticed it has too many strlcats (a common affliction affecting quite a few programs.) It's faster and simpler to use snprintf. In glibc snprintf has a memory allocation failure mode. I'm curious: is OpenBSD committed to avoiding extensions (locale features, etc) which might trigger allocation failure?
Re: mandoc strlcat
On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote: I was looking at mandoc and noticed it has too many strlcats (a common affliction affecting quite a few programs.) It's faster and simpler to use snprintf. In glibc snprintf has a memory allocation failure mode. In OpenBSD, snprintf is designed to be thread and signal-handler safe, as long as you don't use certain dangerous features. I'm afraid I can't find documentation which defines which are dangerous or not, but remember auditing our tree to improve the situation. I'm curious: is OpenBSD committed to avoiding extensions (locale features, etc) which might trigger allocation failure? I don't know if we are commited to such a restriction. We could add such things, but then put them in the dangerous catagory, to not be used in unsafe situations... Hmm, where are our docs for that...
Re: mandoc strlcat
On Thu, May 23, 2013 at 21:38, Theo de Raadt wrote: In glibc snprintf has a memory allocation failure mode. I'm curious: is OpenBSD committed to avoiding extensions (locale features, etc) which might trigger allocation failure? Yes. I mean, what in the world is snprintf doing allocating some locale crap to implement a behavior that strlcat clearly doesn't need to allocate memory for? I don't know if we are commited to such a restriction. We could add such things, but then put them in the dangerous catagory, to not be used in unsafe situations... Hmm, where are our docs for that... It's in man signal. The only thing you can't use is floating point, because dtoa is crazy, but I think it'd even be possible to pass the buffer in from vfprintf and make that signal safe too. Just nobody cares.
Re: mandoc strlcat
It's in man signal. The only thing you can't use is floating point, because dtoa is crazy, The *5 table, yes. I tried to improve the situation there. I nearly lost my mind.
