News for hackers. Stuff that matters.

A comment on Designing a better strcpy. Parent comment

Re:Designing a better strcpy by codesnik on Saturday June 19, 2021 @06:23PM (#27565044)
you can also have something akin to MIDI encoding with higher bit reserved to mark that next byte is a part of length field, too. up to 128 bytes with no overhead, up to 16kb with one byte overhead, and so on. Such a detail would be easy to hide in the library. But I wouldn't be surprised that alignment and other troubles would eat any possible gain.
[ Parent | on HN ]
Re:Designing a better strcpy by habibur on Sunday June 20, 2021 @03:14AM (#27567870)
> But I wouldn't be surprised that alignment ... troubles would eat any possible gain.

It's string. Alignment shouldn't be a problem. Rather alignment issues are for the pointers to that string.

[ Parent | on HN ]
Re:Designing a better strcpy by WalterBright on Saturday June 19, 2021 @06:45PM (#27565203)
Won't work with UTF-8.
[ Parent | on HN ]
Re:Designing a better strcpy by thrwaeasddsaf on Saturday June 19, 2021 @07:49PM (#27565650)
Works with any encoding and arbitrary binary data. The last byte of the length field doesn't have the high bit set, and whatever follows after that is completely irrelevant.

But still needless complexity for this.

[ Parent | on HN ]
Re:Designing a better strcpy by moonchild on Saturday June 19, 2021 @10:31PM (#27566587)
Sure it is, the length is out of band. In fact, you could even use utf-8 to encode the length!
[ Parent | on HN ]