On Thursday, 11 November 2021 at 02:32:21 UTC, Walter Bright wrote:

I have no problem with the lack of support for extensions. The problems are:

• The error messages tell you nothing. The only solution is to go through the entire (large) preprocessed C file and identify every problem, with no help from the compiler. The error message that caused me to file the bug was illegal combination of type specifiers. After more than an hour of working on it, I had finally commented out enough lines to make the error messages go away.
• It's not obvious to someone lacking a strong understanding of C compilers how to make the correct adjustments to the code. For instance, what am I supposed to do with _Float128 to get something that runs and is guaranteed to no change the behavior of the code? I've never written a line of C code that used a compiler extension in my life. It would require a major investment on my part.

On Thursday, 11 November 2021 at 16:58:24 UTC, bachmeier wrote:

And to elaborate further on the second point, I went through all of the items listed on this page last night to assess the size of the problem. I couldn't even understand what some of them were saying. It would really help if the compiler would automatically add lines like #define __restrict restrict.

On Thursday, 11 November 2021 at 17:06:15 UTC, bachmeier wrote:

I think you only can do that with names that start with two "__", because of #ifndef.

It is kinda tricky as C code bases contains a lot of #ifdef based on target compiler, so you have to choose one. I guess GCC is a safe bet.

On Thursday, 11 November 2021 at 17:21:16 UTC, Ola Fosheim Grøstad wrote:

Isn't #ifndef handled by the preprocessor? The __restrict problem I encountered is in the context of restricted pointers *__restrict that remained after preprocessing the file.

On Thursday, 11 November 2021 at 17:37:37 UTC, bachmeier wrote:

Yes, everything with a #-prefix is related to the preprocessor. So you would not want the compiler to add #define, but instead handle __keyword based on the emulated compiler target. But _Float128 cannot be dealt with this way since you want errors to reported…

On Thursday, 11 November 2021 at 18:26:43 UTC, Ola Fosheim Grøstad wrote:

My earlier thought was that DMD could add those statements to the C file, call the preprocessor, and then do the compilation. But even if there's a desire to avoid involvement with the preprocessor call, DMD could still change *__restrict to *restrict and some of the other fixes. It's already identifying those parts of the code so it can ignore them.

On Thursday, 11 November 2021 at 22:07:22 UTC, bachmeier wrote:

Yes, it can do that since the "__" prefix is reserved. But it is tricky with "_" prefixes as users can use those. Some symbols are standard library/compiler-dependent and may vary between hardware targets for the same compiler even?

I think you basically have to choose which specific compiler you want to emulate if you want a plug&play experience?

Many codebases are written for a specific combination of GCC, Clang, XCode-Clang, Intel, Microsoft and will fail on all other compilers. #ifdef and #ifndef are used to tailor the declarations/definitions to each compiler.

I am just saying that it might be difficult to get the easy C-interfacing you hope for, unless you pick one specific compiler and emulate it well. GCC is probably the best option, but then you have to pose as GCC to trigger the correct #ifdef. But GCC has a lot of extensions! Emulating GCC is a difficult challenge and emulating all compilers is unrealistic.

So, plug&play is not very realistic.