Is importC ready?
bachmeier
no at spam.net
Tue Nov 9 19:18:36 UTC 2021
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.
More information about the Digitalmars-d
mailing list