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

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

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

#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));
}

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)

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.

On Tuesday, 9 November 2021 at 17:14:52 UTC, Tejas 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.

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

I agree that the error messages suck.

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.

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

I agree that the error messages suck.

The restrict type-qualifier (C11 6.7.3) is ignored

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

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

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

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