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

Thanks,

Scott


On July 23, 2014 at 9:04:27 PM, Scott L. Brookes (scott.l.brookes.th@dartmouth.edu) 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():
> >
> > 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]