Re: mkdir module license
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? 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? -- Yoann Vandoorselaere [EMAIL PROTECTED]
Re: mkdir module license
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? 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. 2008-04-29 Jim Meyering [EMAIL PROTECTED] * modules/mkdir (License): Re-license as LGPLv2+.
Re: mkdir module license
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]
Re: mkdir module license
Yoann Vandoorselaere [EMAIL PROTECTED] wrote: 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? 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. ...
Re: mkdir module license
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. Is the license change ok thought?
--
Yoann Vandoorselaere [EMAIL PROTECTED]
diff --git a/lib/basename.c b/lib/basename.c
index 426ed40..cf625d8 100644
--- a/lib/basename.c
+++ b/lib/basename.c
@@ -19,10 +19,7 @@
#include config.h
#include dirname.h
-
#include string.h
-#include xalloc.h
-#include xstrndup.h
/* Return the address of the last file name component of NAME. If
NAME has no relative file name components because it is a file
@@ -79,7 +76,7 @@ base_name (char const *name)
/* If there is no last component, then name is a file system root or the
empty string. */
if (! *base)
-return xstrndup (name, base_len (name));
+return strndup (name, base_len (name));
/* Collapse a sequence of trailing slashes into one. */
length = base_len (base);
@@ -91,7 +88,10 @@ base_name (char const *name)
with pure POSIX semantics, this is not an issue. */
if (FILE_SYSTEM_PREFIX_LEN (base))
{
- char *p = xmalloc (length + 3);
+ char *p = malloc (length + 3);
+ if (p == NULL)
+ return NULL;
+
p[0] = '.';
p[1] = '/';
memcpy (p + 2, base, length);
@@ -100,7 +100,7 @@ base_name (char const *name)
}
/* Finally, copy the basename. */
- return xstrndup (base, length);
+ return strndup (base, length);
}
/* Return the length of the basename NAME. Typically NAME is the
diff --git a/lib/dirname.c b/lib/dirname.c
index c27e5b5..f6b8c0c 100644
--- a/lib/dirname.c
+++ b/lib/dirname.c
@@ -21,7 +21,6 @@
#include dirname.h
#include string.h
-#include xalloc.h
/* Return the length of the prefix of FILE that will be used by
dir_name. If FILE is in the working directory, this returns zero
@@ -75,7 +74,10 @@ dir_name (char const *file)
|| (FILE_SYSTEM_DRIVE_PREFIX_CAN_BE_RELATIVE
length == FILE_SYSTEM_PREFIX_LEN (file)
file[2] != '\0' ! ISSLASH (file[2])));
- char *dir = xmalloc (length + append_dot + 1);
+ char *dir = malloc (length + append_dot + 1);
+ if (dir == NULL)
+return NULL;
+
memcpy (dir, file, length);
if (append_dot)
dir[length++] = '.';
diff --git a/lib/mkdir.c b/lib/mkdir.c
index 8073dc8..cc9cea0 100644
--- a/lib/mkdir.c
+++ b/lib/mkdir.c
@@ -29,7 +29,6 @@
#include string.h
#include dirname.h
-#include xalloc.h
/* Disable the definition of mkdir to rpl_mkdir (from the sys/stat.h
substitute) in this file. Otherwise, we'd get an endless recursion. */
@@ -53,7 +52,12 @@ rpl_mkdir (char const *dir, mode_t mode)
if (len dir[len - 1] == '/')
{
- tmp_dir = xstrdup (dir);
+ tmp_dir = strdup (dir);
+ if (tmp_dir == NULL)
+{
+ errno = ENOMEM;
+ return -1;
+}
strip_trailing_slashes (tmp_dir);
}
else
diff --git a/modules/dirname b/modules/dirname
index 7c405c2..5a8ca2d 100644
--- a/modules/dirname
+++ b/modules/dirname
@@ -12,8 +12,7 @@ m4/dos.m4
Depends-on:
double-slash-root
stdbool
-xalloc
-xstrndup
+strndup
configure.ac:
gl_DIRNAME
diff --git a/modules/mkdir b/modules/mkdir
index ed4ee10..532e2d1 100644
--- a/modules/mkdir
+++ b/modules/mkdir
@@ -7,7 +7,7 @@ m4/mkdir-slash.m4
Depends-on:
sys_stat
-xalloc
+strdup
dirname
configure.ac:
Re: mkdir module license
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? 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+?
Re: mkdir module license
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? Bruno
Re: mkdir module license
Yoann Vandoorselaere wrote: Would relicensing the mkdir module and it's dependencies from GPL to LGPL be envisageable? We would like to use this module from the Prelude library. Among these dependencies there is 'xalloc'. Which means that a a failure in a function of the Prelude library could bring down the entire program. Is this what you want? Bruno
Re: mkdir module license
Le jeudi 24 avril 2008 à 13:31 +0200, Bruno Haible a écrit : Yoann Vandoorselaere wrote: Would relicensing the mkdir module and it's dependencies from GPL to LGPL be envisageable? We would like to use this module from the Prelude library. Among these dependencies there is 'xalloc'. Which means that a a failure in a function of the Prelude library could bring down the entire program. Is this what you want? I guess mkdir could use the original malloc implementation, returning an error on allocation failure. Or is that a problem? -- Yoann Vandoorselaere [EMAIL PROTECTED]
