This is the mail archive of the
mailing list for the newlib project.
Re: Backend for newlib's "scanf" family of functions
- From: "Scott L. Brookes" <Scott dot L dot Brookes dot TH at dartmouth dot edu>
- To: Eric Blake <eblake at redhat dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Thu, 24 Jul 2014 01:04:25 +0000
- Subject: Re: Backend for newlib's "scanf" family of functions
- Authentication-results: sourceware.org; auth=none
- References: <etPan dot 53d02424 dot 836c40e dot 22a at sbrookes-mbpr dot wireless dot dartmouth dot edu>,<53D04888 dot 10008 at redhat dot com>
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?
> On Jul 23, 2014, at 7:43 PM, "Eric Blake" <firstname.lastname@example.org> 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 http://libvirt.org