Backend for newlib's "scanf" family of functions

Scott L. Brookes
Thu Jul 24 19:40:00 GMT 2014

Hi all,

Thanks for your help and quick response - especially to you, Mr. Blake.

My confusion was coming from the idea that if process x does a scanf for a 
string from a pipe containing the data "hello world", it would of course 
recieve "hello" but that process y could then scanf "world" from the pipe. 

It seems that this is not the case. The first scanf from process x reads 
PIPE_BUF bytes (it may recieve less) and places them into its own input 
buffer. The thing that I did not understand is that after this operation, 
process y cannot get any data from the pipe. This goes against my intuition, 
but I saw this same behavior on Ubuntu, so it is what I'm going with.



On July 23, 2014 at 9:04:27 PM, Scott L. Brookes ( wrote:
> Hi Mr. Blake,
> Thanks so much for your quick response. I truly appreciate it. You've provided valuable  
> information that is helping me get a better understanding, but I am still having some  
> trouble.
> Suppose the pipe contains the data "hello world". You say that a scanf for a single string  
> (%s) will try to read PIPE_BUF bytes from the pipe. Per the POSIX read definition that  
> you linked, read would return the full "hello world" message from the pipe. However,  
> the scanf expects just "hello".
> You said that scanf can choose not to consume all of the bytes that it reads. I understand  
> that scanf could parse the data that it gets back, but now " world" has been removed from  
> the pipe and cannot necessarily be replaced at the beginning of the pipe. Can you elaborate  
> on this point?
> Thanks again,
> Scott
> > On Jul 23, 2014, at 7:43 PM, "Eric Blake" wrote:
> >
> >> On 07/23/2014 03:07 PM, Scott L. Brookes wrote:
> >>
> >> 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?
> >
> > scanf, and in general ALL stdio read operations (such as fread()), are
> > programmed to call read() in chunks that default up to PIPE_BUF bytes in
> > length, but where you can tune the default request by any calls to
> > setvbuf(). Your read() implementation can return shorter than the
> > requested amount if the sending end does not have that much ready;
> > scanf() may not consume all the bytes it read()s, and will call read()
> > again if it needs to consume more. Your best bet is to carefully
> > re-read the POSIX specifications of read() and write():
> >
> >
> >
> >
> >
> > and make sure your implementation obeys those rules.
> >
> > --
> > Eric Blake eblake redhat com +1-919-301-3266
> > Libvirt virtualization library
> >

More information about the Newlib mailing list