logoalt Hacker News

fsckboylast Saturday at 1:14 AM1 replyview on HN

you misunderstood what i said about the strlen field, but we agree, yes, it's in the header where it belongs.

I explained how returning the address of the string buffer instead of the address of the struct would give you a C compatible string that you could pass to other C library functions. If those functions are "readonly" wrt the string, everything is copasetic.

if those string functions update/write the c-string (which is in the buffer) the strlen in the header will now be wrong. That has nothing to do with my suggestion, and it's already "broken" in that way you point out. My "string free bytes field" suggestion will also be broken by an operation like that, so my suggestion does not make this data structure worse than it already is wrt compatibility with C library functions.

However that strlen and free bytes problem can be managed (no worse than C standard strings themselves) and strlen and/or free bytes are useful features that make some other things easier so overall it's a win.


Replies

ranger_dangerlast Saturday at 2:52 AM

I was basing my response off of this:

> i did see a place to shave a byte in the sds data struct. The null terminator is a wasted field

I'm still not sure what byte in the struct you're talking about removing... because I don't see an actual null terminator field.

show 1 reply