This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Backend for newlib's "scanf" family of functions


On 07/23/2014 07:04 PM, Scott L. Brookes wrote:

> 
> 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?

stdio is buffered. It read()s what is generally more bytes than
necessary from the pipe (and can never push them back into the pipe)
into its buffer, and then does scanf from the contents of that buffer.
As long as your process is going to consume everything from the pipe,
then it really doesn't matter how much or little buffering exists in
between.  If, on the other hand, you are one of the rare programs (like
/bin/sh) that is required by POSIX to not consume too much of stdin in
case another process is going to consume the rest of stdin after what
you finish reading, then you can use setvbuf() to make the stdio buffer
be exactly 1 byte long, for a read() for every single byte and a huge
noticeable inefficiency hit, but where you no longer read data off the
pipe that you aren't planning on using.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]