On 8/3/07, A. Pagaltzis <[email protected]> wrote: > * Peter da Silva <[email protected]> [2007-08-02 21:45]: > > > Please have the length of strings upfront. > > > > Length encoding isn't self-syncing, > > Synching the length is O(1). > > Not doing it makes *everything* O(n) and leaves you to deal with > the semi-predicate problem, source of lots of 'sploits and other > fun for the whole family. > > Pick your poison; I know which one I prefer. > > > and it also limits the length of individual parameters by the > > size of the length. > > So what? Just make sure the counter is wide enough for any string > you can keep in memory. > > Wasteful? So use a variable-width encoding for the length. It can > be brutally stupid as it only needs to be competitive with NUL > termination on very short strings. Using a single byte for > strings < 128 bytes and a machine word for anything longer will > do just fine. > > If you use the lowest bit as a flag to signify the type, then > massaging the counter takes under 2 cycles on average with > optimal machine code: ridiculously fast -- a common theme with > operations on length-prefixed strings. > > That C and UNIX immortalised zero-terminated strings amounts to a > crime if you consider the amount of CPU cycles that have since > been wasted scanning for NULs.
Not just that, also the amount of developer hours that have been wasted dealing with issues related to this subject. Length encoded strings (and related array support) are about the only thing that Wirth got right in Pascal that K&R got wrong in C. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
