fwrite/fread and unbuffered IO

[Etienne Fortin]

I already send it to the list.


-----Message d'origine-----
De : Joel Sherrill <joel@OARcorp.com> [mailto:joel.sherrill@OARcorp.com]

Envoyé : 17 septembre, 2004 15:42
À : Etienne Fortin
Cc : newlib@sources.redhat.com
Objet : Re: RE : fwrite/fread and unbuffered IO


Etienne Fortin wrote:
> I created a diff of modifications I made to fread.c of newlib 1.12.0. 
> It now works as I expect unbuffered read to work. If the FILE I/O is 
> unbuffered, then _read() is directly called with the suplied memory 
> pointer and the number of bytes asked for without any other 
> processing.

I don't know the proper behavior on this one.  Jeff?

> By the way, newlib 1.12.0 is working perfectly with RTEMS 4.6.1. The 
> only problem is a warning about implicit declaration of _fstat in 
> ttyname_r.c of libcsupport. The old header works but not the new of 
> newlib 1.12.0. Maybe it's something you are already informed of...

Send me this patch to the list so it can be incorporated into the newlib
cvs.  I also will grab this patch and use it with the RTEMS RPMs.

If someone approves your other patch, we will use it with RTEMS as well.

> I'm still not sure if this buffered read thing is the expected 
> behavior or not... Anyone please!!! ;)

Have you checked the opengroup.org standard pages?

--joel



> Etienne Fortin
> Sensio
> 
> 
> 131a132,146
> 
>>  /* *************************************** 
>>     AUTHOR: Etienne Fortin (2004-09-17)
>>     Change to accomodate for the fact that
>>     in unbuffered IO, there's no need to
>>     transit data via any kind of buffer.
>>     Because of that, we read into buf
>>     directly for the number of bytes needed.
>>     *************************************** */
>>  if (fp->_flags & __SNBF)
>>    {
>>      return (*fp->_read) (fp->_cookie, (char *) p, total);
>>    }
>>     
>>  /* *************************************** */
>>
> 
> 
> 
> 
> 
> 
> -----Message d'origine-----
> De : Joel Sherrill <joel@OARcorp.com> 
> [mailto:joel.sherrill@OARcorp.com]
> 
> Envoyé : 17 septembre, 2004 12:26
> À : Etienne Fortin
> Cc : newlib@sources.redhat.com
> Objet : Re: fwrite/fread and unbuffered IO
> 
> 
> Is this a termios device by any chance?
> 
> Could you try this with read()/write() not their f--- counterparts? 
> That would narrow the issue down to either RTEMS or newlib.
> 
> --joel
> 
> Etienne Fortin wrote:
> 
>>Hi everyone,
>>I'm playing with fread and fwrite and found some strange behaviors.
>>Well, behavior that I wasn't expecting.
>>
>>If I put my FILE in "unbuffered mode" with setvbuf() and I call
>>fwrite(), the memory pointer supplied to fwrite() is directly used as 
>>the source of the bytes being written to the stream. This is exactly 
>>what I expected since I'm unbuffered, ie no transit via some other 
>>buffer.
>>
>>But with fread, things are quite different. Let's say I'm unbuffered
>>and I write something like this:
>>
>>    fread(data, 1, 50, fp);
>>
>>I expect fread() to takes the "data" ptr directly as the container of
>>the received bytes. But strangely, instead, fread() use the 1 bytes 
>>buffer embedded in the FILE structure (_ubuf) as a transit buffer for 
>>the received characters. This is absolutely not the behavior I 
>>expected. If I tell the FILE stream to be unbuffered, I don't expect 
>>my data to transit via some buffer, even if that buffer is as small as
> 
> 
>>one byte. It's still a buffer. Also, this behavior is quite
>>inneficient since the driver function responsible for getting 
>>characters from the stream is called the number of bytes needed, in 
>>the example 50 times!!! Unbuffered IO doesn't mean a device can't read
> 
> 
>>bytes in sequence...
>>
>>Am I missing something here or is this behavior strange?
>>
>>Etienne Fortin
>>Sensio
>>
>>
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985