Re: New version of function mkdirhier()
On Fri, 2012-01-13 at 13:12 +0100, Samuel Thibault wrote:
> Svante Signell, le Fri 13 Jan 2012 12:31:22 +0100, a écrit :
> I'm answering for Richard :)
OK!
> 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 (except maybe the comment on
his opinion on code quality). And the proposed replacement function
works properly, with minor glitches as you points out. I thought usage
of obsolete library code should be avoided if possible, especially when
better replacements are available, even when creating patches.
> We'd have to
> take a lot of care in our mails to formulate things in a way that does
> not provoke your usual "taking personally criticisms" reaction, which
> means time, which we don't have much, and we'd thus rather just not
> answer.
No, I don't think it is like that in most cases, maybe this one. I
proposed a new verified routine, and got the answer: use as much as
possible of the old and obsolete code.
> > > Now back to the technical stuff. I believe Guillem's solution is quite
> > > appropriate.
> >
> > I did not see any proposed solution.
>
> There was one: just allocate with dynamic size instead of just PATH_MAX.
That one I knew about already. Nothing new here.
> > The bad thing is that there are still packages depending on this code.
> > It should go down the drain and depending packages convert to something
> > else (or a new upstream pops up).
>
> I don't understand this. Did you understand what he said? libtar using
> odd functions is not a problem since if the system does not provide
> them, then libtar has its own version. I don't see where the depending
> packages come into play.
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.
The problem with packages not having upstream is that the code
deteriorates (compared with other code) with time, and if no new
upstream appears in my opinion, depending software should migrate away.
> > Might be so, in my opinion strncat is safer than strcat wrt buffer
> > overflows, but I'm probably wrong.
>
> In some cases it's true, in some other cases (like the case at stake),
> it's wrong.
So the basic knowledge of vulnerability was not totally wrong even if
not applicable in this case.
Reply to: