Re: New version of function mkdirhier()
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:
> > The problem with dynamic string allocation is that you cannot free
> > strings being modified by the functions, like strsep.
>
> What ? Memory allocation has almost nothing to do with string operations
> (except for strdup()). Here, strsep() modifies the string in place,
> which means your buffer address doesn't change. You just have to save it
> and free() it when you're done...
But we are talking strdup here. Regarding free(), see my comment to
Samuel.
> > 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? BTW: How many patches to Debian packages do you create per
day, I haven't seen any? Only Samuel, Pino and me have submitted recent
bug reports. Yes, I know you are working on the gnumach/hurd
functionality, and this is a good thing (tm). Not many people contribute
in this area and all such contributions are of course more worth than
porting buggy, non-maintained old code.
> Of course he's happy with code he didn't write himself, when
> such code is decent. You're making beginner mistakes in yours and
> don't understand when a more experienced person is trying to explain
> them. Worse, you make it personal. Stop it, or you'll just get ignored
> by everyone who currently cares about what you're doing.
Again, let him answer. And the more you look at code the more you find
out how large amounts of crappy code there are.
> Now back to the technical stuff. I believe Guillem's solution is quite
> appropriate.
I did not see any proposed solution.
> 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).
> 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.
Reply to: