Date: Tue, 05 Jan 2021 11:04:37 -0800 From: Keith Packard <keithp@...thp.com> To: enh <enh@...gle.com>, libc-coord@...ts.openwall.com Cc: Florian Weimer <fweimer@...hat.com> Subject: Re: Future directions for *_r functions enh <enh@...gle.com> writes: > iirc basename(3) was the place where we caused problems in practice. The glibc man page for basename is terrifying. Two different functions with different semantics depending on compile-time options. Thanks for getting me to read it closely ... I don't even know what basename/dirname should do in an ideal environment. They would have to malloc to even use a TLS buffer, I'd think. > okay, when i said "we did this years ago", lgamma(3) is one we didn't > actually do :-) Yeah, I hit these when I was fixing the picolibc math library errno/exception/return values to match ANSI-C. The code (imported from newlib) had surprisingly broken gamma interfaces... > i've honestly never seen lgamma(3) used --- afaict the folks writing math > code all know to use lgamma_r(3). a quick code search suggests that when it > is used, it's often used in ways that could fall victim to the basename(3) > gotcha above. here i'd be tempted to just `__attribute__((__deprecated__))` > lgamma(3) and suggest lgamma_r(3) instead. Oh, that's a good idea actually. The chances of code using lgamma being correct are pretty small -- most of the time, I've just seen gamma = exp(lgamma(x)) for code which never changed to use tgamma. -- -keith Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.