So I'm trying to compile the toml99 C library with DMD using ImportC. I first preprocessed the file using cproc. The reason I didn't used GCC is because it defines some symbols specific to GCC so it will furthermore mess the compilation process. I created a gist of the file and uploaded here in case someone wants to get the file and try it. The error message I'm getting is the following:

toml.c(39): Error: cannot implicitly convert expression `malloc` of type `extern (C) void*(ulong __size)` to `extern (C) void* function(ulong)`
toml.c(40): Error: cannot implicitly convert expression `free` of type `extern (C) void(void* __ptr)` to `extern (C) void function(void*)`

These two symbols are function pointers but I wasn't able to modify and make it work. Any ideas?

On 11/9/21 6:45 AM, rempas wrote:

toml.c(39): Error: cannot implicitly convert expression `malloc` of type `extern (C) void*(ulong __size)` to `extern (C) void* function(ulong)`
toml.c(40): Error: cannot implicitly convert expression `free` of type `extern (C) void(void* __ptr)` to `extern (C) void function(void*)`

It seems like it should work. Figuring out the "lines" for things is really difficult in this expanded format, even though I know why it does that. I think importC should possibly allow printing of the actual source line along with the explicit source file/line, because knowing the vagrancies of the preprocessor is not going to be something that's easy to deal with, and you want to see what raw format is being passed to the compiler.

here is where "line 39" of toml.c is.
here is where the definition of malloc is.

To me, this looks reasonable. I narrowed it down to the following file, and it builds with gcc and ldc2 on my system. I don't have support for DMD, as this is an Arm system, but on another system, I can confirm that DMD 2.098.0 does not compile this:

typedef long unsigned int size_t;
extern void *malloc (size_t __size)
     ;
static void* (*ppmalloc)(size_t) = malloc;

I used dmd -c testc.c, gcc -c testc.c and ldc2 -c testc.c.

Please file a bug report.

https://issues.dlang.org

-Steve

On Tuesday, 9 November 2021 at 11:45:28 UTC, rempas wrote:

toml.c(39): Error: cannot implicitly convert expression `malloc` of type `extern (C) void*(ulong __size)` to `extern (C) void* function(ulong)`
toml.c(40): Error: cannot implicitly convert expression `free` of type `extern (C) void(void* __ptr)` to `extern (C) void function(void*)`

What's happening here is that dmd seems to see free as function rather than a pointer to a function.
changing static void* (*ppmalloc)(size_t) = malloc;
to static void* (*ppmalloc)(size_t) = &malloc;

may solve your issue.

On 11/9/21 2:34 PM, Stefan Koch wrote:

toml.c(39): Error: cannot implicitly convert expression `malloc` of type `extern (C) void*(ulong __size)` to `extern (C) void* function(ulong)`
toml.c(40): Error: cannot implicitly convert expression `free` of type `extern (C) void(void* __ptr)` to `extern (C) void function(void*)`

No, the original is valid C, you don't need the address operator.

It's telling that in ldc2 1.28.0, with the new importC feature, it builds fine.

It also builds fine with gcc.

-Steve

On Tuesday, 9 November 2021 at 19:53:48 UTC, Steven Schveighoffer wrote:

Yes it is valid C.
It is not valid D though.

On 11/9/21 3:05 PM, Stefan Koch wrote:

The file is named tomld.c

The way importC works is, you pass a .c file to the compiler, and it treats it as C.

-Steve

On Tuesday, 9 November 2021 at 21:03:20 UTC, Steven Schveighoffer wrote:

It rather tries to interpret the C code as D code.
It's not a full C compiler rather it's a shim in front of the D frontend.
Therefore bugs like the above can happen if the compiler wasn't aware that the function identifier was to be interpreted in "C context"

On 11/9/21 5:19 PM, Stefan Koch wrote:

I'm not sure where this conversation is going. ImportC is supposed to compile C files. Any case where it doesn't compile C files (at least standards-conforming ones) is a bug.

-Steve

On Tuesday, 9 November 2021 at 19:34:44 UTC, Stefan Koch wrote:

Thanks for the answer but this seems to create even more bugs

On Tuesday, 9 November 2021 at 22:19:37 UTC, Stefan Koch wrote:

I also think that Stefan is right here. If we check the spec page for ImportC, in the 2nd note, first sentence, it says: "ImportC is a C compiler embedded into the D implementation". To me that seems that it is a full C compiler that treats the syntax as C and creates files that can be linked with D.