Header file cleanup for C++20 header-units #18221
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- they do not require previously-included headers to provide typedefs
and what not.
This addresses 2 problems discovered when using clang modules (as a
proxy for C++20 header-units).
a) Some headers that pay attention to OPENSSL_NO_STDIO to determine
whether to declare certain FILE*-taking functions do not #include
<stdio.h> themselves, relying on their includer already having done
that. That breaks the above mentioned encapuslation requirement.
Fixed by conditionally including stdio.h in those headers. I chose to
always include stdio.h in such headers, even when they included
another such header that transitively included stdio. That way they
do not rely on an artifact of that intermediate header's behaviour.
b) Some headers have #includes inside 'extern "C" { ... }' regions.
That has a bad code-smell, but GCC and clang have extensions to permit
it with implementation-defined effects. Clang needs annotation on the
included files to know that they themselves are entirely inside a
similar region. GCC behavesq as-if there's an extern "C++" region
wrapping the included header (which must therefore wrap its contents
in extern "C", if that is what it wants. In effect the includer's
extern "C" region is just misleading. I didn't audit all the headers
for this, only those I noticed when addressing #a.
\#a is necessary to build the headers as a set of clang-modules. #b
is not necessary, but as I mentioned, avoids potentially
implementation-defined behaviour.
t8m
added
branch: master
github-actions
bot
added
the
severity: fips change
paulidale
approved these changes
May 3, 2022
paulidale
removed
the
approval: otc review pending
tmshort
approved these changes
May 5, 2022
tmshort
added
approval: done
|
oh, should have said, pretty sure I don't have write access to do the actual merge -- I don't expect to be making many contributions. |
|
The project's committers are the only people who can merge. One of them will process this in due course. |
|
24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually. |
|
Merged, thanks for the fixes. |
openssl-machine
pushed a commit
that referenced
this pull request
May 9, 2022
C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- they do not require previously-included headers to provide typedefs
and what not.
This addresses 2 problems discovered when using clang modules (as a
proxy for C++20 header-units).
a) Some headers that pay attention to OPENSSL_NO_STDIO to determine
whether to declare certain FILE*-taking functions do not #include
<stdio.h> themselves, relying on their includer already having done
that. That breaks the above mentioned encapuslation requirement.
Fixed by conditionally including stdio.h in those headers. I chose to
always include stdio.h in such headers, even when they included
another such header that transitively included stdio. That way they
do not rely on an artifact of that intermediate header's behaviour.
b) Some headers have #includes inside 'extern "C" { ... }' regions.
That has a bad code-smell, but GCC and clang have extensions to permit
it with implementation-defined effects. Clang needs annotation on the
included files to know that they themselves are entirely inside a
similar region. GCC behavesq as-if there's an extern "C++" region
wrapping the included header (which must therefore wrap its contents
in extern "C", if that is what it wants. In effect the includer's
extern "C" region is just misleading. I didn't audit all the headers
for this, only those I noticed when addressing #a.
\#a is necessary to build the headers as a set of clang-modules. #b
is not necessary, but as I mentioned, avoids potentially
implementation-defined behaviour.
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from #18221)
t8m
pushed a commit
to t8m/openssl
that referenced
this pull request
Nov 14, 2022
C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- they do not require previously-included headers to provide typedefs
and what not.
This addresses 2 problems discovered when using clang modules (as a
proxy for C++20 header-units).
a) Some headers that pay attention to OPENSSL_NO_STDIO to determine
whether to declare certain FILE*-taking functions do not #include
<stdio.h> themselves, relying on their includer already having done
that. That breaks the above mentioned encapuslation requirement.
Fixed by conditionally including stdio.h in those headers. I chose to
always include stdio.h in such headers, even when they included
another such header that transitively included stdio. That way they
do not rely on an artifact of that intermediate header's behaviour.
b) Some headers have #includes inside 'extern "C" { ... }' regions.
That has a bad code-smell, but GCC and clang have extensions to permit
it with implementation-defined effects. Clang needs annotation on the
included files to know that they themselves are entirely inside a
similar region. GCC behavesq as-if there's an extern "C++" region
wrapping the included header (which must therefore wrap its contents
in extern "C", if that is what it wants. In effect the includer's
extern "C" region is just misleading. I didn't audit all the headers
for this, only those I noticed when addressing #a.
\#a is necessary to build the headers as a set of clang-modules. #b
is not necessary, but as I mentioned, avoids potentially
implementation-defined behaviour.
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from openssl#18221)
(cherry picked from commit eab9dbb)
openssl-machine
pushed a commit
that referenced
this pull request
Nov 21, 2022
C++20 adds 'header units' as a stepping-stone to modules. Header
units are regular header-files that have a 'self-contained' property
-- they do not require previously-included headers to provide typedefs
and what not.
This addresses 2 problems discovered when using clang modules (as a
proxy for C++20 header-units).
a) Some headers that pay attention to OPENSSL_NO_STDIO to determine
whether to declare certain FILE*-taking functions do not #include
<stdio.h> themselves, relying on their includer already having done
that. That breaks the above mentioned encapuslation requirement.
Fixed by conditionally including stdio.h in those headers. I chose to
always include stdio.h in such headers, even when they included
another such header that transitively included stdio. That way they
do not rely on an artifact of that intermediate header's behaviour.
b) Some headers have #includes inside 'extern "C" { ... }' regions.
That has a bad code-smell, but GCC and clang have extensions to permit
it with implementation-defined effects. Clang needs annotation on the
included files to know that they themselves are entirely inside a
similar region. GCC behavesq as-if there's an extern "C++" region
wrapping the included header (which must therefore wrap its contents
in extern "C", if that is what it wants. In effect the includer's
extern "C" region is just misleading. I didn't audit all the headers
for this, only those I noticed when addressing #a.
\#a is necessary to build the headers as a set of clang-modules. #b
is not necessary, but as I mentioned, avoids potentially
implementation-defined behaviour.
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from #18221)
(cherry picked from commit eab9dbb)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
C++20 adds 'header units' as a stepping-stone to modules. Header units are regular header-files that have a 'self-contained' property -- essentially they do not require previously-included headers to provide typedefs and what not.
This addresses 2 problems discovered when using clang modules (as a proxy for C++20 header-units).
a) Some headers that pay attention to OPENSSL_NO_STDIO to determine whether to declare certain FILE*-taking functions do not #include <stdio.h> themselves, relying on their includer already having done that. That breaks the above mentioned encapuslation requirement. Fixed by conditionally including stdio.h in those headers. I chose to always include stdio.h in such headers, even when they included another such header that transitively included stdio. That way they do not rely on an artifact of that intermediate header's behaviour.
b) Some headers have #includes inside 'extern "C" { ... }' regions. That has a bad code-smell, but GCC and clang have extensions to permit it with implementation-defined effects. Clang needs annotation on the included files to know that they themselves are entirely inside a similar region. GCC behaves as-if there's an extern "C++" region wrapping the included header (which must therefore wrap its contents in extern "C", if that is what it wants. In effect the includer's extern "C" region is just misleading. I didn't audit all the headers for this, only those I noticed when addressing #a.
#a is necessary to build the headers as a set of clang-modules. #b is not necessary, but as I mentioned, avoids potential
implementation-defined behaviour.
[Contribution assignment is now on file]