Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119337
Message-ID: <c8ed719c-9759-64a8-f372-54bad84b55d1@bastelstu.be>
Date: Wed, 18 Jan 2023 22:19:50 +0100
MIME-Version: 1.0
Content-Language: en-US
To: =?UTF-8?Q?Fl=c3=a1vio_Heleno?= <flaviohbatista@gmail.com>
Cc: internals@lists.php.net
References: <Y8U9B4AVP/R7vazI@swift.blarg.de>
 <CAGBsUrdQAXE2qk_UDQY9v6pYpWH+=bX6S3ou+sttQamtDC1F9A@mail.gmail.com>
 <Y8VI5yanzli8D4Cm@swift.blarg.de>
 <alpine.DEB.2.23.453.2301181536160.23089@singlemalt.home.derickrethans.nl>
 <Y8gZWLQd1SvL6a3n@swift.blarg.de>
 <8DA390C5-5E67-4847-A89F-1A8CCC6C5389@gmail.com>
 <CAGBsUrcHNeMYC1bSUkRgp2YNWjQJFojBxw43gcy3dkzEZfF4wg@mail.gmail.com>
 <419f4c45-8171-1051-8956-175283fb6669@bastelstu.be>
 <CAAwFBqq5S2BC+_mYj42hpR5h9_NNcqWtvt6SyqXVF2rfkTBGng@mail.gmail.com>
In-Reply-To: <CAAwFBqq5S2BC+_mYj42hpR5h9_NNcqWtvt6SyqXVF2rfkTBGng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 1/18/23 21:37, Flávio Heleno wrote:
> This may be a silly question, but in that case, wouldn't #ifdef guards keep
> the compiler from including/parsing a.h twice?

It's complicated. Modern compilers may include an optimization for 
include guards 
(https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html), but 
those rules may only be applied fairly narrowly.

I just recompiled gammasection.c in ext/random [1] which is a fairly 
simple file containing just a handful of files and traced the compiler 
with 'strace' for the 'openat' syscalls:

In total 2488 openat syscalls (many of them resulting in ENOENT, because 
of multiple include paths) were performed by the compiler. Multiple of 
my system headers were opened several times, because the include guard 
optimization could not be applied to them. I'm also seeing duplicated 
PHP headers:

>      20 "/usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h",
>      13 "/usr/include/x86_64-linux-gnu/bits/mathcalls-narrow.h",
>      11 "/usr/include/x86_64-linux-gnu/bits/wordsize.h",
>       8 "/usr/include/x86_64-linux-gnu/bits/mathcalls.h",
>       6 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h",
>       5 "/usr/lib/gcc/x86_64-linux-gnu/9/include/limits.h",
>       4 "/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h",
>       3 "/usr/include/assert.h",
>       3 "./php-src/Zend/zend_hash.h",
>       3 "./php-src/Zend/zend.h",
>       2 "/usr/lib/gcc/x86_64-linux-gnu/9/include/stdarg.h",
>       2 "/usr/lib/gcc/x86_64-linux-gnu/9/include/mm_malloc.h",
>       2 "/usr/lib/gcc/x86_64-linux-gnu/9/include/emmintrin.h",
>       2 "/usr/include/x86_64-linux-gnu/bits/long-double.h",
>       2 "./php-src/Zend/zend_string.h",
>       2 "./php-src/Zend/zend_stream.h",
>       2 "./php-src/Zend/zend_stack.h",
[1] https://github.com/php/php-src/blob/master/ext/random/gammasection.c

> When a.h is *not* required by any of b.h, c.h nor foo.c, I agree that it
> should *not* be included at all, but when any of them,

Ideally the scope of each individual header would also be narrowed to 
reduce the number of required dependencies.

Staying at the gammasection.c example from above: Ideally it should not 
be necessary to include the 20 kB zend_string.h twice, because the 
gammasection.c does not use strings at all. Likewise the 50 kB 
zend_hash.h is included three times and not used it all. With the amount 
of C files this adds up.

Best regards
Tim Düsterhus