On Thu, 11 Sep 2014, Per Hedbor wrote:
On Thu, Sep 11, 2014 at 10:58 AM, Arne Goedeke <e...@laramies.com> wrote:
I think there is a couple of features that would be nice to have in
IOBuffer. If there is no objections I would go ahead and add them.
1) support for reading/writing signed integers. Not sure about the api,
maybe the current methods should could be renamed read_uint/add_uint
instead? The -1 return value also would not work for the read_ methods.
The add_int variants actually work fine for signed ints already, due to
the cast to unsigned. sprintf()/sscanf() could be used currently but are
quite slow.
The returns value is an issue, I guess using UNDEFINED makes sense.
In my "normal" usage I only use the return value for read_buffer and
friends however, and then set error mode and just read.
It really simplifies not having to check after each read, I just added
the -1 return value since it sort of makes sense. But UNDEFINED should
work just as well, really.
And renaming the current ones to read_u* makes sense if we add
non-unsigned versions, yes.
And add_int only sort of works, it will break for bignums, and also
normal integers
if the width > sizeof(INT_TYPE) (the code padds will null characters).
Yes, I noticed that digits() doesnt like negative numbers, when playing
with it. Sscanf/sprintf already have code internally for handling all
this stuff, maybe we can move that to a common c-api.
2) read_utf8/add_utf8. its not hard to do, quite common and would save
one string creation and copy.
It would be nice to avoid large amounts of code duplication, however.
I would split the current utf8 encoder/decoder into 2 functions, one for
calculating the length of the result and one doing the actual
encoding/decoding. f_utf8_to_string could then call those two directly,
as could IOBuffer. Sounds ok?
3) reading/writing ieee floats. also handled by sprintf/sscanf, but on
most systems would reduce to bswap+memcpy
That might be useful, yes. But is it really _that_ common? I guess it
makes since to be complete(ish). :)
Well, its not so very common, but it could also use the same code as
sprintf/sscanf does, so it would not add too much code.
4) little endian support? Admittedly the use cases are narrow for
network protocols, but not so much for file formats.
I avoided that since my point of view when initially implementing the
buffer was that it was mainly going to be used for network I/O. But it
does work for normal files as well, so it might indeed be useful.
It blows the number of functions up a bit, so maybe its not worth it.
arne
