Backend for newlib's "scanf" family of functions

[Scott L. Brookes]

Hello!

I am new to the newlib mailing list, but I hope that you will be able to help me 
understand how scanf and related functions work. 

Some context:

I am trying to implement piping in a shell on a custom operating system that 
uses newlib as its C library. I have an implementation of pipes in the operating 
system - open, read, write, and close all work as defined in the POSIX standard 
when called in relation to a pipe/FIFO. 

For piping the output of one command to the input of another, the common process 
is to open a pipe, then fork both processes and use the dup2 call to set stdout 
for the first process to the write end of the pipe and stdin for the second to 
the read end of the pipe. This works just fine and calling read and write (to 
file descriptors 0 and 1, respectively) works as I would expect. However, 
replacing these with printf and scanf does not work. The printf side works just 
fine (data is written to the buffer), but the scanf side is not working.

The question: 

How is scanf repackaged into read calls? Calling with a string format specifier, 
there is no way to know how many bytes to ask for in the read. Expirementation 
saw a read request for 1024 bytes, which would lead me to believe that it is up 
to my pipe implementation to give only chars up to a whitespace, but how does 
this jive with the POSIX definition of a read on a pipe? 

Coincidentally, we found out when trying to tackle this problem that scanf never 
worked for reading from stdin, either... but I think that this case raises the 
same questions. 

Thanks so much! Any info will help!

- Scott