Re: New version of function mkdirhier()
On Fri, 2012-01-13 at 14:55 +0100, Richard Braun wrote:
> On Fri, Jan 13, 2012 at 12:31:22PM +0100, Svante Signell wrote:
> No, we're talking strsep(). See Samuel's reply "make a copy of the
> pointer" which is exactly what I meant here by "You just have to save
> it".
Like this?
int fcn(char *path)
{
char *src, *src_ptr;
src = strdup(path);
src_ptr = src;
<modify pointer src>
free(src_ptr);
...
}
> I value quality more than quantity. But I disagree about the "worth" of
> such types of work. Porting is as valuable (I'd tend to say even more
> considering the current state of the project) as system functionality.
Why, there is still much basic functionality missing for the Hurd.
> But just as I force myself to write proper code before submitting it
> for integration into kernel/system stuff, I expect porters to do just
> the same with their contributions. And if others report problems, I
> consider their comments and adjust the result accordingly. Again, I
> expect others to do the same, which includes you.
Of course, but porting varying quality code is different from writing
new "perfect" code.
> As for replying on
> Guillem's behalf, you got it wrong. I was replying for myself since you
> asked me to review your patch, which I did only after Guillem and Samuel
> replies were posted.
OK!
> Your goal here was to fix a PATH_MAX related
> issue, not fix the original code use of strlcpy/strlcat/whatever. The
> original code being crappy (which isn't even the case here)
I agree the current code is not crappy, it merely use functions not
recommended for use today.
> has usually
> little to do with that goal (except if it's so crappy it prevents you
> from replacing PATH_MAX related code easily).
>
> > > Now back to the technical stuff. I believe Guillem's solution is quite
> > > appropriate.
> >
> > I did not see any proposed solution.
>
> Quoting: "So I'd say, just switch the code to dynamically allocate the
> strings, and let it use strlcat/strlcpy/strsep, etc."
OK, I took the risk of writing a completely new function, not fixing the
old code, for reasons given above and before. I know there will be
problems to get it accepted by the current Debian Maintainer (DM) (no
upstream) but I found it to be a good exercise for me in getting more
acquainted with this kind of coding.
I'll make a patched versions of the old code and submit two alternate
patches, one with the old patched mkdirhier and one with the new
version.
Thank you for your time.
Reply to: