Hello!

This is my first time posting, so do feel free to correct me and this post.

I started writing in D around Q2 2017 and recently been re-writing some of my projects as betterC (entirely!).

I noticed something weird. It started with DMD 2.074.0 and it's still an issue for me in DMD 2.079.1 (and any other compiler really).

Consider this piece:

```
import core.stdc.stdio;

extern(C) void main() {
	printf("a");
}
```

It compiles and runs absolutely wonderful (OMF, MSCOFF, ELF, etc.). No issues.

Now consider this piece:

```
import core.stdc.stdio;

extern(C) void main() {
	putchar('a');
}
```

Oops, `Error 42: Symbol Undefined __D4core4stdc5stdio7putcharFNbNiNeiZi`! To my surprise, `putchar` is extern'd as D in druntime/src/core/stdc/stdio.d, and I find that _really silly_.

Which means `putchar`, during linking, is affected for linking every single C runtime out there, and the only reason I can think of is to easily integrate it with D in general, which in my opinion, is not necessarily needed since the D people (not meant as an insult) promotes betterC as a stand-alone option.

On Windows, stdin, stdout, and stderr are affected when using -m32mscoff and -m64 (and obviously, LDC) because under CRuntime_Microsoft, std* are defined as `shared`.

I'm aware that an easy solution would be defining a version (D_betterC) section.

Will I do a Pull Request? Unfortunately no, I fear I'll abandon mid-way through. It's easier to advise the forums and let an actual professional integrate the fix.

If you have other suggestions, I'm all ears.

On Sunday, 29 April 2018 at 14:42:39 UTC, dd886k wrote:
> Hello!

Embarrassingly enough, I just noticed I made a typo to my usual username.

On 30/04/2018 2:42 AM, dd886k wrote:
> Hello!
> 
> This is my first time posting, so do feel free to correct me and this post.
> 
> I started writing in D around Q2 2017 and recently been re-writing some of my projects as betterC (entirely!).
> 
> I noticed something weird. It started with DMD 2.074.0 and it's still an issue for me in DMD 2.079.1 (and any other compiler really).
> 
> Consider this piece:
> 
> ```
> import core.stdc.stdio;
> 
> extern(C) void main() {
>      printf("a");
> }
> ```
> 
> It compiles and runs absolutely wonderful (OMF, MSCOFF, ELF, etc.). No issues.
> 
> Now consider this piece:
> 
> ```
> import core.stdc.stdio;
> 
> extern(C) void main() {
>      putchar('a');
> }
> ```
> 
> Oops, `Error 42: Symbol Undefined __D4core4stdc5stdio7putcharFNbNiNeiZi`! To my surprise, `putchar` is extern'd as D in druntime/src/core/stdc/stdio.d, and I find that _really silly_.
> 
> Which means `putchar`, during linking, is affected for linking every single C runtime out there, and the only reason I can think of is to easily integrate it with D in general, which in my opinion, is not necessarily needed since the D people (not meant as an insult) promotes betterC as a stand-alone option.
> 
> On Windows, stdin, stdout, and stderr are affected when using -m32mscoff and -m64 (and obviously, LDC) because under CRuntime_Microsoft, std* are defined as `shared`.
> 
> I'm aware that an easy solution would be defining a version (D_betterC) section.
> 
> Will I do a Pull Request? Unfortunately no, I fear I'll abandon mid-way through. It's easier to advise the forums and let an actual professional integrate the fix.
> 
> If you have other suggestions, I'm all ears.

Welcome.

I just checked, extern(D) isn't at fault. You actually do want name mangling for wrapper functions like that.

Did you only -I the file? If you compile it in normally, it won't error out. Normally its compiled into druntime and hence Phobos.

We really should have functions like this be templated (empty brackets) so that it'll work with just -I happily.

On Sunday, 29 April 2018 at 14:55:06 UTC, rikki cattermole wrote:
> I just checked, extern(D) isn't at fault. You actually do want name mangling for wrapper functions like that.

Re-externing what I need as C is wasted productivity, IMO.

> Did you only -I the file? If you compile it in normally, it won't error out. Normally its compiled into druntime and hence Phobos.

Yeah, I am using core.stdc which _is_ from druntime indeed, but
the hint here is _stdc_ (and more specifically, _std_).

> We really should have functions like this be templated (empty brackets) so that it'll work with just -I happily.

Really it's simply a betterC-related issue and thus why I
proposed the insertion of some version (D_betterC) here and
there.

