> basename() is in the dirname module
That's the POSIX variant. We're using the GNU variant everywhere and the GNU
variant is a whopping two lines of code:
char *base = strrchr(path, '/');
return base ? base + 1 : (char *)path;
> you're correct that GNU strerror_r is not handled by gnulib.
> th
First, I'm not sure if we want to import the respective gnulib modules directly
into the elfutils code base or if you want me to do this in my fork. In the
latter case the issue is settled as there is no value for me in jumping through
hoops if the code is not going to be upstreamed anyway. So,
Please compare the following code with asprintf.c/vasprintf.c/vasnprintf.c from
gnulib. asprintf depends on vasprintf which in turn depends on vasnprintf
there. vasnprintf is non-standard and not even available on glibc, while
vsnprintf as used by my implementation is standardized by POSIX and w
On Thu, Feb 23, 2017 at 11:18:53AM +0100, Ulf Hermann wrote:
> First, I'm not sure if we want to import the respective gnulib modules
> directly into the elfutils code base or if you want me to do this in
> my fork. In the latter case the issue is settled as there is no value
> for me in jumping th
On Fri, Feb 17, 2017 at 01:16:11PM +0100, Ulf Hermann wrote:
> And then there are nonstandard C constructs, especially void* arithmetics
void * arithmetic can at times be surprising, so that seems a fine cleanup.
Best to make sure the code compiles cleanly with -Wpointer-arith.
> and statement ex
On 23 Feb 2017 10:39, Ulf Hermann wrote:
> > basename() is in the dirname module
>
> That's the POSIX variant. We're using the GNU variant everywhere
looking closer, it's not either. POSIX doesn't guarantee that the input
is not modified, while GNU guarantees that it is left alone. the gnulib
o
