From: Markos C. <mar...@im...> - 2012-02-23 09:57:29
|
test_app is a read-only variable because it is defined as a preprocessor macro. Using basename() on this variable, it will most certainly lead to a segmentation fault in uClibc code. Moreover, there is no need to use basename() at all since the test_app variable is a single string and it does not contain any leading paths. Quote from uClibc's include/libgen.h header: "Return final component of PATH. This is the weird XPG version of this function. It sometimes will modify its argument. Therefore we normally use the GNU version (in <string.h>) and only if this header is included make the XPG version available under the real name. extern char *__xpg_basename (char *__path) __THROW; #define basename __xpg_basename" Signed-off-by: Markos Chandras <mar...@im...> --- testcases/kernel/syscalls/creat/creat07.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/testcases/kernel/syscalls/creat/creat07.c b/testcases/kernel/syscalls/creat/creat07.c index 3bb1288..294f998 100644 --- a/testcases/kernel/syscalls/creat/creat07.c +++ b/testcases/kernel/syscalls/creat/creat07.c @@ -91,7 +91,7 @@ int main(int ac, char **av) if (pid == 0) { char *av[2]; - av[0] = basename(test_app); + av[0] = test_app; av[1] = NULL; (void)execve(test_app, av, NULL); perror("execve failed"); @@ -147,7 +147,7 @@ void setup(char *app) tst_brkm(TBROK|TERRNO, NULL, "getcwd failed"); snprintf(test_path, sizeof(test_path), "%s/%s", - pwd, basename(test_app)); + pwd, test_app); free(pwd); } -- 1.7.1 |
From: Cyril H. <ch...@su...> - 2012-02-23 15:37:30
|
Hi! > test_app is a read-only variable because it is defined as a preprocessor macro. > Using basename() on this variable, it will most certainly lead to a segmentation > fault in uClibc code. Moreover, there is no need to use basename() at all since > the test_app variable is a single string and it does not contain any leading > paths. > > Quote from uClibc's include/libgen.h header: > > "Return final component of PATH. > This is the weird XPG version of this function. It sometimes will > modify its argument. Therefore we normally use the GNU version (in > <string.h>) and only if this header is included make the XPG > version available under the real name. > > extern char *__xpg_basename (char *__path) __THROW; > #define basename __xpg_basename" Well in glibc you get version that is not reentrant but doesn't modify the source string when _GNU_SOURCE is defined (which is defined in creat07.c), so this may be bug in uClibc compatibility. And I think that there is no reason to segfault when the argument doesn't need to be modified, which should be the case here. Or did the segfault occured in your enviroment? However commit this as the call is useless here. -- Cyril Hrubis ch...@su... |
From: Markos C. <Mar...@im...> - 2012-02-23 15:46:23
|
On 02/23/2012 03:38 PM, Cyril Hrubis wrote: > Hi! >> test_app is a read-only variable because it is defined as a preprocessor macro. >> Using basename() on this variable, it will most certainly lead to a segmentation >> fault in uClibc code. Moreover, there is no need to use basename() at all since >> the test_app variable is a single string and it does not contain any leading >> paths. >> >> Quote from uClibc's include/libgen.h header: >> >> "Return final component of PATH. >> This is the weird XPG version of this function. It sometimes will >> modify its argument. Therefore we normally use the GNU version (in >> <string.h>) and only if this header is included make the XPG >> version available under the real name. >> >> extern char *__xpg_basename (char *__path) __THROW; >> #define basename __xpg_basename" > > Well in glibc you get version that is not reentrant but doesn't modify > the source string when _GNU_SOURCE is defined (which is defined in > creat07.c), so this may be bug in uClibc compatibility. > > And I think that there is no reason to segfault when the argument > doesn't need to be modified, which should be the case here. Or did the > segfault occured in your enviroment? It segfaults if it modifies the argument because the argument is read-only. I don't remember when this function modifies the argument but it certainly is a bit dangerous to use a read-only variable when this function has known "weird" behaviour -- markos |
From: Cyril H. <ch...@su...> - 2012-02-23 15:56:09
|
Hi! > > Well in glibc you get version that is not reentrant but doesn't modify > > the source string when _GNU_SOURCE is defined (which is defined in > > creat07.c), so this may be bug in uClibc compatibility. > > > > And I think that there is no reason to segfault when the argument > > doesn't need to be modified, which should be the case here. Or did the > > segfault occured in your enviroment? > > > It segfaults if it modifies the argument because the argument is > read-only. I don't remember when this function modifies the argument but > it certainly is a bit dangerous to use a read-only variable when this > function has known "weird" behaviour Okay, commited. -- Cyril Hrubis ch...@su... |
From: Markos C. <Mar...@im...> - 2012-02-23 15:59:49
|
On 02/23/2012 03:56 PM, Cyril Hrubis wrote: > Hi! >>> Well in glibc you get version that is not reentrant but doesn't modify >>> the source string when _GNU_SOURCE is defined (which is defined in >>> creat07.c), so this may be bug in uClibc compatibility. >>> >>> And I think that there is no reason to segfault when the argument >>> doesn't need to be modified, which should be the case here. Or did the >>> segfault occured in your enviroment? >> >> >> It segfaults if it modifies the argument because the argument is >> read-only. I don't remember when this function modifies the argument but >> it certainly is a bit dangerous to use a read-only variable when this >> function has known "weird" behaviour > > Okay, commited. > Thanks :) -- markos |