Re: implicit declaration of function 'utime' in trailing slashes test

["Tim Rühsen" <tim.ruehsen@gmx.de>]

[-- Attachment #1.1: Type: text/plain, Size: 4071 bytes --]



On 23.01.21 07:09, Ryan Schmidt wrote:
> On Jan 22, 2021, at 16:47, Tim Rühsen wrote:
> 
>> On 21.01.21 01:34, Ryan Schmidt wrote:
>>> Hi, I'm the maintainer of wget in MacPorts.
>>> In the version of clang included with Xcode 12 and later, implicit declaration of functions is an error.
>>> During configure, wget 1.12.1 prints this:
>>> checking whether utime handles trailing slashes on files... no
>>> config.log contains this:
>>> configure:49368: checking whether utime handles trailing slashes on files
>>> configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os -Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c  >&5
>>> conftest.c:491:23: error: implicit declaration of function 'utime' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>>>                   if (!utime ("conftest.tmp/", NULL))
>>>                        ^
>>> 1 error generated.
>>> configure:49414: $? = 1
>>> configure: program exited with status 1
>>> So the results of this test don't represent what you want them to.
>>> This configure test uses #include <time.h>. The problem goes away if I change that to #include <utime.h>. Then configure output is still:
>>> checking whether utime handles trailing slashes on files... no
>>> but config.log then contains:
>>> configure:49368: checking whether utime handles trailing slashes on files
>>> configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os -Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c  >&5
>>> configure:49414: $? = 0
>>> configure:49414: ./conftest
>>> configure:49414: $? = 2
>>> configure: program exited with status 2
>>> Now the results of the test are accurate.
>>> I included this patch in the MacPorts wget 1.12.1 port:
>>> https://github.com/macports/macports-ports/blob/13fd7facb9e1ea9e70b79c8c0b429058b9bb8698/net/wget/files/implicit.patch
>>> Of course you'll want to patch m4/utime.m4 instead of configure.
>>
>> ./configure scripts are not made for using -Werror in CFLAGS.
>>
>> This is documented somewhere but (sorry), I am just too tired to search for the URL right now.
> 
> Unfortunately, you no longer have much of a choice. Treating implicit declarations of functions as an error is the *default* behavior of the compiler included with Xcode 12 and later.
> 
> In the output I showed above I have specified -Werror=implicit-function-declaration manually in CFLAGS because I am using an earlier version of Xcode but I want to simulate the experience of an Xcode 12 user so that I can identify and fix this type of problem.
> 
> Apple intentionally changed the default behavior of the compiler in order to be able to ship Macintosh computers with ARM processors ("Apple Silicon"). ARM processors have different calling conventions for variadic and non-variadic functions, so the compiler must know before you call a function what type of function it is, and the way it knows that is by the function declaration.
> 
> The C99 standard requires that you declare functions before you use them. It has been this way for over 2 decades. wget should do so in all of its code, regardless of whether the code is in a configure test or elsewhere.
> 
> This one configure test that I mentioned is the only place where I noticed a problem, so as far as I know only the one-byte change I proposed above needs to be made.

Thanks for the explanation, that makes it clearer now (and possibly my 
brain is not as mushed as during my last read/answer).

The code involved here comes directly from gnulib and is not part of the 
wget project. The issue affects not only wget and any patching here is 
mostly lost time/efford.

So I am adding the gnulib mailing list to the recipients as IMO this 
issue should be discussed/answered there. It will be read by people with 
more related expertise than I can provide.

Regards, Tim


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]