On 30/04/2018 3:05 AM, dd86k wrote:
> On Sunday, 29 April 2018 at 14:55:06 UTC, rikki cattermole wrote:
>> I just checked, extern(D) isn't at fault. You actually do want name mangling for wrapper functions like that.
> 
> Re-externing what I need as C is wasted productivity, IMO.
> 
>> Did you only -I the file? If you compile it in normally, it won't error out. Normally its compiled into druntime and hence Phobos.
> 
> Yeah, I am using core.stdc which _is_ from druntime indeed, but
> the hint here is _stdc_ (and more specifically, _std_).
> 
>> We really should have functions like this be templated (empty brackets) so that it'll work with just -I happily.
> 
> Really it's simply a betterC-related issue and thus why I
> proposed the insertion of some version (D_betterC) here and
> there.

This issue has nothing to do with -betterC or extern(D).
You can get this same issue without it added if you don't link against phobos/druntime.

It also isn't specific to core.stdc.*. Just your usage of it (-I'ing only).

On 2018-04-29 16:42, dd886k wrote:
> Hello!
> 
> This is my first time posting, so do feel free to correct me and this post.
> 
> I started writing in D around Q2 2017 and recently been re-writing some of my projects as betterC (entirely!).
> 
> I noticed something weird. It started with DMD 2.074.0 and it's still an issue for me in DMD 2.079.1 (and any other compiler really).
> 
> Consider this piece:
> 
> ```
> import core.stdc.stdio;
> 
> extern(C) void main() {
>      printf("a");
> }
> ```
> 
> It compiles and runs absolutely wonderful (OMF, MSCOFF, ELF, etc.). No issues.
> 
> Now consider this piece:
> 
> ```
> import core.stdc.stdio;
> 
> extern(C) void main() {
>      putchar('a');
> }
> ```
> 
> Oops, `Error 42: Symbol Undefined __D4core4stdc5stdio7putcharFNbNiNeiZi`! To my surprise, `putchar` is extern'd as D in druntime/src/core/stdc/stdio.d, and I find that _really silly_.
> 
> Which means `putchar`, during linking, is affected for linking every single C runtime out there, and the only reason I can think of is to easily integrate it with D in general, which in my opinion, is not necessarily needed since the D people (not meant as an insult) promotes betterC as a stand-alone option.
> 
> On Windows, stdin, stdout, and stderr are affected when using -m32mscoff and -m64 (and obviously, LDC) because under CRuntime_Microsoft, std* are defined as `shared`.
> 
> I'm aware that an easy solution would be defining a version (D_betterC) section.
> 
> Will I do a Pull Request? Unfortunately no, I fear I'll abandon mid-way through. It's easier to advise the forums and let an actual professional integrate the fix.
> 
> If you have other suggestions, I'm all ears.

Looks like "putchar" is inlined [1]. That means the "putchar" you're referencing is not the one in the C standard library but it's implemented in druntime. That means you need to link with druntime/phobos, it's not enough to link with the C standard library.

I don't know why it was done this way. Perhaps it's just a macro on some platforms.

[1] https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1289

-- 
/Jacob Carlborg

On Sunday, 29 April 2018 at 15:14:25 UTC, rikki cattermole wrote:
> This issue has nothing to do with -betterC or extern(D).
> You can get this same issue without it added if you don't link against phobos/druntime.

Oh heh I think you're right. It is only an issue when linking and by default it does link the C runtime, so I'll be fine making a source file externing everything myself. Didn't think of that, oops.

On Sunday, 29 April 2018 at 15:40:20 UTC, Jacob Carlborg wrote:
>
> I don't know why it was done this way. Perhaps it's just a macro on some platforms.

I think it's to better integrate with normal D code (thread safety, which explains the stdin is tagged with shared (TLS)).

It's all fine now. I'll type away my own bindings in a separate source file (stdc.d).

On Sunday, 29 April 2018 at 15:52:11 UTC, dd86k wrote:
> It's all fine now. I'll type away my own bindings in a separate source file (stdc.d).

You can also just do it in the usage module, for the individual functions you need. I do this a lot for various C libraries (and used to for the Win32 functions before they were included)

BTW i haven't tried win32 functions with betterC. we should - and they should generally work, though the struct inits might cause linker errors in some cases.

General tip btw: if you do see a linker error about "undefined symbol _Dsomething_init", you can probably just use `= void` when declaring the struct so it is not automatically initialized (so same behavior as C) and then memset it to 0 or whatever you need.

On Sunday, 29 April 2018 at 15:40:20 UTC, Jacob Carlborg wrote:
> I don't know why it was done this way. Perhaps it's just a macro on some platforms.

At least ms, glibc and freebsd provide it as a function.