Why this code doesn't work while it should be (or at least that's what I believe)?

[rempas]

Hi again! I've read the spec for the attributes to try calling functions from external libraries and tied to make an example for "printf" but It seems I'm doing something wrong. I'm trying the following code:

enum i32 stdout = 1;
enum i32 stderr = 2;

@extern(syscall, 60)
noreturn exit(i32 error_code);

@extern(module, "libc")
i32 printf(const u8* format, ... );

i32 print(const u8[] format, ...) {
  return printf(format.ptr, )
}

void main() {
  exit(0);
}

When trying to compile, I'm getting the following error code: test.vx:7:9: Error: Expected `IDENTIFIER` after @extern(, while got `MODULE_SYM` token 'module'

In extend, I also know that the way I'm using variadic arguments is not right but I wasn't able to find anything in the spec so can you also help with that?

P.S. The error message is being displayed in the STDOUT and not in STDERR, I don't know if you choose to do that or if you didn't noticed it.

[MrSmith33]

1. the whole attribute section is WIP (except extern(syscalll))
2. Best place to find working examples is in test suite and existing code. See source/tests/passing.d
3. Should all messages be in stderr?

[MrSmith33]

1. Only one attribute is implemented atm - @extern(syscall) and you can only attach it directly to the definition.
2. I guess the only time it matters where you output the text to, is when you mix different kinds of information (like data and errors) and caller wants to have only one of them.

[rempas]

Only one attribute is implemented atm - @extern(syscall) and you can only attach it directly to the definition.

Oh, I see! Btw, this will fully support calling C functions from external libraries (.so/.dll) right? If yes then does this mean that you won't implement object files (remember the previous conversation we had)?

I guess the only time it matters where you output the text to, is when you mix different kinds of information (like data and errors) and caller wants to have only one of them.

Yes. And well maybe when people expect it to work like that and they are doing automation, idk....

[MrSmith33]

this will fully support calling C functions from external libraries (.so/.dll) right?

Yes, Vox uses C ABI everywhere atm, so all external functions that also use C ABI will work out of the box. Implementing object files is low priority. So you can assume no object file support for some time.

[rempas]

Nice! And imo If we already have fully support for C functions this way, they object files should not get implemented at all if they're going to reduce compilation times more than 10-15%. Of course that's an opinion and you may think differently but compilation times will be VERY import for anyone using Vox from they way I'm seeing it.

[MrSmith33]

There are only 2 usecases I want to support with .lib files: linking foreign language libraries into Vox executable/dll, or vice versa.