On Wednesday, 10 November 2021 at 06:38:58 UTC, rempas wrote:

*I also think that "STEVEN" is right. Sorry, mistakes happen...

On Tuesday, 9 November 2021 at 13:44:04 UTC, Steven Schveighoffer wrote:

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

It works with LDC2 for you? I'm having the latest version (ldc 1.28.0) downloaded from the release 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?

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?

When preprocessing with GCC, both DMD and LDC give the same error message and it the same I've got from another time I tried to use ImportC and it is here. Clang has the same behavior as well.

When preprocessing with TCC, again both of them have the same error message and it's the following:

/usr/include/stdio.h(407): Error: missing comma
/usr/include/stdio.h(407): Error: `=`, `;` or `,` expected
/usr/include/stdio.h(410): Error: missing comma
/usr/include/stdio.h(410): Error: `=`, `;` or `,` expected
/usr/include/stdio.h(412): Error: missing comma
/usr/include/stdio.h(412): Error: `=`, `;` or `,` expected
/usr/include/stdio.h(451): Error: missing comma
/usr/include/stdio.h(451): Error: `=`, `;` or `,` expected
/usr/include/stdio.h(456): Error: missing comma
/usr/include/stdio.h(456): Error: `=`, `;` or `,` expected
/usr/include/stdio.h(459): Error: missing comma
/usr/include/stdio.h(459): Error: `=`, `;` or `,` expected
/usr/include/string.h(410): Error: missing comma
/usr/include/string.h(410): Error: `=`, `;` or `,` expected

I haven't tried to preprocess with any other compilers but I don't expect anything else to work if these didn't...

On 11/10/21 2:04 AM, rempas wrote:

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

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

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

On 11/10/21 1:31 AM, rempas wrote:

It shouldn't.

Perhaps you mean that you get more errors if you fix that situation? A compiler typically has phases where it can error out. This means that it might not get to further errors (or further errors are happening because of prior errors). It doesn't mean the later errors aren't there, it's just that the compiler gives up before finding them.

-Steve

On Wednesday, 10 November 2021 at 15:06:26 UTC, Steven Schveighoffer wrote:

Yes, this is exactly what I mean!

On Wednesday, 10 November 2021 at 15:04:35 UTC, Steven Schveighoffer wrote:

How? What's the difference in your example? How you preprocessed and compiled?

I did! I personally believe that ImportC is the last and only chance for D. More and more people seem to abandon D libraries so more people leave and less people are coming because of that. At the same time because there are not a lot of people, there are not a lot of libraries and more get abandoned. It's actually a cycle. ImportC can be a true game changer!!!

On Wednesday, 10 November 2021 at 17:38:12 UTC, rempas wrote:

Agreed. But, it must be quite seamless. But if we could get there, yes 🌟

On Wednesday, 10 November 2021 at 17:57:50 UTC, Imperatorn wrote:

It should be able to compile medium to big libraries. Nobody excepts it to be able to compile GIMP but it should be a able to tomlc99 which is a little bit more than 2k lines of code

On 11/10/21 12:38 PM, rempas wrote:

I did none of that. My example is the lines you had problems with, and only enough to make that error show up. It's just those 3 lines.

I don't think ImportC is that much of a game changer (you can already make C bindings with quite a small effort, and there are tools to get you 90% there), but a broken/not working ImportC will be a huge drawback to the language, so it's important to get it right.

-Steve

On Thursday, 11 November 2021 at 02:03:22 UTC, Steven Schveighoffer wrote:

Actually you are right, there are ways to do that but having a FULLY working C compiler that will be able to do ALL the work for you will be awesome! But maybe yeah you are right, it will probably not be a game changer