[DTrace-devel] [PATCH 12/14] Add support for NULL strings

[Nick Alcock]

On 3 May 2023, Eugene Loh via DTrace-devel uttered the following:

> On 5/2/23 12:24, Nick Alcock wrote:
>
>> On 2 May 2023, eugene loh said:
>>
>>> Specifically, define a byte string DT_NULL_STRING whose first byte is
>>> 0x00 but with extra nonzero bytes to distinguish between empty and NULL
>>> strings.  An empty string stored as a static variable will have its
>>> first bytes all zero.  A NULL string will have its first bytes be
>>> DT_NULL_STRING.  That is, both will have initial byte 0, and then we
>>> have to go further to distinguish the two cases.
>> You might want to note that this is the same technique that older DTrace
>> implementations always used.
>
> Where can I see (e.g., in DTv1 source code) what was done?

... good question. I thought I knew but I can't find any sign of it
now. Maybe I was hallucinating. Dammit. I guess don't say that then :)

>>> We require strsize >= sizeof(DT_NULL_STRING), which is reasonable.
>> We might waste up to three bytes! I think we can live with that (what's
>> the overhead of a map value anyway? 16 bytes? More? :) ).
>
> How waste three bytes?  It's sufficient to have two bytes (leading
> 0x00 and then one more byte), and if you have two-byte strings they
> are only really one char long (plus terminating byte).  Anyhow, we
> don't want to make DT_NULL_STRING too wide, but there really is no
> practical issue here.

Up to two bytes, I can't count. But yes there really isn't any problem
at all.

>> I'm assuming here that you caught all the places that need changing (a
>> quick check suggests you did). If someone else wants to check...
>
> Actually, if s and t are strings and t==NULL, then s=t needs to be
> handled.  That's the reason for my posting a v2 patch.  Also, while
> the disasm fix will still be good, the disasm test was a little too
> picky.  So, I'll modify that patch as well.

Thanks!

-- 
NULL && (void)