* musl & strndupa? @ 2014-01-01 19:42 Raphael Cohn 2014-01-01 19:54 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Raphael Cohn @ 2014-01-01 19:42 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 637 bytes --] Hi, I'm trying to compile 'audit' (aka libaudit, auditd, etc - from http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using musl 0.9.14. The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I presume is an alloca version of strndup, and presumably a _GNU_SOURCE feature. I can't seem to see a definition for it in musl, although strdupa exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests as much). Is this intentional? If so, what would anyone suggest as a work around? My guess would be #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t) but I'd like a second opinion... Raph [-- Attachment #2: Type: text/html, Size: 902 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: musl & strndupa? 2014-01-01 19:42 musl & strndupa? Raphael Cohn @ 2014-01-01 19:54 ` Rich Felker 2014-01-01 20:07 ` Raphael Cohn 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2014-01-01 19:54 UTC (permalink / raw) To: musl On Wed, Jan 01, 2014 at 07:42:47PM +0000, Raphael Cohn wrote: > Hi, > > I'm trying to compile 'audit' (aka libaudit, auditd, etc - from > http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using musl > 0.9.14. > > The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I > presume is an alloca version of strndup, and presumably a _GNU_SOURCE > feature. I can't seem to see a definition for it in musl, although strdupa > exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests as > much). > > Is this intentional? If so, what would anyone suggest as a work around? My > guess would be #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t) > but I'd like a second opinion... That's roughly the way to do it, but you need strnlen, not strlen, and there are various other details like properly parenthesizing macro arguments. In addition, there's no way to avoid multiple-evaluations of arguments unless you use the GNU C statement-expressions extension. It should be noted that almost any use of alloca is either a bug (potentially exploitable stack overflow) or useless (because the size is bounded and thus could/should just be replaced by a fixed-size array). This is the main reason I've been hesitant to go to the trouble of providing this and dealing with the multiple-evaluation or #ifdef __GNUC__ issue -- really, any software using alloca (and by extension, strdupa or strndupa) should be fixed. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: musl & strndupa? 2014-01-01 19:54 ` Rich Felker @ 2014-01-01 20:07 ` Raphael Cohn 2014-01-01 20:18 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Raphael Cohn @ 2014-01-01 20:07 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 2875 bytes --] Rich, Thank you for the extremely informative and quick response! I suspect in the small, understandable places that use this function in this package it should be possible to avoid multiple evaluations (well, at least for this version of the code; no g'tee that would hold). Out of interest, I presume there's no guarantee that alloca is aligned? It's not a feature I've ever used - it seems like a micro-optimisation for tight loops that should be made as part of a decision by a higher-level language (eg Vala, which, as I understand, doesn't). BTW, This package has a few more issues than just musl ones... it doesn't understand cross-compilation for starters, makes insane use of code generation (always a big smell in my book, especially when done using a compiled language). Looks like it suffers from not enough peer review / usage... Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 1 January 2014 19:54, Rich Felker <dalias@aerifal.cx> wrote: > On Wed, Jan 01, 2014 at 07:42:47PM +0000, Raphael Cohn wrote: > > Hi, > > > > I'm trying to compile 'audit' (aka libaudit, auditd, etc - from > > http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using > musl > > 0.9.14. > > > > The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I > > presume is an alloca version of strndup, and presumably a _GNU_SOURCE > > feature. I can't seem to see a definition for it in musl, although > strdupa > > exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests > as > > much). > > > > Is this intentional? If so, what would anyone suggest as a work around? > My > > guess would be #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t) > > but I'd like a second opinion... > > That's roughly the way to do it, but you need strnlen, not strlen, and > there are various other details like properly parenthesizing macro > arguments. In addition, there's no way to avoid multiple-evaluations > of arguments unless you use the GNU C statement-expressions extension. > > It should be noted that almost any use of alloca is either a bug > (potentially exploitable stack overflow) or useless (because the size > is bounded and thus could/should just be replaced by a fixed-size > array). This is the main reason I've been hesitant to go to the > trouble of providing this and dealing with the multiple-evaluation or > #ifdef __GNUC__ issue -- really, any software using alloca (and by > extension, strdupa or strndupa) should be fixed. > > Rich > [-- Attachment #2: Type: text/html, Size: 3907 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: musl & strndupa? 2014-01-01 20:07 ` Raphael Cohn @ 2014-01-01 20:18 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2014-01-01 20:18 UTC (permalink / raw) To: musl On Wed, Jan 01, 2014 at 08:07:07PM +0000, Raphael Cohn wrote: > Rich, > > Thank you for the extremely informative and quick response! I suspect in > the small, understandable places that use this function in this package it > should be possible to avoid multiple evaluations (well, at least for this > version of the code; no g'tee that would hold). > > Out of interest, I presume there's no guarantee that alloca is aligned? You'd have to consult the compiler for a guarantee, but I think the intent is that it's suitably aligned for any type, but perhaps not for extended things like vector operations. > It's not a feature I've ever used - it seems like a micro-optimisation for > tight loops that should be made as part of a decision by a higher-level > language (eg Vala, which, as I understand, doesn't). The intent of alloca is to allow the programmer to be lazy about obtaining temporary, "arbitrarily large" storage that will automatically cease to exist when the caller returns. It's mostly obsoleted by VLAs (but alloca can do things VLA can't, e.g. when used in loops), but VLAs are also unsafe in the same way that there's no way to check for allocation failures or handle them when they occur. When you really need more than a small reasonable bounded-size buffer, you need to be using malloc/free and dealing with the ugly failure cases and cleanup on return... Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-01 20:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-01 19:42 musl & strndupa? Raphael Cohn 2014-01-01 19:54 ` Rich Felker 2014-01-01 20:07 ` Raphael Cohn 2014-01-01 20:18 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).