On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote: > builtins.def:635: DEF_EXT_LIB_BUILTIN (BUILT_IN_EXECVE, > "execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING, > ATTR_NOTHROW_LIST) > > Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING > a weird bug? > > The correct const symbol is BT_FN_INT_CONST_STRING_PTR_CONST_STRING
I'm sorry, after reading deeply it, i found that it's not a bug. The more weird thing was "..." in middle of the C's stack from int execle(const char *path, const char *arg, ..., char * const envp[]); extracted from "man execle". DEF_EXT_LIB_BUILTIN (BUILT_IN_EXECLE, "execle", BT_FN_INT_CONST_STRING_CONST_STRING_VAR, ATTR_NOTHROW_SENTINEL_1) It shows that SENTINEL and 1 are the unique representation different to the rest. It's better to say to the programmers "don't use execle because it manipulates badly the C's stack" It's posible that execle can be dangerous as the SSP's canary can be flawed. Why don't they correct the below specification to use? int execel(const char *path, const char *arg, char * const envp[], ...); instead of flawed int execle(const char *path, const char *arg, ..., char * const envp[]); > Please, to revise the builtins const symbols from > execl, execlp, execle, execv, execvp and execve > because they use different const symbols for co-similar exec?* J.C.Pizarro
