Re: ?problem with read("*l") with binary data

[Tom Oehser <tom@...>]

>>it won't *break* anything for libio to allow nulls in a string on *l

>Yes, but it will slow down the processing of files line by line, which is

Will it?  That depends on the libc implementation.  Interestingly, the gnu
C library documentation has warnings about fgets, recommending gnu getline
as a replacement.  I'll do some benchmarking, but, fgets already has to go
through looking for \n and might not be any faster than buffered reads of
the fscanf used in read(N).  I certainly don't assume it would slow it
down, I would almost bet that there would be no speed cost of putting the
scan for \n in liolib.  All of this stuff is using buffered streams, after
all, so it isn't as though you are really reading one byte vs. one line.

>I suggest that you add a new function "readuntil(c)" that reads
>everything until it finds a byte "c", or add a new option "*Uc" to

Conceivably that is useful, also.  But, I'll have to see it to believe
that there is really a performance cost to eliminating the fgets() call.

Either way, I'll do the research and benchmark it on a couple of
platforms and submit a patch offer...

-Thanks -Tom