Is importC ready? (page 4)

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!

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

November 18, 2021

Re: [Solved] Re: Is importC ready?

Posted by bachmeier
in reply to bachmeier

Permalink

bachmeier

Posted in reply to bachmeier

Permalink

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

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

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.

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.

Forums