www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is importC ready?

reply bachmeier <no spam.net> writes:
I tried to compile a simple C file this morning, containing

```
#include "nmath.h"

double fsign(double x, double y)
{
#ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
	return x + y;
#endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
}
```

I assumed this would be straightforward since it doesn't have a 
bunch of dependencies and it's only a few lines of code. Instead, 
I got a stream of errors. After running the file through the 
preprocessor, I had to comment out anything with

-  `__extension__`
- Restricted pointers `*__restrict`
- `_Float128`
- `__asm__`

And in the source, anything with ISNAN, or in the preprocessed 
file,

- `__builtin_isnan`

I [filed a bug](https://issues.dlang.org/show_bug.cgi?id=22496). 
After this experience, it's not obvious to me that importC is 
ready to be part of a stable compiler release. Maybe I just had 
bad luck with the choice of file.
Nov 09 2021
next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have a 
 bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


It looks like that file uses a lot of compiler extensions

https://dlang.org/spec/importc.html#limitations

ImportC only compiles standard C11 and nothing more

(Although that noreturn part might need updating since we have 
that now, i think)
Nov 09 2021
parent reply bachmeier <no spam.net> writes:
On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have 
 a bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


 It looks like that file uses a lot of compiler extensions

 https://dlang.org/spec/importc.html#limitations

 ImportC only compiles standard C11 and nothing more

 (Although that noreturn part might need updating since we have 
 that now, i think)


It doesn't seem practical to ignore compiler extensions and leave 
them to the user to debug and fix. My understanding is that you 
can convert restricted pointers `*__restrict` to a simple `*` - 
the compiler should recognize that and make the change for you. 
At a minimum, the compiler knows when it's encountering 
extensions and can spit out a message telling you what's going 
on. The current messages are pretty awful.
Nov 09 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas wrote:

 [...]


 It doesn't seem practical to ignore compiler extensions and 
 leave them to the user to debug and fix. My understanding is 
 that you can convert restricted pointers `*__restrict` to a 
 simple `*` - the compiler should recognize that and make the 
 change for you. At a minimum, the compiler knows when it's 
 encountering extensions and can spit out a message telling you 
 what's going on. The current messages are pretty awful.


Imo we should try to fix that. Let's hope Walter agrees 🍀
Nov 09 2021
prev sibling parent reply Dave P. <dave287091 gmail.com> writes:
On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing
 [...]




 It doesn't seem practical to ignore compiler extensions and 
 leave them to the user to debug and fix. My understanding is 
 that you can convert restricted pointers `*__restrict` to a 
 simple `*` - the compiler should recognize that and make the 
 change for you. At a minimum, the compiler knows when it's 
 encountering extensions and can spit out a message telling you 
 what's going on. The current messages are pretty awful.


ImportC understands `restrict`, it just doesn’t understand 
non-standard keywords. See 
[this](https://dlang.org/spec/importc.html#wrapping).

That example is incomplete, but you can  `#define __restrict 
restrict`, `#define __asm__ asm`, etc.

I agree that the error messages suck.
Nov 09 2021
next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 9 November 2021 at 19:04:04 UTC, Dave P. wrote:

 On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing
 [...]




 It doesn't seem practical to ignore compiler extensions and 
 leave them to the user to debug and fix. My understanding is 
 that you can convert restricted pointers `*__restrict` to a 
 simple `*` - the compiler should recognize that and make the 
 change for you. At a minimum, the compiler knows when it's 
 encountering extensions and can spit out a message telling you 
 what's going on. The current messages are pretty awful.


 ImportC understands `restrict`, it just doesn’t understand 
 non-standard keywords. See 
 [this](https://dlang.org/spec/importc.html#wrapping).

 That example is incomplete, but you can  `#define __restrict 
 restrict`, `#define __asm__ asm`, etc.

 I agree that the error messages suck.


Yeah, I saw that example, but the main limitation of such a 
strategy is that I don't have the knowledge to construct a file 
that without potentially changing behavior. I made some changes 
by hand and confirmed that changing `*__restrict` to `*restrict`, 
`__asm__` to `asm`, and `buitin_isnan` to `isnan` results in a 
file that compiles. That still leaves `_Float128`. This all 
requires a lot of C compiler knowledge that shouldn't be required 
of a D programmer.
Nov 09 2021
prev sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 9 November 2021 at 19:04:04 UTC, Dave P. wrote:

 On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:

 [...]


 ImportC understands `restrict`, it just doesn’t understand 
 non-standard keywords. See 
 [this](https://dlang.org/spec/importc.html#wrapping).

 That example is incomplete, but you can  `#define __restrict 
 restrict`, `#define __asm__ asm`, etc.

 I agree that the error messages suck.


https://dlang.org/spec/importc.html#restrict


 The restrict type-qualifier (C11 6.7.3) is ignored
Nov 10 2021
next sibling parent Dave P. <dave287091 gmail.com> writes:
On Wednesday, 10 November 2021 at 15:42:52 UTC, WebFreak001 wrote:

 On Tuesday, 9 November 2021 at 19:04:04 UTC, Dave P. wrote:

 On Tuesday, 9 November 2021 at 18:45:04 UTC, bachmeier wrote:

 [...]


 ImportC understands `restrict`, it just doesn’t understand 
 non-standard keywords. See 
 [this](https://dlang.org/spec/importc.html#wrapping).

 That example is incomplete, but you can  `#define __restrict 
 restrict`, `#define __asm__ asm`, etc.

 I agree that the error messages suck.


 https://dlang.org/spec/importc.html#restrict


 The restrict type-qualifier (C11 6.7.3) is ignored




That is a conformant implementation of restrict. Restrict is just 
an optimization hint.


 The intended use of the restrict qualifier (like the register 
 storage class) is to promote optimization, and deleting all 
 instances of the qualifier from all preprocessing translation 
 units composing a conforming program does not change its 
 meaning (i.e., observable behavior).


By “understand” I mean it recognizes it as a keyword and that it 
is a type qualifier.
Nov 10 2021
prev sibling parent bachmeier <no spam.net> writes:
On Wednesday, 10 November 2021 at 15:42:52 UTC, WebFreak001 wrote:


 https://dlang.org/spec/importc.html#restrict


 The restrict type-qualifier (C11 6.7.3) is ignored




And it should be added to that page that you'll get strange error 
messages like `Error: illegal combination of type specifiers` 
when you try to compile C code with `*__restrict` buried in line 
874. Wouldn't be difficult to print a warning saying `restrict` 
was ignored and which line.
Nov 10 2021
prev sibling next sibling parent Dave P. <dave287091 gmail.com> writes:
On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have a 
 bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


It can parse simple C files, but IMO is not ready yet. There are 
still a number of outstanding 
[bugs](https://issues.dlang.org/buglist.cgi?quicksearch=importc) 
that should be resolved before declaring it “ready”.
Nov 09 2021
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2021 8:41 AM, bachmeier wrote:

 I tried to compile a simple C file this morning, containing


The things that tripped are C extensions, not C11. Especially the errors about 
`__extension__` :-/

Anyhow, `restrict` works. You can do things like:

   #define __restrict restrict

or even:

   #define __restrict

before the #include. (ImportC just ignores the `restrict` keyword, which is 
Standard compliant behavior.)

Over time, we'll probably add support for extensions. But for the moment, it's 
for C11 code.
Nov 10 2021
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 11 November 2021 at 02:32:21 UTC, Walter Bright 
wrote:

 Over time, we'll probably add support for extensions. But for 
 the moment, it's for C11 code.


Promising to hear. The less friction possible the better IMO.
Nov 10 2021
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 11 November 2021 at 02:32:21 UTC, Walter Bright 
wrote:

 On 11/9/2021 8:41 AM, bachmeier wrote:

 I tried to compile a simple C file this morning, containing


 The things that tripped are C extensions, not C11. Especially 
 the errors about `__extension__` :-/

 Anyhow, `restrict` works. You can do things like:

   #define __restrict restrict

 or even:

   #define __restrict

 before the #include. (ImportC just ignores the `restrict` 
 keyword, which is Standard compliant behavior.)

 Over time, we'll probably add support for extensions. But for 
 the moment, it's for C11 code.


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.
Nov 11 2021
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 11 November 2021 at 16:58:24 UTC, bachmeier wrote:

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

 On 11/9/2021 8:41 AM, bachmeier wrote:

 I tried to compile a simple C file this morning, containing


 The things that tripped are C extensions, not C11. Especially 
 the errors about `__extension__` :-/

 Anyhow, `restrict` works. You can do things like:

   #define __restrict restrict

 or even:

   #define __restrict

 before the #include. (ImportC just ignores the `restrict` 
 keyword, which is Standard compliant behavior.)

 Over time, we'll probably add support for extensions. But for 
 the moment, it's for C11 code.


 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.


And to elaborate further on the second point, I went through all 
of the items [listed on this 
page](https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html) 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`.
Nov 11 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 11 November 2021 at 17:06:15 UTC, bachmeier wrote:

 understand what some of them were saying. It would really help 
 if the compiler would automatically add lines like `#define 
 __restrict restrict`.


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.
Nov 11 2021
parent reply bachmeier <no spam.net> writes:
On Thursday, 11 November 2021 at 17:21:16 UTC, Ola Fosheim 
Grøstad wrote:

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

 understand what some of them were saying. It would really help 
 if the compiler would automatically add lines like `#define 
 __restrict restrict`.


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


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.
Nov 11 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 11 November 2021 at 17:37:37 UTC, bachmeier 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.



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…
Nov 11 2021
parent reply bachmeier <no spam.net> writes:
On Thursday, 11 November 2021 at 18:26:43 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 11 November 2021 at 17:37:37 UTC, bachmeier 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.



 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…


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.
Nov 11 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 11 November 2021 at 22:07:22 UTC, bachmeier wrote:

 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.


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.
Nov 11 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2021 9:06 AM, bachmeier wrote:

 It would really help if the compiler would automatically add 
 lines like `#define __restrict restrict`.


Iain and I discussed that a few months ago. The original plan was to make them 
keywords. But there's a blizzard of them, and it's a different list for every 
compiler.

We eventually decided it might be simpler to have the compiler automatically 
apply a set of its own #defines, like you say, but that will only work if the 
compiler itself is executing the preprocessor.
Nov 11 2021
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2021 8:58 AM, bachmeier wrote:

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


Was the file/line number given for the error incorrect?

I agree, though, that the error messages are inadequate. This first iteration
of 
ImportC has a priority of getting correct code to compile correctly. Error 
messages are admittedly mostly placeholders. The important thing is the 
file/line being correct.


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


I don't know what _Float128 is, either (though I can guess). So I turn to
Google:

https://www.google.com/search?q=C+_Float128

And the first hit is:

https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html

Most of the C headers are declarations. If you just comment out the offending 
declarations, the code will likely compile just fine, since you likely wouldn't 
be using _Float128 unless you knew what it was.
Nov 11 2021
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/11/21 10:29 PM, Walter Bright wrote:

 On 11/11/2021 8:58 AM, bachmeier wrote:

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


 
 Was the file/line number given for the error incorrect?


While you are thinking about this, one thing I brought up in [another 
thread](https://forum.dlang.org/post/smdtv6$1rjc$1 digitalmars.com), is 
that the preprocessor automatically adds file/line information to the 
preprocessed file. That is important so you can trace the error back to 
the original file.

But for this purpose, you do have a preprocessed file, which may have 
code that either ImportC cannot deal with or where the preprocessed file 
seemingly has been badly formed. Having to find the real line to 
diagnose in the real file is not that easy when the error messages are 
all based on the file/line rewrite tokens.

It would be nice for the compiler to at least have an option to show 
"true" file/line numbers. Maybe a directive to ignore all file/line 
rewrite tokens.

-Steve
Nov 11 2021
next sibling parent reply Dave P. <dave287091 gmail.com> writes:
On Friday, 12 November 2021 at 04:13:44 UTC, Steven Schveighoffer 
wrote:

 On 11/11/21 10:29 PM, Walter Bright wrote:

 On 11/11/2021 8:58 AM, bachmeier wrote:

 [...]


 
 Was the file/line number given for the error incorrect?


 While you are thinking about this, one thing I brought up in 
 [another 
 thread](https://forum.dlang.org/post/smdtv6$1rjc$1 digitalmars.com), is that
the preprocessor automatically adds file/line information to the preprocessed
file. That is important so you can trace the error back to the original file.

 But for this purpose, you do have a preprocessed file, which 
 may have code that either ImportC cannot deal with or where the 
 preprocessed file seemingly has been badly formed. Having to 
 find the real line to diagnose in the real file is not that 
 easy when the error messages are all based on the file/line 
 rewrite tokens.

 It would be nice for the compiler to at least have an option to 
 show "true" file/line numbers. Maybe a directive to ignore all 
 file/line rewrite tokens.

 -Steve


Invoke gcc (or clang) with the `-P` flag. It will disable 
linemarker output, which means you’ll get error messages 
corresponding to the preprocessed line instead of the original 
line.
Nov 11 2021
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/12/21 12:54 AM, Dave P. wrote:


 
 Invoke gcc (or clang) with the `-P` flag. It will disable linemarker 
 output, which means you’ll get error messages corresponding to the 
 preprocessed line instead of the original line.


Oh yeah, that's a much better solution, thanks!

-Steve
Nov 12 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2021 8:13 PM, Steven Schveighoffer wrote:

 While you are thinking about this, one thing I brought up in [another 
 thread](https://forum.dlang.org/post/smdtv6$1rjc$1 digitalmars.com), is that
the 
 preprocessor automatically adds file/line information to the preprocessed
file. 
 That is important so you can trace the error back to the original file.
 
 But for this purpose, you do have a preprocessed file, which may have code
that 
 either ImportC cannot deal with or where the preprocessed file seemingly has 
 been badly formed. Having to find the real line to diagnose in the real file
is 
 not that easy when the error messages are all based on the file/line rewrite 
 tokens.
 
 It would be nice for the compiler to at least have an option to show "true" 
 file/line numbers. Maybe a directive to ignore all file/line rewrite tokens.


If you really need it, running a script to delete the file/line directives
would 
do it.
Nov 12 2021
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 12 November 2021 at 03:29:07 UTC, Walter Bright wrote:

 On 11/11/2021 8:58 AM, bachmeier wrote:

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


 Was the file/line number given for the error incorrect?

 I agree, though, that the error messages are inadequate. This 
 first iteration of ImportC has a priority of getting correct 
 code to compile correctly. Error messages are admittedly mostly 
 placeholders. The important thing is the file/line being 
 correct.


The error messages are of this form:

```
/usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: 
illegal combination of type specifiers
/usr/include/string.h(43): Error: found `__dest` when expecting 
`,`
```

I was only able to identify the offending lines by repeatedly 
commenting and uncommenting code.
Nov 12 2021
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven just posted a solution in this thread.
Nov 15 2021
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/16/21 1:08 AM, Walter Bright wrote:

 Steven just posted a solution in this thread.


It was Dave P, not me!

-Steve
Nov 16 2021
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2021 6:43 AM, Steven Schveighoffer wrote:

 On 11/16/21 1:08 AM, Walter Bright wrote:

 Steven just posted a solution in this thread.


 
 It was Dave P, not me!
 
 -Steve


Sorry, Dave P, my mistake!
Nov 16 2021
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have a 
 bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


There's a solution for this. Buried in a recent post on This Week 
in D, there's [a link to a list of 
fixes](https://raw.githubusercontent.com/ibuclaw/importC/main
src/keywords.c.in). That plus `#define __builtin_isnan isnan` allows my C file
and many others to compile with LDC. Some files that compile with LDC do not
compile with DMD. I'm still having trouble with `__builtin_isfinite` errors. I
thought `#define __builtin_isfinite isfinite` would work, but it doesn't.

Once I understand this better, I will update the issue I created.
Nov 15 2021
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 15 November 2021 at 21:29:53 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have 
 a bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


 There's a solution for this. Buried in a recent post on This 
 Week in D, there's [a link to a list of 
 fixes](https://raw.githubusercontent.com/ibuclaw/importC/main
src/keywords.c.in). That plus `#define __builtin_isnan isnan` allows my C file
and many others to compile with LDC. Some files that compile with LDC do not
compile with DMD. I'm still having trouble with `__builtin_isfinite` errors. I
thought `#define __builtin_isfinite isfinite` would work, but it doesn't.

 Once I understand this better, I will update the issue I 
 created.


Giving up on this experiment. It's just not worth the time. 
Better to go back to wrapping C libraries like I've been doing 
for years. Nobody writes standard C.
Nov 17 2021
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2021 8:23 PM, bachmeier wrote:

 Giving up on this experiment. It's just not worth the time. Better to go back
to 
 wrapping C libraries like I've been doing for years. Nobody writes standard C.


If you're skilled enough in C to wrap the C headers manually, you're still
going 
to be far better off using ImportC, because you'll only have to wrap the
extensions.
Nov 19 2021
prev sibling parent reply bachmeier <no spam.net> writes:
On Monday, 15 November 2021 at 21:29:53 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 I tried to compile a simple C file this morning, containing

 ```
 #include "nmath.h"

 double fsign(double x, double y)
 {
 #ifdef IEEE_754
     if (ISNAN(x) || ISNAN(y))
 	return x + y;
 #endif
     return ((y >= 0) ? fabs(x) : -fabs(x));
 }
 ```

 I assumed this would be straightforward since it doesn't have 
 a bunch of dependencies and it's only a few lines of code. 
 Instead, I got a stream of errors. After running the file 
 through the preprocessor, I had to comment out anything with

 -  `__extension__`
 - Restricted pointers `*__restrict`
 - `_Float128`
 - `__asm__`

 And in the source, anything with ISNAN, or in the preprocessed 
 file,

 - `__builtin_isnan`

 I [filed a 
 bug](https://issues.dlang.org/show_bug.cgi?id=22496). After 
 this experience, it's not obvious to me that importC is ready 
 to be part of a stable compiler release. Maybe I just had bad 
 luck with the choice of file.


 There's a solution for this. Buried in a recent post on This 
 Week in D, there's [a link to a list of 
 fixes](https://raw.githubusercontent.com/ibuclaw/importC/main
src/keywords.c.in). That plus `#define __builtin_isnan isnan` allows my C file
and many others to compile with LDC. Some files that compile with LDC do not
compile with DMD. I'm still having trouble with `__builtin_isfinite` errors. I
thought `#define __builtin_isfinite isfinite` would work, but it doesn't.

 Once I understand this better, I will update the issue I 
 created.


Giving up on this experiment. It's much easier/faster to wrap 
what I need and forget about the rest. Solve one problem and you 
get three new compiler error messages. Eventually I run into 
something I can't fix, so I move on to a new file, and it's the 
same thing. It's hopeless without a complete implementation or 
workaround for all of the GCC compiler extensions. I honestly 
have no idea why they pretend C is standardized.
Nov 17 2021
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 18 November 2021 at 04:38:36 UTC, bachmeier wrote:

 On Monday, 15 November 2021 at 21:29:53 UTC, bachmeier wrote:

 On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

 [...]


 There's a solution for this. Buried in a recent post on This 
 Week in D, there's [a link to a list of 
 fixes](https://raw.githubusercontent.com/ibuclaw/importC/main
src/keywords.c.in). That plus `#define __builtin_isnan isnan` allows my C file
and many others to compile with LDC. Some files that compile with LDC do not
compile with DMD. I'm still having trouble with `__builtin_isfinite` errors. I
thought `#define __builtin_isfinite isfinite` would work, but it doesn't.

 Once I understand this better, I will update the issue I 
 created.


 Giving up on this experiment. It's much easier/faster to wrap 
 what I need and forget about the rest. Solve one problem and 
 you get three new compiler error messages. Eventually I run 
 into something I can't fix, so I move on to a new file, and 
 it's the same thing. It's hopeless without a complete 
 implementation or workaround for all of the GCC compiler 
 extensions. I honestly have no idea why they pretend C is 
 standardized.


Because the real truth is that with pure ISO C, there are plenty 
of stuff that would only be possible with Assembly, and place C 
at the same spot as other high level languages, and we cannot 
damage C's reputation as the systems programming language, now 
can we?
Nov 17 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 04:38:36 UTC, bachmeier wrote:

 extensions. I honestly have no idea why they pretend C is 
 standardized.


The baseline is standardized, but in C there is a long tradition 
for writing code for specific system targets and compilers. So, 
by convention you try to keep system specific and compiler 
specific stuff in a small set of files and macros. Then you can 
port to another system/compiler by rewriting that small set of 
files and macros.

System level codebases are generally not portable, only 
"portable", which is what makes it system level. :-)

Why is this acceptable? Well, adapting to a new C compiler is 
less work than adapting the system specific parts to a new 
system, so it does not matter much.
Nov 18 2021
prev sibling parent surlymoor <surlymoor cock.li> writes:
Has anybody tried building a project using ImportC with dub?
Nov 15 2021