Le mardi 29 avril 2008 à 13:16 +0200, Jim Meyering a écrit : > Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote: > > Le lundi 28 avril 2008 à 22:40 +0200, Jim Meyering a écrit : > >> Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote: > >> > Le samedi 26 avril 2008 à 02:31 +0200, Bruno Haible a écrit : > >> >> Yoann Vandoorselaere wrote: > >> >> > I guess mkdir could use the original malloc implementation, returning > >> >> > an > >> >> > error on allocation failure. Or is that a problem? > >> >> > >> >> Sounds ok to me: There is no reason why a system call replacement like > >> >> mkdir() > >> >> should not report its allocation failures through -1/ENOMEM. Care to > >> >> provide > >> >> a patch that is acceptable to Jim? > >> > >> > Attached. > >> > >> Changing the mkdir wrapper to fail with ENOMEM is fine, > >> since mkdir is already specified to fail with ENOMEM. > >> > >> However, your patch also changes basename.c and dirname.c. > >> Did you mean to include those? > > > > Theses are not required, however it would be nice to move the > > strip_trailing_slashes() function in it's own separate module, so that > > mkdir doesn't have to pull the whole dirname dependencies. > > > > Does that sound good? > > Sure. Will you write the patch?
After looking at it more, this would involve splitting the dirname module into dirname/basename, which wouldn't be practical since they share a lot of definition. It might be better to convert the dirname module to not use xalloc(), and make sure the caller handle the error fine. Do you agree on this? > >> We can't change the base_name and dir_name APIs so lightly. Callers of > >> those functions currently require a non-NULL return value, and with > >> your change, they would all have to adapt to handle NULL. > >> > >> > Is the license change ok thought? > >> > >> I'll change the mkdir license to LGPL. > >> Or do you require LGPLv2+? > > > > For Prelude, we need the LGPLv2+ license. Ok with you? > > Done. Thanks! Additionally, can we make the dirname dependencie LGPLv2+ licensed too? -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
