Thread overview
betterC and core.stdc modules; betterC and varargs routines
Oct 10
monkyyy
Oct 11
ryuukk_
3 days ago
Salih Dincer
3 days ago
Derek Fawcus
October 10

Should betterC modules and programs be able to use the modules under core.stdc? I certainly expected they should, or at least for many modules.

The specific issue I ran in to was with varargs routines, and making use of core.stdc.stdarg, where I had to link with phobos.

$ cat stdarg1.d
import core.stdc.stdarg;

pragma(printf)
public extern(C) int wrap_printf(scope const char* f, ...) {
	import core.stdc.stdio;

	va_list ap;

	va_start(ap, f);
	auto rc = vprintf(f, ap);
	va_end(ap);

	return rc;
}

extern(C) void main() {
	wrap_printf("Foo\n");
}
$ dmd -betterC stdarg1.d
/usr/bin/ld: stdarg1.o: in function `wrap_printf':
stdarg1.d:(.text.wrap_printf[wrap_printf]+0xce): undefined reference to `_D4core4stdc6stdarg6va_endFNbNiPSQBf8internal6vararg8sysv_x6413__va_list_tagZv'
collect2: error: ld returned 1 exit status
Error: undefined reference to `nothrow @nogc void core.stdc.stdarg.va_end(core.internal.vararg.sysv_x64.__va_list_tag*)`
       referenced from `wrap_printf`
       perhaps `.d` files need to be added on the command line, or use `-i` to compile imports
Error: linker exited with status 1
       cc stdarg1.o -o stdarg1 -m64 -Xlinker --export-dynamic -L/usr/lib/x86_64-linux-gnu -lpthread -lm -lrt -ldl

Yet I can make it link, and work using:

$ dmd -c -betterC stdarg1.d
$ dmd -of=stdarg1 stdarg1.o
$ ./stdarg1
Foo

I tried to work around this via the following, and various variations, however I ran a different issue.

$ cat stdarg2.d
pragma(printf)
public extern(C) int wrap_printf(scope const char* f, ...) {
	import stdarg2c;
	extern(C) int vprintf(scope const char*, va_list);

	va_list ap;

	va_start(ap, f);
	auto rc = vprintf(f, ap);
	va_end(ap);

	return rc;
}

extern(C) void main() {
	wrap_printf("Foo2\n");
}
$ cat stdarg2c.c
#include <stdarg.h>
$ dmd -betterC stdarg2.d
stdarg2.d(2): Error: `__va_list_tag` is not defined, perhaps `import core.stdc.stdarg;` ?

Actually importing core.stdc.stdarg as it suggests simply brings back the original issue.

October 10

On Thursday, 10 October 2024 at 20:48:45 UTC, Derek Fawcus wrote:

>

Should betterC modules and programs be able to use the modules under core.stdc?

Should? yes
Will? unlikely

BetterC and the platforms it enables should not be considered supported

October 11
Looks like for dmd it defines functions with bodies.

LDC and GDC use builtins instead.

https://github.com/dlang/dmd/blob/f6f520aedeec5f823b9d5dae431d1760a82e8639/druntime/src/core/stdc/stdarg.d#L319

Add ``-i=core.stdc.stdarg`` and it should compile it in.
October 11

import core.stdc.stdarg;


// add this
extern(C) void va_end(void* ap){}

pragma(printf)
public extern(C) int wrap_printf(scope const char* f, ...) {
    import core.stdc.stdio;

    va_list ap;

    va_start(ap, f);
    auto rc = vprintf(f, ap);
    va_end(ap);

    return rc;
}


extern(C) void main(int argc, const(char)** argv)
{
    wrap_printf("Foo\n");
}

Adding: extern(C) void va_end(void* ap){} works for me, looks like DMD doesn't do its job properly

If -betterC can't do what C does, then it's not -betterC, but -worseC

To me this is a bug and it should be reported

October 14

On Friday, 11 October 2024 at 05:39:06 UTC, ryuukk_ wrote:

>

To me this is a bug and it should be reported

Thanks for the suggestions folks, so I've created a bug ticket, and attached a diff to fix the issue. It did however reveal another similar issue with lack of access to alloca() from betterC.

https://issues.dlang.org/show_bug.cgi?id=24814

October 14

On Monday, 14 October 2024 at 20:32:08 UTC, Derek Fawcus wrote:

>

It did however reveal another similar issue with lack of access to alloca() from betterC.

That alloca issue is:

https://issues.dlang.org/show_bug.cgi?id=24815

3 days ago
On Monday, 14 October 2024 at 21:00:27 UTC, Derek Fawcus wrote:
> On Monday, 14 October 2024 at 20:32:08 UTC, Derek Fawcus wrote:
>> It did however reveal another similar issue with lack of access to alloca() from betterC.
>
> That alloca issue is:
>
> https://issues.dlang.org/show_bug.cgi?id=24815

Thanks for reporting issues. I wonder why you want to use low-level facilities and not D modules (e.g. FixedString)?

SDB@79
3 days ago
On Saturday, 19 October 2024 at 11:40:22 UTC, Salih Dincer wrote:
> On Monday, 14 October 2024 at 21:00:27 UTC, Derek Fawcus wrote:
>> On Monday, 14 October 2024 at 20:32:08 UTC, Derek Fawcus wrote:
>>> It did however reveal another similar issue with lack of access to alloca() from betterC.
>>
>> That alloca issue is:
>>
>> https://issues.dlang.org/show_bug.cgi?id=24815
>
> Thanks for reporting issues. I wonder why you want to use low-level facilities and not D modules (e.g. FixedString)?
>
> SDB@79

I am evaluating its viability as something added to a large multi-threaded time critical C based code base, as a means to add some safety, and maybe (eventually) lift to higher abstractions.

Hence it being a case of using betterC, and the parts where it should be able to use any C APIs it has offered.

A specific template based implementation of strings is completely irrelevant to my evaluating the ability to make use of alloca(), or va_copy() - which is how I found the alloca issue. Likewise for anything else offered via core.stdc.

The things I've found so far, if presented to colleagues without viable workaround would result in use of the betterC subset of D simply being a non starter.

Looking in to available third party library packages is simply not a consideration at this stage.

DF