ImportC and #pragma pack (page 4)

On Wednesday, 29 September 2021 at 17:25:51 UTC, Imperatorn wrote: > My vote is for supporting it. That way it will be complete, and I remember seeing it around networking and serialization contexts for example. I tried asking in some c/c++ forums and got an estimate at around 3-5% of stuff use it according to them. Not much, but also not below 1%. I would also vote for that particular feature. I've also come across it in serialization context, but also many times in the embedded system low-level context to describe memory-mapped devices. As to how open should ImportC be to C extensions, I have no idea.

On Thursday, 30 September 2021 at 07:01:07 UTC, Claude wrote: > On Wednesday, 29 September 2021 at 17:25:51 UTC, Imperatorn wrote: >> My vote is for supporting it. That way it will be complete, and I remember seeing it around networking and serialization contexts for example. I tried asking in some c/c++ forums and got an estimate at around 3-5% of stuff use it according to them. Not much, but also not below 1%. > > I would also vote for that particular feature. > > I've also come across it in serialization context, but also many times in the embedded system low-level context to describe memory-mapped devices. > > As to how open should ImportC be to C extensions, I have no idea. Windows, Linux/Android and macOS headers are full of C extensions, so I would say for ImportC to be of value for systems programming on those platforms, it needs to at very least be able to understand those extensions.

September 30, 2021

Re: ImportC and #pragma pack

Posted by Steven Schveighoffer
in reply to Walter Bright

Permalink

Steven Schveighoffer

Posted in reply to Walter Bright

Permalink

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

On Thursday, 30 September 2021 at 00:53:27 UTC, Walter Bright wrote:

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).

Let's see. Since it's not documented, it'd be unwise to write a struct like that. So, if I somehow had a C struct like that, I'd want an error. Then I'd move #pragma pack(1) either above or below the whole struct start depending on what I meant.

Well, there might be some unwritten convention on how the compilers handle this but as long as we are not aware of one, it's best to do the right thing.

On Thursday, 30 September 2021 at 09:05:50 UTC, Paulo Pinto wrote: > > Windows, Linux/Android and macOS headers are full of C extensions, so I would say for ImportC to be of value for systems programming on those platforms, it needs to at very least be able to understand those extensions. I'm looking at the VC headers coming with Visual Studio, and it seems you can go a long way with: #pragma once #pragma push_macro/pop_macro #pragma pack

On Thursday, 30 September 2021 at 11:54:21 UTC, Guillaume Piolat wrote: > On Thursday, 30 September 2021 at 09:05:50 UTC, Paulo Pinto wrote: >> >> Windows, Linux/Android and macOS headers are full of C extensions, so I would say for ImportC to be of value for systems programming on those platforms, it needs to at very least be able to understand those extensions. > > I'm looking at the VC headers coming with Visual Studio, and it seems you can go a long way with: > #pragma once > #pragma push_macro/pop_macro > #pragma pack Until you need to ingest stuff using SAL, COM, linker directives, calling conventions, Windows exception handling. All of which can pop up on header files.

On 9/30/2021 4:52 AM, Dukc wrote: > Let's see. Since it's not documented, it'd be unwise to write a struct like that. That has never, ever, stopped anyone before. People will often inadvertently discover a bug, then build their whole program around it. For an example, in the olden daze, a popular C comment style used at Microsoft was: //******************* Big Rocks and Tall Trees ********************\\ Note the last two characters. Microsoft C did not do \ line splicing per the C Standard. But my compiler did (yay!) But this code failed to compile: //******************* Big Rocks and Tall Trees ********************\\ int x; No matter how much I explained that this was a bug in Microsoft's compiler, it was my fault. I had to do what is called being "bug compatible" with Microsoft.

Forums