Date: Fri, 10 Jun 2022 15:54:26 +0000
[Daniel]
> On second thought, this would actually be a good reason to turn system
> C headers into importable headers with explicit preprocessor arguments
> for how they should be translated.
That one is going to be very tricky - as I found out for example with (MSVC's) <math.h> (which eventually got fixed) and similar headers whose inclusion are not idempotent.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Friday, June 10, 2022 8:30 AM
To: Ben Boeckel <ben.boeckel_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>; Daniel Ruoso via SG15 <sg15_at_[hidden]>
Subject: Re: [SG15] Header units and dependency scanning
Em sex., 10 de jun. de 2022 ās 10:36, Daniel Ruoso <daniel_at_[hidden]> escreveu:
> An importable header is a header where the state of the preprocessor
> at the point of inclusion is not meant to semantically change how the
> header should be translated, and where isolation from that state is
> desirable.
On second thought, this would actually be a good reason to turn system
C headers into importable headers with explicit preprocessor arguments
for how they should be translated.
Over the years I have seen many cases of confusion caused by half of
the translation units of a project setting, for instance, large file
support in 32bit builds, which would lead to very unamusing
consequences. A project being able to say "I parse the system headers
unambiguously in this single way" seems like a very powerful thing.
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C99b98258683d4abcb03008da4af614d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637904718028982777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Rwi8yQ2xTkuAf0QzPhRw0ISgOOfH4p0amT7rmvCTGqg%3D&reserved=0
> On second thought, this would actually be a good reason to turn system
> C headers into importable headers with explicit preprocessor arguments
> for how they should be translated.
That one is going to be very tricky - as I found out for example with (MSVC's) <math.h> (which eventually got fixed) and similar headers whose inclusion are not idempotent.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Friday, June 10, 2022 8:30 AM
To: Ben Boeckel <ben.boeckel_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>; Daniel Ruoso via SG15 <sg15_at_[hidden]>
Subject: Re: [SG15] Header units and dependency scanning
Em sex., 10 de jun. de 2022 ās 10:36, Daniel Ruoso <daniel_at_[hidden]> escreveu:
> An importable header is a header where the state of the preprocessor
> at the point of inclusion is not meant to semantically change how the
> header should be translated, and where isolation from that state is
> desirable.
On second thought, this would actually be a good reason to turn system
C headers into importable headers with explicit preprocessor arguments
for how they should be translated.
Over the years I have seen many cases of confusion caused by half of
the translation units of a project setting, for instance, large file
support in 32bit builds, which would lead to very unamusing
consequences. A project being able to say "I parse the system headers
unambiguously in this single way" seems like a very powerful thing.
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C99b98258683d4abcb03008da4af614d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637904718028982777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Rwi8yQ2xTkuAf0QzPhRw0ISgOOfH4p0amT7rmvCTGqg%3D&reserved=0
Received on 2022-06-10 15:54:28