On 24 Feb 2017 10:42, Ulf Hermann wrote:
> >> and the GNU variant is a whopping two lines of code:
> >>
> >> char *base = strrchr(path, '/');
> >> return base ? base + 1 : (char *)path;
> >
> > and we get straight to an example of why your solutions don't scale.
> > your replacement is wrong. and
and the GNU variant is a whopping two lines of code:
char *base = strrchr(path, '/');
return base ? base + 1 : (char *)path;
and we get straight to an example of why your solutions don't scale.
your replacement is wrong. and ironically, it's wrong on Windows,
which is the whole point of your
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
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
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
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,
> 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
On 2017-02-22, Mike Frysinger wrote:
> you're correct that GNU strerror_r is not handled by gnulib.
> that doesn't look like it's too hard to deal with, but it is
> something that'd have to be considered.
And if someone is going to take the time to implement strerror_r, really
the patch should go
On 22 Feb 2017 18:43, Ulf Hermann wrote:
> > sorry, but i don't know what you're talking about. you don't read the
> > gnulib code/modules directly, you just run gnulib-tool and tell it which
> > modules to import. it does all the rest for you.
> >
> > you want asprintf ? then add it to the lis
> sorry, but i don't know what you're talking about. you don't read the
> gnulib code/modules directly, you just run gnulib-tool and tell it which
> modules to import. it does all the rest for you.
>
> you want asprintf ? then add it to the list.
> modules=(
> asprintf
> glob
>
On 22 Feb 2017 17:45, Ulf Hermann wrote:
> > imo, elfutils shouldn't be growing these fallback implementations itself.
> > if you want to do this stuff, use gnulib instead.
> >
> > then there is no ifdef hell in the source files, and you don't have to
> > worry about testing whether the ifdef's ar
> imo, elfutils shouldn't be growing these fallback implementations itself.
> if you want to do this stuff, use gnulib instead.
>
> then there is no ifdef hell in the source files, and you don't have to
> worry about testing whether the ifdef's are correct because gnulib did
> it all for you.
OK,
On Wed, Feb 22, 2017 at 05:01:51PM +0100, Ulf Hermann wrote:
> > these portability replacements are starting to get out of hand
> To what extent should elfutils be portable to non-GNU systems?
That has never really been a goal. elfutils is specifically for
handling ELF files and DWARF data on a GN
On 22 Feb 2017 17:01, Ulf Hermann wrote:
> > these portability replacements are starting to get out of hand
>
> To what extent should elfutils be portable to non-GNU systems? My goal here
> is to port it to windows while minimizing the amount of external dependencies
> I have to add. The functio
> these portability replacements are starting to get out of hand
> -mike
To what extent should elfutils be portable to non-GNU systems? My goal here is
to port it to windows while minimizing the amount of external dependencies I
have to add. The functions I have replaced so far are so trivial tha
On 22 Feb 2017 13:50, Ulf Hermann wrote:
> Add replacements to libeu.a if they don't exist. Include system.h
> and link against libeu.a where they are used.
these portability replacements are starting to get out of hand
-mike
signature.asc
Description: Digital signature
16 matches
Mail list logo
