ImportC and #pragma pack

[Steven Schveighoffer]

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