3 ms·

oof bit packing to save a single bit? https://github.com/maxim2266/str/blob/f4e84657b23977ab3c5cd760523b7c99bc90da92/str.h#L59 https://github.com/maxim2266/str

oof bit packing to save a single bit? https://github.com/maxim2266/str/blob/f4e84657b23977ab3c5cd760523b7c99bc90da92/str.h#L59 https://github.com/maxim2266/str/blob/f4e84657b23977ab3c5cd7... seems unlikely to matter if you have a bunch of strings flying around... two features I'd love to see implemented: - wrapping thread safe tokenization using strtok_r so it's pleasant to tokenize a string - sprintf-like formatting anything that improves string handling in C is doing God's work

kevin_thibedeau 6y ago
strtok_r() destructively modifies its input so wrapping it works against this library's objective of using const ponters. It is easy enough to reimplement, though, and I've done this for similar sub-string pointer objects that work without NUL termination.
- souprock 6y ago
  The existence of strtok_r() is weird anyway. If we can make errno thread-safe, there is no reason why plain strtok() can't be thread-safe. The idea that somebody wants strtok() state shared across threads is just as weird as the idea that errno should be shared across threads.
  - kevin_thibedeau 6y ago
    The C API was never designed with threading in mind. Not all platforms support threads so the old behavior must stay around.
    - souprock 6y ago
      Say what? You like to call plain strtok() from different threads, having them all update a shared global state? I think you missed the point here, because that would be some really evil usage of the strtok() function. We had "int errno" as global state. We fixed it, in a compatible way, to be thread-safe. Platforms without threads can still implement it the old way if desired. The same kind of compatible fix could have been done with the strtok() function. There was no need to introduce another function. Simply: the internal state of strtok() shall be distinct for each thread. (which is trivial if the platform only supports a single thread)
jsnell 6y ago
It's not about saving a bit, but about saving an entire word. If the length and ownership weren't packed together, you'd need one more field in the str struct for the ownership bit, and due to alignment the minimum size increase would be a word.

kevin_thibedeau 6y ago

strtok_r() destructively modifies its input so wrapping it works against this library's objective of using const ponters. It is easy enough to reimplement, though, and I've done this for similar sub-string pointer objects that work without NUL termination.

souprock 6y ago
The existence of strtok_r() is weird anyway. If we can make errno thread-safe, there is no reason why plain strtok() can't be thread-safe. The idea that somebody wants strtok() state shared across threads is just as weird as the idea that errno should be shared across threads.
- kevin_thibedeau 6y ago
  The C API was never designed with threading in mind. Not all platforms support threads so the old behavior must stay around.
  - souprock 6y ago
    Say what? You like to call plain strtok() from different threads, having them all update a shared global state? I think you missed the point here, because that would be some really evil usage of the strtok() function. We had "int errno" as global state. We fixed it, in a compatible way, to be thread-safe. Platforms without threads can still implement it the old way if desired. The same kind of compatible fix could have been done with the strtok() function. There was no need to introduce another function. Simply: the internal state of strtok() shall be distinct for each thread. (which is trivial if the platform only supports a single thread)

jsnell 6y ago

It's not about saving a bit, but about saving an entire word. If the length and ownership weren't packed together, you'd need one more field in the str struct for the ownership bit, and due to alignment the minimum size increase would be a word.