Hi! I'd like to ping for my patch here: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01348.html
Thanks Bernd. On 10/17/16 21:18, Bernd Edlinger wrote: > On 10/17/16 20:05, Joseph Myers wrote: >> On Sun, 16 Oct 2016, Bernd Edlinger wrote: >> >>> Second, the declaration in the glibc header files simply look wrong, >>> because the type of argv, and envp is "char *const *" while the >>> builtin function wants "const char**", thus only the array of char* >>> itself is const, not the actual char stings they point to. >> >> char *const * is the POSIX type. (It can't be const char ** or const >> char >> *const * because you can't convert char ** implicitly to those types in >> ISO C.) You'd need to check the list archives for rationale for the >> built-in functions doing something different. >> > > Yes, that was discussed here: > https://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html > > No mention why the BT_PTR_CONST_TYPE does not match the posix type. > But the right types were used on __gcov_execv/e/p stubs, so the author > did know the right types at least. > > So I think that was broken from the beginning, but that was hidden by > the loose checking in the C FE and not warning in the C++ FE when > prototypes don't match. > >>> Third, in C the builtins are not diagnosed, because C does only look >>> at the mode of the parameters see match_builtin_function_types in >>> c/c-decl.c, which may itself be wrong, because that makes an ABI >>> decision dependent on the mode of the parameter. >> >> The matching needs to be loose because of functions using types such as >> FILE * where the compiler doesn't know the exact contents of the type >> when >> processing built-in function definitions. (Historically there were also >> issues with pre-ISO headers, but that may be less relevant now.) >> > > The C++ FE has exactly the same problem with FILE* and struct tm* > but it solves it differently and "learns" the type but only for FILE* > and with this patch also for const struct tm*. It is a lot more > restrictive than C, but that is because of the ++ ;) > > Well in that case the posix functions have to use the prototypes > from POSIX.1.2008 although their rationale is a bit silly... > > This updated patch fixes the prototype of execv/p/e, > and adds a new test case that checks that no type conflict > exists in the execve built-in any more. > > Now we have no -Wsystem-headers warnings with glibc-headers any more. > And the gcov builtin also is working with C++. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > > > Thanks > Bernd.
