Cannot compile C file using ImportC

[Steven Schveighoffer]

On 11/10/21 2:04 AM, rempas wrote:
> On Tuesday, 9 November 2021 at 13:44:04 UTC, Steven Schveighoffer wrote:
>>
>> 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](https://gist.github.com/rempas/a1633ba4d3fd4f166277d7ff35cedc63#file-tomld-c-L1439) 
>> is where "line 39" of toml.c is.
>> [here](https://gist.github.com/rempas/a1633ba4d3fd4f166277d7ff35cedc63#file-tomld-c-L763) 
>> 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:
>>
>> ```c
>> 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
> 
> It works with LDC2 for you? I'm having the latest version (ldc 1.28.0) 
> downloaded from the 
> [release](https://github.com/ldc-developers/ldc/releases/tag/v1.28.0) 
> page for Linux (X86_64) and it doesn't seem to work for me. These 2 
> errors are not present with LDC2 however, I'm now getting some other 
> errors with LDC2. How was your LDC2 built?

I'm using the downloaded LDC2 for aarch64.

But I'm not building tomld.c that you created, I'm building the reduced 
example (that I posted).

> Also it is worth noting that the compiler that is used to preprocess the 
> file will result in different error messages when trying to use ImportC. 
> For example when using cproc to preprocess and then LDC2 to compile, the 
> error message is the following:
> 
> ```
> toml.c(638): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> toml.c(671): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> toml.c(1027): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> toml.c(1140): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> toml.c(1844): Error: cannot implicitly convert expression `*((*tab).arr 
> + cast(long)i * 8L)` of type `const(toml_array_t*)` to `toml_array_t*`
> toml.c(1855): Error: cannot implicitly convert expression `*((*tab).tab 
> + cast(long)i * 8L)` of type `const(toml_table_t*)` to `toml_table_t*`
> toml.c(1914): Error: cannot implicitly convert expression `0 <= idx && 
> (idx < (*arr).nitem) ? (*((*arr).item + cast(long)idx * 32L)).arr : 
> cast(const(toml_array_t*))0LU` of type `const(toml_array_t*)` to 
> `toml_array_t*`
> toml.c(1919): Error: cannot implicitly convert expression `0 <= idx && 
> (idx < (*arr).nitem) ? (*((*arr).item + cast(long)idx * 32L)).tab : 
> cast(const(toml_table_t*))0LU` of type `const(toml_table_t*)` to 
> `toml_table_t*`
> toml.c(2247): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> toml.c(2305): Error: assignment cannot be used as a condition, perhaps 
> `==` was meant?
> ```

That is an interesting situation -- you have D errors being applied to C 
code. I think those should be disabled, otherwise, you will have to 
change all your C code, and it's more like portC than importC.

I'd suggest filing all these as issues. If importC is to be successful 
it has to build existing C projects.

-Steve