Mail Archives: djgpp-workers/1998/03/25/01:57:09
On Tue, 24 Mar 1998, Vik Heyndrickx wrote:
> Can't the libc be extended so that it autodetects the file contents
> type, i.e. text or binary data, e.g. by means of the following
> criterium:
It can be done (although I wouldn't suggest using this autodetection
in general-purpose library functions). But I don't see how would it
help to solve the problem at hand.
> The point I am trying to make is that the problem originates in the read
> of binary files that are written to text files and that it is not libc's
> task to make the write functions accept the binary data is if it were
> text, but that the read functions should operate on text data when it IS
> text data. You are trying to solve the problem where it occurs, I try to
> point you to the origin of the problem and that is nearly always a
> better place to deal with a problem.
There are programs which cannot work without reading files in binary
mode. Grep is such a program, and there are others. Writing the
screen in binary mode has a lot of disadvantages, so when such a
program writes parts of the files' content to the screen, it usually
will do so in text mode. These are exactly the programs that have the
problem for which I'm looking for a solution. Forcing these programs
to read in text mode will cause them to lose some of their features.
> (raw vs. cooked) == (binary vs. text) != (device vs. file)
Sorry, I must be slow this morning. What were you saying here?
> > Second, what do you return as the number of bytes written to the caller?
>
> Yes, I know that seems a problem, just the number of characters that
> preceded this ^Z, i.e. 0 for a buffer of data starting with ^Z.
This will cause some programs to loop indefinitely.
- Raw text -