Date: Tue, 25 Sep 2018 08:44:59 +0000
From: Emmanuel Dreyfus <m...@netbsd.org>
Message-ID: <20180925084459.gd25...@homeworld.netbsd.org>
| What a pity they do that without introducing basename_r().
If that existed in some kind of wodespread use, that might have happened,
otherwise, it would be inventing something new, which has been known, but
is avoided wghever possible.
| configure scripts will have to test run-time behavior os basename()
| to figure the flavor.
One might hope that in time thery're all compat - but in any case it is easy
to wrote code that assymes the LCD and works with any form, there should
not really be a need to configure for different ones.
Further, they are such trivial functions (useful, but trivial) that if a
version that acts in a particular way is wanted, it is trivial to simply
rewrite it under a different name (so if you're going to call one of these
over and over, so performance matters, you can make a version which
does exactly what you need in the most effecient way possible).
Simon Burge <simonb@> said:
| The code in question is essentially:
[elided here]
| Even with the new approved wording for
| the next revision of the spec for dirname(3) you quoted I'm still not sure
if
| the code above should be considered valid or not.
It isn't, any call can return a pointer to static const storage (we know when
that will happen, but the standard doesn't limit it to those cases) and any
call can modify the buffer - hence using the result from one call as input to
another is always wrong.
It is annoyiong, but it is kind of forced upon us all because of the way that
the implementations have beendone over time (the way various versions
diverged in order to meet whatever was deemed to be the need for the users
of that version).
This really is an area where a new fuincion (or pair of functions) has some
chance of success - I think FreeBSD has a new interface that is a combined
dirname()/basename() which might be suitable. Get that in a few systems most
likely including glibc, and there's a chance that it could appear in posix in
the future.
kre
