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


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" <eblake@redhat.com> 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():
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
> 
> and make sure your implementation obeys those rules.
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 


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