Re: New version of function mkdirhier()
Svante Signell, le Fri 13 Jan 2012 12:31:22 +0100, a écrit :
> On Fri, 2012-01-13 at 11:28 +0100, Richard Braun wrote:
> > On Fri, Jan 13, 2012 at 10:33:23AM +0100, Svante Signell wrote:
> > > Maybe you can find
> > > a smart solution, I haven't. Are you ever happy with code written by
> > > somebody else than yourself?
> > > BTW: what happened with the psmisc patch you promised a long time ago?
> >
> > Again, that damn attitude with regard to comments. Why would we even
> > waste time helping you when chances are you'll just insult peolpe in
> > return.
>
> I would prefer that Guillem answers himself, not you. Are you his
> advocate?
I'm answering for Richard :)
No, but Guillem probably feels the same, and I do too: it's hard to tell
you anything because you quickly get things personally. 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. I'm really balanced in my time between 1) managing reviews for
you patches, which takes time, but also benefits from the time you have
spent, or 2) just work on stuff without dealing with your mails, which
means your contribution and worktime gets lost.
> BTW: How many patches to Debian packages do you create per
> day, I haven't seen any?
That does not really matter here.
> > 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.
> > It solves the size problem while limiting the number of
> > changes, making it easier for whoever maintains the original code to
> > accept the patch. As for the cons you mentioned, he did answer about
> > that too (there is no portability issue since there are replacements
> > if the system doesn't provide all the non standard functions, and most
> > str* functions are only dangerous when misused).
>
> 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.
> > Personnally, I'd advise against using srtncat(). Ever. Confusing and
> > almost useless since it still requires maintaining string sizes, which,
> > as Guillem mentioned, usually leads to more code complexity, making
> > the result even more confusing. Such confusion is what makes C string
> > operations so error prone.
>
> 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.
Samuel
Reply to: