www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC and #pragma pack

reply Walter Bright <newshound2 digitalmars.com> writes:
https://issues.dlang.org/show_bug.cgi?id=22315

I'm on the fence about implementing this. On the one hand, I can do it and make 
it work. On the other hand, the C11 way is to use _Alignas, and that's 10 years 
old now. How far do we go with implementing all the nutburger obsolete C 
extension cruft out there?
Sep 27 2021
next sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 How far do we go with implementing all the nutburger obsolete C 
 extension cruft out there?


The whole point of importc is compatibility, no?  So I say: all 
the way.
Sep 27 2021
next sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 28 September 2021 at 06:30:09 UTC, Elronnd wrote:

 On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
 wrote:

 How far do we go with implementing all the nutburger obsolete 
 C extension cruft out there?


 The whole point of importc is compatibility, no?  So I say: all 
 the way.


I second this, otherwise it's sort of pointless if it isn't 
entirely compatible.
Sep 28 2021
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 28 September 2021 at 06:30:09 UTC, Elronnd wrote:

 On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
 wrote:

 How far do we go with implementing all the nutburger obsolete 
 C extension cruft out there?


 The whole point of importc is compatibility, no?  So I say: all 
 the way.


Compatibility with what? Are there projects using pragma pack as 
part of a stable API?
Sep 28 2021
parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 08:54:00 UTC, max haughton wrote:

 On Tuesday, 28 September 2021 at 06:30:09 UTC, Elronnd wrote:

 On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
 wrote:

 How far do we go with implementing all the nutburger obsolete 
 C extension cruft out there?


 The whole point of importc is compatibility, no?  So I say: 
 all the way.


 Compatibility with what? Are there projects using pragma pack 
 as part of a stable API?


Absolutely.
For example the VST3 SDK 
https://github.com/steinbergmedia/vst3_pluginterfaces/blob/b8566ef3b2a0cba60a96e3ef2001224c865c8b36/base/falignpush.h

This header is then included before every struct definition.
It's very easy after a D translation to have an ABI problem 
because of this, so SDK writers have written sizeof checks.
Sep 28 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 5:54 AM, Guillaume Piolat wrote:

 For example the VST3 SDK 
 https://github.com/steinbergmedia/vst3_pluginterfaces/blob/b8566ef3b2a0cba60a96e3ef2001224c865c8b
6/base/falignpush.h 
 
 
 This header is then included before every struct definition.
 It's very easy after a D translation to have an ABI problem because of this,
so 
 SDK writers have written sizeof checks.


Filed a bug report on it:
https://github.com/steinbergmedia/vst3_pluginterfaces/issues/9

While that won't change our decision, I encourage people to file bug reports on 
projects that use #pragma pack.
Sep 28 2021
parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 17:28:54 UTC, Walter Bright 
wrote:

 While that won't change our decision, I encourage people to 
 file bug reports on projects that use #pragma pack.


If so many C and C++ compilers started implementing #pragma pack 
to support these projects, it is doubtful these projects will 
move one bit for supporting a D compiler. Anyway.
Sep 28 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 12:40 PM, Guillaume Piolat wrote:

 On Tuesday, 28 September 2021 at 17:28:54 UTC, Walter Bright wrote:

 While that won't change our decision, I encourage people to file bug reports 
 on projects that use #pragma pack.


 
 If so many C and C++ compilers started implementing #pragma pack to support 
 these projects, it is doubtful these projects will move one bit for supporting
a 
 D compiler. Anyway.


I'm used to my bug reports being ignored!

Anyhow, pointing out non-standard constructs that can be replaced with standard 
ones is good for everyone, not just D.
Sep 28 2021
parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 23:16:28 UTC, Walter Bright 
wrote:

 Anyhow, pointing out non-standard constructs that can be 
 replaced with standard ones



But _Alignas strictly can't replace #pragma pack.

D's align(), C's _Alignas, and #pragma pack have 3 different 
semantics.

See https://ideone.com/bv6mET

- #pragma pack can only _reduce_ alignment requirements within a 
struct, NOT introduce additional padding

- _Alignas, contrarily, can only be used to _increase_ alignment 
and introduce padding, but cannot reduce the natural alignment of 
a field.

- D's align can both reduce and increase field alignment, which 
is of course the better option (https://ideone.com/TLSZUO)
Sep 28 2021
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 5:46 PM, Guillaume Piolat wrote:

 On Tuesday, 28 September 2021 at 23:16:28 UTC, Walter Bright wrote:

 Anyhow, pointing out non-standard constructs that can be replaced with 
 standard ones


 
 
 But _Alignas strictly can't replace #pragma pack.
 
 D's align(), C's _Alignas, and #pragma pack have 3 different semantics.
 
 See https://ideone.com/bv6mET
 
 - #pragma pack can only _reduce_ alignment requirements within a struct, NOT 
 introduce additional padding
 
 - _Alignas, contrarily, can only be used to _increase_ alignment and introduce 
 padding, but cannot reduce the natural alignment of a field.
 
 - D's align can both reduce and increase field alignment, which is of course
the 
 better option (https://ideone.com/TLSZUO)
 
 


C11 6.7.5-4 sez: "The combined effect of all alignment attributes in a 
declaration shall not specify an alignment that is less strict than the 
alignment that would otherwise be required for the type of the object or member 
being declared."

Which I interpret to mean it can be allowed as an extension.
Sep 28 2021
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Lua, sljit, zlib, xlib don't use it.

Got to page 10 on GH and didn't find anything that used it.

This can probably be tabled until we find a library that needs it.
Sep 28 2021
parent reply jfondren <julian.fondren gmail.com> writes:
On Tuesday, 28 September 2021 at 08:35:57 UTC, rikki cattermole 
wrote:

 Lua, sljit, zlib, xlib don't use it.

 Got to page 10 on GH and didn't find anything that used it.

 This can probably be tabled until we find a library that needs 
 it.


```
$ grep -rl 'pragma pack' /usr/include/|cut -d/ -f4|sort -u
```

botan-2 clang dvdread f2fs_fs.h F3DAudio.h faaccfg.h faac.h 
FACT.h FAPOBase.h FAPOFX.h FAPO.h FAudioFX.h FAudio.h ffi.h 
gssapi krb5 libmodplug libusb-1.0 linux neaacdec.h nspr nss 
OpenEXR p11-kit-1 PCSC pgm-5.3 pkcs11 pkcs11-helper-1.0 qt 
quota.h SDL SDL2 smbios_c sodium unrar wine ykpers-1 zzip

SDL, qt (just one QtQml file, no idea how important it is), 
*lotta* media stuff, libusb, unrar, botan-2, two linux kernel 
headers.
Sep 28 2021
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Tuesday, 28 September 2021 at 09:31:21 UTC, jfondren wrote:

 SDL


SDL's some bizarre "what if someone includes me after a pack(1)?" 
code that could be removed, but others look more legit.
Sep 28 2021
parent reply russhy <russhy gmail.com> writes:
It's quite common to see #pragma pack used in gamedev libraries 
when you need to squeeze every little bit for performance
Sep 28 2021
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 5:45 AM, russhy wrote:

 It's quite common to see #pragma pack used in gamedev libraries when you need
to 
 squeeze every little bit for performance


The point is C11 specifies using _Alignas, and by now all used C compilers 
should support that.
Sep 28 2021
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Out of that list linux and SDL2 probably are the most likely to work 
short term, so yeah that changes things.
Sep 28 2021
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


If it's not too much work I think you might as well implement it 
but an error/warning message must be issued if it is ignored.

__Import__ C must not lie about what it can or cannot do because 
(in the hands of 99% of its users) it is not going to be used as 
a C compiler, but rather a C compiler being deployed to properly 
consume C header files.
Sep 28 2021
prev sibling next sibling parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


I tried ImportC with TCC and warp as preprocessor.
TCC stdlib uses #pragma pack also.
The conundrum with ImportC is that it seems to me you have to 
build with the right cstdlib headers if you intend to use this or 
that backend.
So in the end I managed to convert none of the STB headers 
libraries with ImportC (not only due to pragma pack).
Sep 28 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 5:50 AM, Guillaume Piolat wrote:

 The conundrum with ImportC is that it seems to me you have to build with the 
 right cstdlib headers if you intend to use this or that backend.


Not sure what that means.


 So in the end I managed to convert none of the STB headers libraries with 
 ImportC (not only due to pragma pack).


Please enumerate the issues you found.
Sep 28 2021
parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 17:32:26 UTC, Walter Bright 
wrote:

 On 9/28/2021 5:50 AM, Guillaume Piolat wrote:

 The conundrum with ImportC is that it seems to me you have to 
 build with the right cstdlib headers if you intend to use this 
 or that backend.


 Not sure what that means.


I mean that the ImportC preprocessor needs libc headers, and 
those SHOULD be the same libc that the code will be linked 
against.

1. Suppose you use ImportC right now, using the TinyCC with its 
own cstlib headers, for the purpose of preprocessing C code in 
order to give to ImportC.

The preprocessed C code has the following `dirent` struct:
https://github.com/TinyCC/tinycc/blob/82b0af74501bf46b16bc2a4a9bd54239aa7b7127/win32/include/dirent.h#L25

2. You link with the libc that comes with DMD or LDC, so the 
clang or msvc or Digital Mars one. They contains another `dirent` 
struct definition

3. At runtime, the C stdlib has its own understanding of what is 
the `dirent` struct. A memory corruption ensues right after 
calling readdir() and reading the result.
Sep 28 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 12:52 PM, Guillaume Piolat wrote:

 On Tuesday, 28 September 2021 at 17:32:26 UTC, Walter Bright wrote:

 On 9/28/2021 5:50 AM, Guillaume Piolat wrote:

 The conundrum with ImportC is that it seems to me you have to build with the 
 right cstdlib headers if you intend to use this or that backend.


 Not sure what that means.


 
 I mean that the ImportC preprocessor needs libc headers, and those SHOULD be
the 
 same libc that the code will be linked against.


Just like for any C code, the .h files must match the library binaries.



 1. Suppose you use ImportC right now, using the TinyCC with its own cstlib 
 headers, for the purpose of preprocessing C code in order to give to ImportC.
 
 The preprocessed C code has the following `dirent` struct:
 https://github.com/TinyCC/tinycc/blob/82b0af74501bf46b16bc2a4a9bd54239aa7b7127/win32/
nclude/dirent.h#L25 
 
 
 2. You link with the libc that comes with DMD or LDC, so the clang or msvc or 
 Digital Mars one. They contains another `dirent` struct definition
 
 3. At runtime, the C stdlib has its own understanding of what is the `dirent` 
 struct. A memory corruption ensues right after calling readdir() and reading
the 
 result.


Of course that will fail, just like it will fail if you compile code with 
TinyCC's stdlib and link with clang's stdlib.
Sep 28 2021
parent reply Guillaume Piolat <first.name notexisting.com> writes:
On Tuesday, 28 September 2021 at 23:54:52 UTC, Walter Bright 
wrote:

 Of course that will fail, just like it will fail if you compile 
 code with TinyCC's stdlib and link with clang's stdlib.


I now realize that using D, it was "just working" because of work 
that went into DRuntime to avoid ABI problems:
https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/src/core/sys/posix/dirent.d#L53

So the current state is that: the D compiler works will all 
(supported) C runtime, with a single set of D headers.

This won't be the case in an ImportC future, your build will 
depend on pointing on the right libc include paths (unless there 
is a similar syncretic header set that works with common libc), 
and I just hope the compiler will do it automatically :)
Sep 28 2021
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2021 5:11 PM, Guillaume Piolat wrote:

 This won't be the case in an ImportC future, your build will depend on
pointing 
 on the right libc include paths (unless there is a similar syncretic header
set 
 that works with common libc), and I just hope the compiler will do it 
 automatically :)


I'm afraid that in order for D to save you, you have to write the code in D,
not C!
Sep 28 2021
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


Is there an alternative that could be suggested? For instance, 
throwing an error message but explaining how to use `_Alignas`? 
If not, I'm not sure what choice there is.
Sep 28 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


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%.
Sep 29 2021
parent reply Claude <claudemr live.fr> writes:
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.
Sep 30 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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.
Sep 30 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
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
Sep 30 2021
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Sep 30 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/30/2021 4:54 AM, Guillaume Piolat wrote:

 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


The first two are dealt with by the preprocessor, not the compiler.
Oct 01 2021
prev sibling next sibling parent Kenneth Dallmann <fake 123.con> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?




  I believe I know why you are on the fence about it, and I feel 
the same.
My concept would be simply to make D its own language, the more 
unneccessary  stuff
is added the more complicated and disorienting it can be to users.

My point of view is, so long as the compiler can use C code with 
all its features then
there is no point in making a D version of the features that 
aren't important.

Simplicity is beautiful.

Thank you
Sep 29 2021
prev sibling next sibling parent Kenneth Dallmann <fake 123.con> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


I have to add to my message.

    If D is not a superset of C then there's no need for 
"compatibility".
There are already enough underlying differences in syntax that D 
is not truly
"compatible" with C.  You could make D a typechecked Python with 
little similarities
in syntax and still say it is compatible.

So long as it can be translated to C and that it can build symbol 
tables of C, for
typing, then it would still have all the same usability as 
"betterC".
Sep 29 2021
prev sibling next sibling parent Kenneth Dallmann <fake 123.con> writes:
I think the issue that happened with C++ was that it was made a 
superset and then
they just kept adding features, shortcuts, whatnot. The syntax 
can be very confusing, there are redundant syntax constructs, 
shortcuts, and structurally it doesn't look organized.
Sep 29 2021
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/28/21 2:05 AM, Walter Bright wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315
 
 I'm on the fence about implementing this. On the one hand, I can do it 
 and make it work. On the other hand, the C11 way is to use _Alignas, and 
 that's 10 years old now. How far do we go with implementing all the 
 nutburger obsolete C extension cruft out there?


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.

-Steve
Sep 29 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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).
Sep 29 2021
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Sep 30 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
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.
Sep 30 2021
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 30 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 30 September 2021 at 11:52:37 UTC, Dukc wrote:

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

 [...]


 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.


I agree, should be an error
Oct 01 2021
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/dlang/dmd/pull/13112
Oct 01 2021
next sibling parent bauss <jj_1337 live.dk> writes:
On Friday, 1 October 2021 at 08:23:43 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13112


Thank you Walter :)
Oct 01 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 1 October 2021 at 08:23:43 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/13112


👍
Oct 01 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 28 September 2021 at 06:05:04 UTC, Walter Bright 
wrote:

 https://issues.dlang.org/show_bug.cgi?id=22315

 I'm on the fence about implementing this. On the one hand, I 
 can do it and make it work. On the other hand, the C11 way is 
 to use _Alignas, and that's 10 years old now. How far do we go 
 with implementing all the nutburger obsolete C extension cruft 
 out there?


FYI, just asked two of the "old guys" at my workplace and they 
said there where a few places pragma pack was used in our codebase
Oct 04 2021