On Thu, 1 Oct 2015 14:10:39 -0400
Greg Reagle <greg.reagle_AT_umbc.edu> wrote:
Hey Greg,
> See attached.
I honestly do not like this patch. This will make it
very difficult to add variable integer lengths later
on.
What I can think of is approaching this issue by
emalloc'ing (BUFSIZ * size) bytes and use the fact that
read() allows us to specify the length of the chunks.
If we have 16 Bytes per line (bpl), we just read in
(bpl / size) chunks. This allows us to solve line-break
issues in the middle of a chunk and could even allow
us to keep the static BUFSIZ-buffer (read won't read
in partial chunks, problem solved).
Then we can pass a void * of the read chunk to print
value().
Inside print value, we know the size of the memory
segment, so what we do is assemble a long long value
from the memory (one simple for-loop).
The advantage of this is that we don't have to butch the
main loop too much and we open the way for a more
general approach.
This would also allow us to print 3-byte-chunks
effortlessly, which the GNU coreutils cannot.
If I hadn't an exam coming up next week, I'd do it
myself. If you have no idea what the hell I'm talking
about, wait until next Wednesday, when I've taken
the exam.
On thing left to discuss would be how to handle the
printing. I'd heuristically set the format on the
next major integral type.
For instance, when we read in a 3 byte chunk, we
want to take the next larger integral type (which
is int32 with 4 bytes).
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Fri Oct 02 2015 - 11:57:42 CEST