digitalmars.D - betterC and core.stdc modules; betterC and varargs routines
- Derek Fawcus (71/71) Oct 10 2024 Should betterC modules and programs be able to use the modules
- monkyyy (5/7) Oct 10 2024 Should? yes
- Richard (Rikki) Andrew Cattermole (4/4) Oct 10 2024 Looks like for dmd it defines functions with bodies.
- ryuukk_ (23/23) Oct 10 2024 ```D
- Derek Fawcus (6/7) Oct 14 2024 Thanks for the suggestions folks, so I've created a bug ticket,
- Derek Fawcus (3/5) Oct 14 2024 That alloca issue is:
- Salih Dincer (4/9) Oct 19 2024 Thanks for reporting issues. I wonder why you want to use
- Derek Fawcus (16/27) Oct 19 2024 I am evaluating its viability as something added to a large
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.
Oct 10 2024
monkyyy <crazymonkyyy gmail.com> 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
Oct 10 2024
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.
Oct 10 2024
```D
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
Oct 10 2024
On Friday, 11 October 2024 at 05:39:06 UTC, ryuukk_ wrote:To me this is a bug and it should be reportedThanks 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
Oct 14 2024
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
Oct 14 2024
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:Thanks for reporting issues. I wonder why you want to use low-level facilities and not D modules (e.g. FixedString)? SDB 79It 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
Oct 19 2024
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: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. DFOn Monday, 14 October 2024 at 20:32:08 UTC, Derek Fawcus wrote:Thanks for reporting issues. I wonder why you want to use low-level facilities and not D modules (e.g. FixedString)? SDB 79It 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
Oct 19 2024