Ping...
On 10/24/16 15:36, Bernd Edlinger wrote: > 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.