Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Wide String Constants #1947

Open
NotsoanoNimus opened this issue Feb 9, 2025 · 2 comments
Open

Feature Request: Wide String Constants #1947

NotsoanoNimus opened this issue Feb 9, 2025 · 2 comments
Assignees
Labels
Additional info please Further information is requested

Comments

@NotsoanoNimus
Copy link

Hi, I believe this is a fairly seldom-used feature of C, but would there be any possibility of adding in C wide string constants to C3?

Ordinary C usage:

char16_t *MyString = L"Compile-time wide string as a raw array of bytes; no frills";

This feature is useful when writing for constrained environments that do not support higher-level language constructs like WString (i.e. when not using the stdlib --> --use-stdlib=no / --link-libc=no).

Plenty of firmware/loaders utilize this feature regularly per UEFI requirements. In my current C3 testing with UEFI, I've been dynamically converting normal char arrays to wchar arrays using the UEFI allocator to get by.

--

In C3, raw strings and other string constant types could also use this L prefix.

def wchar = ushort;   // alt. `def char16 = ushort`
// ...

    wchar *simple_wide_str = L`C:\Path\To\File`;

It's possible I missed this in the language documentation as some other feature. The FourCC character literals get close, but they don't allow a complete string-like capability without manually creating an inline array of them.

@lerno
Copy link
Collaborator

lerno commented Feb 9, 2025

I could perhaps add a builtin for it, so rather than adding the L prefix, it would be something like @stringw("Hello world"). Would that be sufficient?

@lerno lerno self-assigned this Feb 9, 2025
@lerno lerno added the Additional info please Further information is requested label Feb 9, 2025
@NotsoanoNimus
Copy link
Author

@lerno Absolutely, I think that would get the job done for a more obscure feature of the language, especially one that probably isn’t worth the effort of a whole new string prefix.

Leveraging the builtin, I will likely do my best to hack a way to make it as concise as possible with macros/preprocessing after the fact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Additional info please Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants