From: William G. Greathouse (wgreathouse@smva.com)
Date: Sat Nov 25 2000 - 20:01:55 EST
All,
There is a bug in the uC-libc library code regarding buffering.
stdin and stdout ("buffered" descriptors) receive buffers of 4 bytes,
while stderr ("unbuffered" descriptor) receives a buffer of 8 bytes.
If you look closely, you will see that the library misassigns the
buffer size as being sizeof (char *) instead of the actual buffer
size. Also, you must realize that a buffered file descriptor is
only flushed to the device when the buffer is full (every 4 bytes
in the uncorrected library), at a "newline" output, when fflush(stdout)
is called, or when input is requested on stdin. Please note that
uC-libc also fails to flush stdout when input is requested on stdin.
If you want unbuffered output, you should use stderr or call fflush
explicitly. This is standard C I/O. It is not specific to the uC-libc
implementation.
Attached, you will find my updates to uC-libc stdio that corrects
the buffered I/O buffer size problem and the automatic flush on input
problem. There are also other corrections that may or may not be
important to you. Please note that this patch may not apply cleanly
to your sources, as it is generated from my NET+Lx (NETARM uClinux)
library with updates. You can probably look at the diff file and
see what needs to be done manually if needed.
Good luck and let me know if this corrects the errors you are seeing
(I know it solved my I/O problems).
Enjoy,
Bill
Corrections/updates in the attached patch:
1. Memory leak in resolv.c
2. Memory corruption in resolv.c
3. Ignore T_SIG responses from name server which causes
lookup failures on successful lookups.
4. General cleanup/update of resolv.c
5. Additional standard include file (arpa/nameser.h) and
appropriate changes
6. Fix stdio.c buffering error. Unbuffered streams had
an 8 character buffer, buffered streams had a 4 character
buffer!
7. In stdio.c stderr is supposed to be unbuffered
8. In stdio.c fgets loop error could result in buffer overruns
9. In stdio.c flush stdout pending output on read request from stdin
10. et.al.
Apply from uC-libc directory using "patch -p1 <uC-libc.patch001005"
-----Original Message-----
From: owner-uclinux-dev@uClinux.org
[mailto:owner-uclinux-dev@uClinux.org]On Behalf Of Lars Qvist
Sent: Saturday, November 25, 2000 9:57 AM
To: uclinux-dev@uClinux.org
Subject: [uClinux-dev] More about printf
Hello again,
I tried a little more with printf.
I only run following (no function call)
gets(s);
for(y=0, s[y], y++]
{
printf("%c", s[y]);
}
This program only prints 0,4,8,12 and so on characters!!!
gets(s);
for(y=0, s[y], y++]
{
printf("%c", s[y]);
}
puts("");
This program prints all character!!!
strlen(s) is OK!!!
I am pretty shure it has something to do with the Tx-FIFO buffer in the
UART.
The buffer can create an interrupt when the buffer has 4 characters
remaining.
Is this interrupt used by uClinux or how is the UART handled?
I entered a delay of 10 seconds between the "for-loop" and the "puts"
and could clearly see that the remaining characters appeared with the
"puts" .
Best Regards
Lars Qvist
This message resent by the uclinux-dev@uclinux.org list server
http://www.uClinux.org/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:19 EDT