Thread overview
[Issue 24132] ImportC: Add support for wchar_t
Sep 03, 2023
ryuukk_
[Issue 24132] ImportC: Add support for wchar_t, char16_t, char32_t
Sep 03, 2023
Adam Wilson
Sep 12, 2023
Walter Bright
Oct 31
Dlang Bot
September 03, 2023
https://issues.dlang.org/show_bug.cgi?id=24132

ryuukk_ <ryuukk.dev@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ryuukk.dev@gmail.com

--- Comment #1 from ryuukk_ <ryuukk.dev@gmail.com> ---
Sounds like an easy PR to do, add the define here:

https://github.com/dlang/dmd/blob/master/druntime/src/importc.h

--
September 03, 2023
https://issues.dlang.org/show_bug.cgi?id=24132

Adam Wilson <flyboynw@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ImportC: Add support for    |ImportC: Add support for
                   |wchar_t                     |wchar_t, char16_t, char32_t

--- Comment #2 from Adam Wilson <flyboynw@gmail.com> ---
(In reply to ryuukk_ from comment #1)
> Sounds like an easy PR to do, add the define here:
> 
> https://github.com/dlang/dmd/blob/master/druntime/src/importc.h

It's not *quite* that simple. wchar_t is #define as an unsigned short in C, and either an unsigned short *or* an intrinsic type in C++. This means that when the preprocessor runs it emits an unsigned short. However, most C preprocessors have a switch that treat wchar_t as an intrinsic type instead of "typedef wchar_t unsigned short" However, the current ImportC implementation does not support this and vomits up errors when you try to use it.

What we need is the ability for ImportC to recognize wchar_t, char16_t, and char32_t *after* the preprocessor has run so that ImportC can emit the appropriate char/wchar/dchar types.

--
September 12, 2023
https://issues.dlang.org/show_bug.cgi?id=24132

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
C11 defines char32_t as uint_least32_t, which is specified to be a typedef, not a macro or a keyword.

Preprocessors usually key off the existence of __cplusplus to turn C++ semantics on and off. ImportC currently does not do that.

I suggest putting:

     typedef wchar_t unsigned short;

in your copy of importc.h and see how far that gets?

--
October 28
https://issues.dlang.org/show_bug.cgi?id=24132

--- Comment #4 from Adam Wilson <flyboynw@gmail.com> ---
So I was poking around the compiler source today and I noticed that in lexer.d at line 80 there is a reference to wchar_t in ImportC specific code, so it appears to know about wide-chars in C.

Then I discovered Ckeywords in tokens.d. So all we have to do is add wchar_ and dchar_ to that list and add the following to importc.h

#define wchar_t wchar
#define char16_t wchar
#define char32_t dchar

A little hacky maybe, but for ImportC it would work, and it would allow us to use D style strings natively which is the semantically correct outcome. IIRC, the wchar and dchar types are unsigned short and unsigned int respectively when using export(C) so that should function as normal.

--
October 31
https://issues.dlang.org/show_bug.cgi?id=24132

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #5 from Dlang Bot <dlang-bot@dlang.rocks> ---
@LightBender created dlang/dmd pull request #15757 "Issue 24132 - ImportC: Add support for wide-chars." fixing this issue:

- Fix Issue 24132. Add wchar/dchar to C Keywords list. Use #defines to convert C wide-chars to wchar/dchar.

https://github.com/dlang/dmd/pull/15757

--
November 21
https://issues.dlang.org/show_bug.cgi?id=24132

Adam Wilson <flyboynw@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Adam Wilson <flyboynw@gmail.com> ---
I'm going to close this as WON'T FIX.

I'll try to attack my problem with a post-processor script.

--