Every field value in the database would consist of a few octets, say 4, which says how long it is (a zero value indicates the field is null/empty), plus a string of octets having the actual field data, which is *not* null terminated. This would handle all of the current data types (strings, numbers, etc) unchanged, and also handle binary correctly.
Of course, this would necessitate a file format change, but that would probably be worthy for a version 2.9 or 3.0.
Corresponding to this, your basic low-level functions for manipulating data would just use stuff like memcpy() instead of strcpy(). This could also stand to make your code run a lot faster in some cases, as you would not have to scan a string to know how long it is; a scan moves every byte through the CPU. Whereas, if you wanted to copy a value, particularly a large one, you can just say "copy N bytes from address A to B" and that can execute entirely inside the memory, without the CPU seeing more than a few bytes.
And I certainly agree that having to encode any data for storage really slows things down.
Aside from habit, is there really any advantage to using null-terminated data over non-terminated and counted data?
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
