This is the mail archive of the 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]

Backend for newlib's "scanf" family of functions


I am new to the newlib mailing list, but I hope that you will be able to help meÂ
understand how scanf and related functions work.Â

Some context:

I am trying to implement piping in a shell on a custom operating system thatÂ
uses newlib as its C library. I have an implementation of pipes in the operatingÂ
system - open, read, write, and close all work as defined in the POSIX standardÂ
when called in relation to a pipe/FIFO.Â

For piping the output of one command to the input of another, the common processÂ
is to open a pipe, then fork both processes and use the dup2 call to set stdoutÂ
for the first process to the write end of the pipe and stdin for the second toÂ
the read end of the pipe. This works just fine and calling read and write (toÂ
file descriptors 0 and 1, respectively) works as I would expect. However,Â
replacing these with printf and scanf does not work. The printf side works justÂ
fine (data is written to the buffer), but the scanf side is not working.

The question:Â

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

Coincidentally, we found out when trying to tackle this problem that scanf neverÂ
worked for reading from stdin, either... but I think that this case raises theÂ
same questions.Â

Thanks so much! Any info will help!

- Scott

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