va_end closer to the __vfprintf() call, free the buffer when __vfprintf()
fails and don't bother trying to shrink the buffer with realloc() before
returning it.
Submitted by: bde
Add a lock to FILE. flockfile and friends are now implemented
(for the most part) in libc. flockfile_debug is implemented in
libc_r; I suppose it's about time to kill it but will do it in
a future commit.
Fix a potential deadlock in _fwalk in a threaded environment.
A file flag (__SIGN) was added to stdio.h that, when set, tells
_fwalk to ignore it in its walk. This seemed to be needed in
refill.c because each file needs to be locked when flushing.
Add a stub for pthread_self in libc. This is needed by flockfile
which is allowed by POSIX to be recursive.
Make fgetpos() error return value (-1) match man page.
Remove recursive calls to locked functions (stdio); I think I've
got them all, but I may have missed a couple.
A few K&R -> ANSI conversions along with removal of a few instances
of "register".
$Id$ -> $FreeBSD$ in libc/stdio/rget.c
Not objected to: -arch, a few months ago
In some cases replace if (a == null) a = malloc(x); else a =
realloc(a, x); with simple reallocf(a, x). Per ANSI-C, this is
guaranteed to be the same thing.
I've been running these on my system here w/o ill effects for some
time. However, the CTM-express is at part 6 of 34 for the CAM
changes, so I've not been able to do a build world with the CAM in the
tree with these changes. Shouldn't impact anything, but...
more cleanly integrated with stdio. This should be faster and cleaner
since it doesn't memcpy() the data into a seperate buffer. This lets
stdio allocate and manage the buffer and then hand it over to the user.
Obtained from: Todd Miller <Todd.Miller@courtesan.com> via OpenBSD
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
not based on gpl'ed code, just prototype and usage. I'm not 100% certain
they behave the same while the system is in trouble (eg: malloc() failing)
but in those circumstances all bets would be off anyway.
These routines work like sprintf() and vsprintf(), except that instead of
using a fixed buffer, they allocate memory and return it to the user
and it's the user's responsibility to free() it. They have allocate as
much memory as they need (and can get), so the size of strings it can deal
with is limited only by the amount of memory it can malloc() on your
behalf.
There are a few gpl'ed programs starting to use this interface, and it's
becoming more common with the scares about security risks with sprintf().
I dont like the look of the code that the various programs (including
cvs, gdb, libg++, etc) provide if configure can't find it on the system.
It should be possible to modify the stdio core code to provide this
interface more efficiently, I was more worried about having something
that worked and was secure. :-) (I noticed that there was once intended
to be a smprintf() routine when our stdio was written for 4.4BSD, but it
looks pretty stillborn, and it's intended interface is not clear). Since
Linux and gnu libc have this interface, it seemed silly to bring yet
another one onto the scene.
