On Sat, Sep 04, 2021 at 05:19:21PM +0200, Florian Weimer wrote: > * Segher Boessenkool: > > > Let me quote the original mail (I had to dig it out of the archives as > > well, no nice threading, too lazy, sorry): > > It still doesn't say why. I did see a reference to fleeting reference > to <stdatomic.h> and <float.h>. Yeah... I dug out the actual patch from linux-kbuild: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild-v5.15&id=c0891ac15f0428ffa81b2e818d416bdf3cb74ab6 The reasoning in there is completely wrong. <stdarg.h> is not a "userspace header". Instead, it is a standard header, required for some functionality in C. It also says "GPL 2 version of <stdarg.h> can be extracted from http://archive.debian.org/debian/pool/main/g/gcc-4.2/gcc-4.2_4.2.4.orig.tar.gz"; which seems to suggest you cannot use stuff from GPLv3-licensed GCC. This is just wrong. The header in question says """ Under Section 7 of GPL version 3, you are granted additional permissions described in the GCC Runtime Library Exception, version 3.1, as published by the Free Software Foundation. """ And <https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=COPYING.RUNTIME> reads in part """ 1. Grant of Additional Permission. You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. """ which says that if you compile with GCC, then it is perfectly fine if it uses the standard C headers, it does not make your work GPL-licenced. > After all, <stdatomic.h> is exactly like <stdarg.h> in that it's > possible to use its functionality even without the header file. The > __atomic builtins are even documented in the GCC manual (unlike > <stdatomic.h>), which is why some programmers prefer them over the > standard interface. And then there's the _Atomic keyword itself, whose > use can easily result in calls to libatomic functions, too. So blocking > <stdatomic.h> makes little sense to me. > > I don't know enough about softfloat if blocking the inclusion of > <float.h> is worth it. Blocking the use of <float.h> is pretty useless: it is possible to do millions of things in the kernel source that are frowned upon, or actively bad, or anything in between or more extreme. That is what code review is for. If it would be a common mistake (it is not afaik) you can warn for it from checkpatch.pl or something. The patch is just re-implementing part of the standard GCC <stdarg.h>, so that it will only work with recent GCC (and maybe clang as well if it implements the GCC internal interfaces correctly (i.e. compatibly) here, and the same for other compilers). Almost all of the <stdarg.h> GCC itself uses is the same, but it also is compatible to the various C standards if this header is included indirectly. That is all just some ifdeffery anyway, so doesn't influence compilation times noticeably, and all that. - * - So as far as I can see the motivation behind the patch is a) a misunderstanding of what standard C headers are, are for, etc.; and b) a misunderstanding of the GPL and the GCC runtime exception to it. The patch makes things worse than they were. If on the contrary Linux would use *more* standard compiler headers, say <stddef.h>, then insidious bugs like that fixed by c46bbf5d2def would be prevented. Segher
