Open kg opened 5 years ago
Sigh, yeah I was a little bit overzealous with all these asserts in the past, one of many mistakes.
After taking a closer look it seems that nk_label_xxx
does not have these asserts. So it seems mostly a problem inside nuklear_selectable.c
with nk_do_selectable
, nk_do_selectable_image
and nk_do_selectable_symbol
being the main offenders. So it should be a quick fix by removing the specific asserts checking the length.
Another question would if zero strings are enough? Since nk_label
does accept zero length strings but not NULL
. Of course if NULL
should be allowed (and it is in release were most function will just return) a lot more function would need to be changed.
For a quick fix it should probably be enough to just remove the NK_ASSERT(len);
in these three functions I just mentioned. Then at least the ugly 2-byte buffer workaround could be removed. Also if you want and have the time could create a PR for it.
Zero length is fine, I think. It's easy to just set aside a one-byte buffer with a null in it that can safely be passed to both ptr+len and ptr APIs. If I can figure out why it still crashes with the assert gone I'll create a PR. I'm guessing it's performing a copy to a scratch buffer or something, but when I test it it trashes the stack so the crash happens later.
If a string's length is 0 various parts of nuklear's API crash or assert. For example, in nk_do_selectable:
I've arrived at a hack of creating a 2-byte buffer with zeroes in it and passing that as str, along with a len of 1. For some reason this avoids the crash and draws nothing, which is what I want.
The correct behavior would be for a len of 0 to just not draw anything. I tried to do this and it crashes for some reason anyway.