[tz] [PROPOSED 00/18] tzselect improvements for configuring "from now on"

[Paul Eggert]

On 2023-12-21 03:46, Dimitry Andric wrote:


> The problem is that c99 effectively runs "cc -std=iso9899:1999 -pedantic". _Generic is a C11 extension so it will then warn about that.

Thanks for doing the testing. I ran into that bug with _Generic on 
FreeBSD 14 and installed the following workaround, which fixed things 
for me:

https://mm.icann.org/pipermail/tz/2023-December/033364.html

so if you do a "git pull" I hope this problem is fixed on FreeBSD 
15-CURRENT as well.

I view this as merely a bug in how clang does things. When you run 
'make' in POSIX mode (by putting a ".POSIX:" line at the start of the 
Makefile), 'make' defaults CC to c99 (as current POSIX requires). In 
tzcode, even before the abovementioned patch, all uses of _Generic were 
protected by "#if __has_extension(c_generic_selections)" but clang 
complain about the uses anyway. The patch works around this clang bug by 
ignoring '#if __has_extension(c_generic_selections)' when it succeeds.

If clang is going to diagnose any use of an extension X, then 
__has_extension(X) should be false. Perhaps the clang folks could 
implement this suggestion.


> The easiest workaround is to not use c99, but "cc -std=c11", optionally with "-pedantic", that will work just fine even with ce293ccb574a77956c758a81287dbc8ef4f4eedf reverted.

You can do that by editing the "#CC = ..." line in the tzcode Makefile, 
or by running "make CC='cc -std=c11'". We can't make these changes in 
tzcode's distributed Makefile, though, as that wouldn't be portable.


> In addition, -pedantic is known to complain about GNU extensions such as __builtin_offsetof. There is not much you can do about that, since we make extensive use of such extensions in the FreeBSD system headers.

Yes, your email contained the following messages indicating this problem:

> zic.c:2395:11: warning: defining a type within '__builtin_offsetof' is a Clang extension [-Wgnu-offsetof-extensions]
>  2395 |                                       alignof(zic_t)));
>       |                                       ^~~~~~~~~~~~~~
> zic.c:74:33: note: expanded from macro 'alignof'
>    74 | # define alignof(type) offsetof(struct { char a; type b; }, b)
>       |                                 ^~~~~~
> /usr/include/stddef.h:71:42: note: expanded from macro 'offsetof'
>    71 | #define offsetof(type, field)   __offsetof(type, field)
>       |                                            ^~~~
> /usr/include/sys/cdefs.h:424:53: note: expanded from macro '__offsetof'
>   424 | #define __offsetof(type, field)  __builtin_offsetof(type, field)
>       |                                                     ^~~~

I don't see this message in FreeBSD 14, so this is a regression in 
FreeBSD 15. And it appears to be another bug in FreeBSD and/or clang. 
First, any code using __builtin_offsetof is using a GNU extension, so 
why warn about __builtin_offsetof with a particular argument that 
happens to be a new type? And second, "__builtin_offsetof(struct { char 
a; type b; }, b)" doesn't define any type that can be used anywhere 
else, so why warn about the type? And third, there's nothing in C99 that 
prohibits the use of "offsetof(struct { char a; type b; }, b)" and it 
works on every C99 platform, so why warn about it?

I reproduced the problem on Fedora 39 with "make CC='clang 
-std=iso9899:1999 -pedantic'", and attempted to pacify clang with the 
attached patch, but that merely changed the diagnostics to be something 
like this:

zic.c:2408:11: warning: '_Alignof' is a C11 extension [-Wc11-extensions]
  2408 |                                       alignof(zic_t)));
       |                                       ^
/usr/bin/../lib/clang/17/include/stdalign.h:19:17: note: expanded from 
macro 'alignof'
    19 | #define alignof _Alignof
       |                 ^
1 warning generated.

Since this bug is only a warning, perhaps we should give up trying to 
work around it. I hope the clang folks fix the bug eventually.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd.patch
Type: text/x-patch
Size: 2053 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20231221/a7f52147/attachment.bin>