Re: New version of function mkdirhier()
On Sat, 2012-01-14 at 23:48 +0100, Samuel Thibault wrote:
> Svante Signell, le Fri 13 Jan 2012 14:43:06 +0100, a écrit :
> > > No, but Guillem probably feels the same, and I do too: it's hard to tell
> > > you anything because you quickly get things personally.
> >
> > I don't consider my replies to be personal
>
> I should have said "you quickly take things personally". It's difficult
> to comment on your code because you quickly take it as a personal
> criticism, which it is not.
What is personal criticism then, and what is the alternative,
non-personal? Getting feedback on a proposed patch, isn't that
personal? Nobody else is adjusting the patches for you, only commenting
on them. So creating a new patch bounces back to the proposer. In an
extreme extension, never propose anything to be safe, but of course
then nothing happens.
> > And the proposed replacement function works properly, with minor
> > glitches as you points out.
>
> But it doesn't mean that upstream will happily accept it.
In this case there is no upstream, only different package maintainers.
There was an attempt to fork that package, libtar-ng, by a Redhat
associated person contributing to Fedora in 2009. It seem that the fork
never took off though.
> > I thought usage of obsolete library code should be avoided if
> > possible, especially when better replacements are available, even when
> > creating patches.
>
> Which function are you referring to precisely? Some functions are not
> "obsolete", they are just not trivial to use.
Ok, the functions are not obsolete, the thing is that libbsd is needed
in addition to glibc and it would be nice to use only glibc-supplied
functions. However, in this case it is not relevant.
> > Yes, but the fallback version use same non-recommended constructs as the
> > POSIX version does (modifying the argument) and I wanted to get rid of
> > that for this piece of the code.
>
> I'm lost. What are you referring to exactly?
I've looked a little more at the compat code and both the supplied
basename and dirname don't modify it's argument, like the POSIX ones
do. That's the reason the configure tests fail, and these should be
ported, not using the POSIX ones.
Reply to: