ImportC and #pragma pack
Steven Schveighoffer
schveiguy at gmail.com
Thu Sep 30 11:46:01 UTC 2021
On 9/29/21 8:53 PM, Walter Bright wrote:
> On 9/29/2021 1:21 PM, Steven Schveighoffer wrote:
>> Might I suggest -- you are going to have to preprocess the file
>> anyway. If you filter the preprocessor results through another
>> processor that "fixes" these things (like changes #pragma pack into D
>> `align` directives), then you have room to deal with nutburgers.
>
> It's not the implementation difficulty, it's more the opening of
> "support every extension every C compiler ever added" kind of thing.
>
> Besides, the #pragma pack is never properly documented. For example,
>
> struct S
> #pragma pack(1)
> { ...
> #pragma pack()
> ...
> };
>
> supposed to do? It wretchedly mixes up the preprocessor and the core
> language syntax in a completely undocumented manner (and they're
> supposed to be separate languages).
I may not have expressed what I meant clearly. The ImportC compiler can
avoid dealing with this issue at all, as long as you specify that the
preprocessing step handles it.
What I mean is, the C preprocessor, and let's call it the
nutburgerprocessor, are 2 filters that the file must run through before
it gets to C11/ImportC style code that is then usable by the D compiler.
When I say C11/ImportC, I am acknowledging that C11 doesn't provide a
viable alternative to #pragma pack. I'd suggest just handling align
directives as they are in D, since I'm pretty sure that syntax isn't
valid C11 anyway.
This way, any bizzare C extensions can be supported by supplying the
build chain with an appropriate converter.
Alternatively, you can pick one #pragma pack implementation and support
that, and if someone is building on a C compiler that supports different
semantics, they have to work out the difference.
-Steve
More information about the Digitalmars-d
mailing list