Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

sp.h: Fixing C by giving it a high quality, ultra portable standard library

spader.zone

Post reply on HN
Print view View original

221–222 of 222 posts

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#221

Post by pjmlp »

skydhash wrote: post #155
Luker88 wrote: post #146

> C is valuable because it’s simple This is funny to me because just today some friends gave me a link to a C quiz: https://stefansf.de/c-quiz/ From which I gathered that it is a much more cursed language than I remembered. Maybe we all just got used to C and just happen to use a minimal subset. The problems with C are not mainly with the standard library, but any effort to improve things should be lauded.

There's C the standard, and there's C the implementation (compiler & platform). The standard is nice to have on a bookshelf, but your main reference should be the implementation.

Until one cares about writing portable code across implementations.

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#222

Post by diffuse_l »

boricj wrote: post #101
diffuse_l wrote: post #84

Earlier quoted context omitted.

Nothing prevents you from using a shared pool of strings that don't have null terminator. It can even be more efficient, since you don't have the null byte to handle at string end. Depending on the maximum string length you want to support, it doesn't even have to take more space.

How do you represent that pool of strings on-disk? If we concatenate the raw strings together without the null terminator, either all string references will require a length on top of the offset (25% size penalty for a Elf32_Sym ), or we'll need a separate descriptor table that stores string offsets and lengths to index into. If we prepend strings with a length (let's say LEB128), we'll be at best tied with null-term…

For short strings (probably most of them) - use a byte for the length (at the string/symbol definition site, alongside the offset) (adds 1 byte * symbols, use high bit if necessary to add bytes for longer strings). You need the offset into the table anyway. It isn't strictly better, but it isn't strictly worse, and it gives you the option to reuse sub-strings.
Post reply on HN