[PING**2] [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

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.