Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.