bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mkdir module license


From: Jim Meyering
Subject: Re: mkdir module license
Date: Wed, 30 Apr 2008 00:03:02 +0200

Yoann Vandoorselaere <address@hidden> wrote:

> Le mardi 29 avril 2008 à 13:16 +0200, Jim Meyering a écrit :
>> Yoann Vandoorselaere <address@hidden> wrote:
>> > Le lundi 28 avril 2008 à 22:40 +0200, Jim Meyering a écrit :
>> >> Yoann Vandoorselaere <address@hidden> 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?

I'm reluctant to change dirname's (dir_name's) API that way,
after so long.  I agree that it'd be better to have a different
API, but changing it in this manner seems unwise.

Here's a possibility:
stripslash.c needs two functions from basename.c,
last_component and base_len, neither of which performs memory
allocation.  I suggest you consider creating a new file, e.g.,
basename-tools.c and put them in it, with its own .h file
(or maybe just use dirname.h).  Then create your stripslash
module and adjust the basename and dirname modules to include
the new file(s).

>> >> 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.
...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]