Skip to content
This repository has been archived by the owner on Dec 2, 2019. It is now read-only.

Change the whole library to not use any null-terminated strings #905

Open
Hejsil opened this issue Sep 18, 2019 · 6 comments
Open

Change the whole library to not use any null-terminated strings #905

Hejsil opened this issue Sep 18, 2019 · 6 comments

Comments

@Hejsil
Copy link
Contributor

Hejsil commented Sep 18, 2019

As discussed in #890

To make this change happen, it would be wise to change (not add new API calls) the whole library to not use any null-terminated strings. For this reason I'm currently a bit reluctant to approve this PR.

Would this involve removing APIs like nk_label and only having nk_text?

In this case yes as the only motivation to have nk_label was to support null-terminated strings wink

@dumblob
Copy link
Contributor

dumblob commented Sep 18, 2019

This makes sense to me for several reasons:

  1. it allows simpler, cleaner, and safer interfacing with other languages and libraries
  2. it does allow arbitrary use of \0
  3. it shouldn't constrain C users as they can can use e.g. the sds string trick to avoid the error-prone tracking of string length in separate variables

@Hejsil
Copy link
Contributor Author

Hejsil commented Sep 18, 2019

Another thing that would be nice with this change would be if all sizes where of type size_t. This also makes interfacing certain safer languages simpler (I can avoid an @intCast in Zig). It is also semantically more correct as I assume there is no way a length would ever be negative. strlen also returns size_t :)

One small con with such a change would be that C defines behavior for unsigned int overflows but signed int overflow is undefined. Operations on signed integers can optimize better because of this.

@Temtaime
Copy link

Temtaime commented Nov 5, 2019

Personally i don't see any reasons to not use null terminated strings. They are simple and fit very well as this is simple C gui library.
No reasons to overcomplicate it.

@dumblob
Copy link
Contributor

dumblob commented Nov 5, 2019

Personally i don't see any reasons to not use null terminated strings.

There is one. And it's very important one. Bindings to other languages. Nowadays "nobody" is writing GUIs in C. But libraries are written in C because of easy interoperability. And so is Nuklear.

No reasons to overcomplicate it.

Feel free to design a better solution conforming to the above mentioned requirement.

@Temtaime
Copy link

Temtaime commented Nov 5, 2019

C null terminated string is a standard. Every programming language has utilities for interoperability with it. I'm using Nuklear with Dlang and there's no pain with its API at all.
You don't insist to rewrite windows API for example, isn't it?

@dumblob
Copy link
Contributor

dumblob commented Nov 5, 2019

Every programming language has utilities for interoperability with it.

They do, but as you said with "having utilities". That's just a nice way of saying they don't support null-terminated buffers/strings as first class citizens. And I fully agree.

You don't insist to rewrite windows API for example, isn't it?

I don't follow - Nuklear has nothing to do with Windows API.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants