On Thu, 1 Oct 2015 14:10:39 -0400 Greg Reagle <greg.rea...@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 <d...@frign.de>