- The stack was getting smashed by __grow_type_table()
- reallocf() was being called with the wrong pointer
- The maximum argument number was being incorrectly computed
PR: misc/23521
the encoding and using the character set [a-zA-Z0-9]. This gives a total
of 62^6 = 56800235584 possible temporary filenames for the usual default
invocation of 6 X's (compared to as few as 52 possibilities for the
previous algorithm where up to 5 characters were wasted by the PID).
Update some apparently bitrotten comments to reflect reality.
Audited by: eivind, freebsd-audit
Reviewed by: freebsd-current (a while ago)
Originally submitted by: Peter Jeremy <Peter.Jeremy@alcatel.com.au>
rmdir(2) on directories and unlink(2) otherwise. This modification,
and most of the man page update has been obtined from OpenBSD. This
was spotted by someone on a mailing lists a few months ago, but
I've lost their mail.
Reviewed by: sheldonh
just use _foo() <-- foo(). In the case of a libpthread that doesn't do
call conversion (such as linuxthreads and our upcoming libpthread), this
is adequate. In the case of libc_r, we still need three names, which are
now _thread_sys_foo() <-- _foo() <-- foo().
Convert all internal libc usage of: aio_suspend(), close(), fsync(), msync(),
nanosleep(), open(), fcntl(), read(), and write() to _foo() instead of foo().
Remove all internal libc usage of: creat(), pause(), sleep(), system(),
tcdrain(), wait(), and waitpid().
Make thread cancellation fully POSIX-compliant.
Suggested by: deischen
points. For library functions, the pattern is __sleep() <--
_libc_sleep() <-- sleep(). The arrows represent weak aliases. For
system calls, the pattern is _read() <-- _libc_read() <-- read().
is good for... :-)), I discovered that part of the change when mkstemps()
was brought in was missed - it was missing the termination case to make
sure it doesn't walk into the suffix. This isn't the same code OpenBSD
has, I think this is a little better as we terminate the loop in a better
spot.
misinterpreted to mean that the pointer passed to asprintf() must be suitable
for passing to realloc() as-is (ie. either a NULL pointer or a valid pointer).
track.
The $Id$ line is normally at the bottom of the main comment block in the
man page, separated from the rest of the manpage by an empty comment,
like so;
.\" $Id$
.\"
If the immediately preceding comment is a @(#) format ID marker than the
the $Id$ will line up underneath it with no intervening blank lines.
Otherwise, an additional blank line is inserted.
Approved by: bde
compiling, since <stdio.h> correctly doesn't declare off_t although
the pseudo-prototypes for the new fseeko() and ftello() functions
use it. Handle this like the corresponding problem for va_list
versus the vprintf() family.
Fixed some English errors.
ever saw one), and move the description of NULL behaviour out to a
'NOTES' section, with an extra note that programs should not rely up
on it.
Kinda-approve-by: bde (by not replying to the mail with the diff)
string. From the submitted patch:
Credit for patch: Chris Torek <torek@bsdi.com>
Tod Miller <millert@openbsd.org>
This makes us in line with SunOS 4.1.3_U1, Solaris 2.6, OpenBSD 2.3,
HP-UX 10.20, Irix 5.3. The previous behavior was in line with Ultrix 4.4.
PR: bin/7970
Submitted by: Niall Smart nialls@euristix.ie
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
leading XXX's. It could wrap an uppercase character through chars
like: [ \ ] ^ _ ` in between Z and a. The backslash and back tick
might be particularly nasty in a shell script context. Also, since
we've been using upper-case generated values for a while now, go with
the flow and use them in the pathname search rotation.
Change the FILE locking to support kernel threads when linked with
libpthread (which you haven't see yet). This requires that libc become
thread-safe and thread-aware, testing __isthreaded before attempting
to do lock/unlock calls. The impact on non-threaded programs is minor.
This change works with libc_r, so it's the best compromise.
implement mkdtemp
improve man page for mk*temp
use arc4random to seed extra XXX's randomly
Optionally warn of unsafe mktemp uses
From various commits by theo de raadt and Todd Miller.
Obtained from: OpenBSD
This should go into 2.2 after a testing period.
case has very little to do with the output size being larger than
INT_MAX.
2. The new #include of <limits.h> was disordered.
3. The new declaration of `on' was disordered (integer types go together).
4. Testing an unsigned value for > 0 was fishy.
Submitted by: bde
instead of Singe Unix, thanx Bruce for explaining, I am not realize
standards war was there.
But now, fix n == 0 case to not return error and fix check for too
big n.
Things left to do: check for overflow in arguments.
Final word is Bruce's quote:
C9x specifies the BSD4.4-Lite behaviour:
[#3] ... Thus, the
null-terminated output has been completely written if and
only if the returned value is less than n.
It means that if we not have any null-terminated output as for n == 0
we can't return value less than n, so we forced to return value
equal to n i.e. 0
The next good thing is glibc compatibility, of course.
2) Do check for too big n in machine-independent way.
3) Minor optimization assuming EOF is < 0
The main argument is that it is impossible to determine if %n evaluated or not
when snprintf return 0, because it can happens for both n == 0 and n == 1.
Although EOF here is good indication of the end of process, if n is
decreased in the loop...
Since it is already supposed in many places that EOF *is* negative, f.e.
from Single Unix specs for snprintf
"return ... a negative value if an output error was encountered"
this not makes situation worse.
to pass not more than buffer size to %n agrument, old variant
always assume infinite buffer.
%n is for actually transmitted characters, not for planned ones.
"return the number of bytes needed, rather the number used"
According to Single Unix specs:
Upon successful completion, these functions return the number of bytes
transmitted excluding the terminating null
1) if buffer size is smaller than arguments size, return buffer
size, not arguments size as before.
2) if buffer size is 0, return 0, not EOF as before.
(now it is compatible with Linux and Apache implementations too).
NOTE: Single Unix specs says:
If the value of n {buffer size} is zero on a call to snprintf(), an
unspecified value less than 1 is returned.
It means we can't return EOF since EOF can take *any* value in general
not especially < 1. Better variant will be return -1 (it is less then
1 and different with n == 1 case) but -1 value is already occuped by
EOF in our implementation, so we can't distinguish true IO error
in that case. So 0 here is only possible case still conforming
to Single Unix specs.
on systems where long doubles are just doubles. FreeBSD hasn't
been such a system since it started using gcc-2.5 many years ago.
The fix is of low quality. It loses precision.
scanf() of long doubles doesn't seem to be used much, but gdb-4.16
uses %Lg format in its expression parser if it thinks that the
system supports printf'ing of long doubles. The symptom was that
floating point literals were usually interpreted to be 0.0.
and forgot what I was trying to do originally and accidently zapped
a feature. :-] The problem is that we are converting a counted buffer in
a malloc pool into a null terminated C-style string. I was calling realloc
originally to shrink the buffer to the desired size. If realloc failed, we
still returned the valid buffer - the only thing wrong was it was a tad
too large. The previous commit disabled this.
This commit now handles the three cases..
1: the buffer is exactly right for the null byte to terminate the
string (we don't call realloc).
2: it's got h.left = 0, so we must expand it to make room. If realloc
fails here, it's fatal.
3: if there's too much room, we realloc to shrink it - a failed realloc
is not fatal, we use the original buffer which is still valid.
so that all these makefiles can be used to build libc_r too.
Added .if ${LIB} == "c" tests to restrict man page builds to libc
to avoid needlessly building them with libc_r too.
Split libc Makefile into Makefile and Makefile.inc to allow the
libc_r Makefile to include Makefile.inc too.
- 0 was returned instead of EOF when an input failure occured while
skipping white-space after 0 assignments. This fixes PR2606. The
diagnosis in PR2606 is wrong.
- EOF was returned instead of 0 when an input failure occurred after
zero assignments and nonzero suppressed assignments.
- EOF was spelled -1.
This should be in 2.2.
a manner consistent with other implementations. Its done in a way that
adds only a tiny amount of overhead when positional arguments are not used.
I also have a test program to go with this, but don't know where it belongs
in the tree.
Submitted-By: Bill Fenner <fenner@FreeBSD.ORG>
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.
in a bunch of man pages.
Use the correct .Bx (BSD UNIX) or .At (AT&T UNIX) macros
instead of explicitly specifying the version in the text
in a bunch of man pages.
refilled) a file that was either line- or un-buffered, all files were
flushed. According to the code comment, the flush (according to ANSI)
is supposed to happen on write + line buffered output files, not _all_
files.
Obtained from: OpenBSD / Theo de Raadt, possibly from proven@cygnus.com
- buffer expansions were not working right due to a return code botch.
- signed types instead of size_t's meant somebody else went and put
casts in, I've changed the types to what they should have been.
Added $Id$'s to files that were lacking them (gpalmer), made some
cosmetic changes to conform to style guidelines (bde) and checked
against NetBSD and Lite2 to remove unnecessary divergences (hsu, bde)
One last code cleanup:-
Removed spurious casts in fseek.c and stdio.c.
Added missing function argument in fwalk.c.
Added missing header include in flags.c and rget.c.
Put in casts where int's were being passed as size_t's.
Put in missing prototypes for static functions.
Changed second args of __sflags() inflags.c and writehook() in vasprintf.c
from char * to const char * to conform to prototypes.
This directory now compiles with no warnings with -Wall under
gcc-2.6.3 and with considerably less warnings than before with the
ultra-pedantic script I used for testing. (Most of the remaining ones
are due to const poisoning).
The usual stuff, adding missing function prototypes, argument types,
return values, etc.
This directory now compiles with no warnings with -Wall on gcc2.6.3!
The usual stuff, adding missing function prototypes, argument types,
return values, etc. In mktemp.c, convert pid from u_int to pid_t, and
get rid of "extern int errno".
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.
nonstandard normal version and the standard threaded version.
Removed a bogus L in a constant. fpos_t's aren't longs, and casting to
fpos_t would be verbose.
the precision; ANSI X3J11 is not crystal clear but certainly says
that the precision specifies the number of /digits/, and signs
and "0x" aren't really digits.
NetBSD already has a similar patch.
resides in read-only memory is going to cause the program to core dump,
and this is commmon with older pre-ANSI C programs.
(I've scratched my head over this one at 3 in the morning before
while trying to port some ancient program)
Suggested by: Gary Kline <kline@tera.com>
commit by bde.
Fix bugs in floating point formatting. The 4.4lite version is similar
to revision 1.3 in old-cvs and is missing all of jtc's fixes in revision
1.4 in old-cvs. Revision 1.2 in ncvs fixed one of the old bugs but
introduced at least one new one (for %.0e).
old-cvs log:
revision 1.4
date: 1993/11/04 19:38:22; author: jtc; state: Exp; lines: +33 -20
My work from NetBSD to make printf() & friends ANSI C compliant.
Fixes several bugs in floating point formatting:
1. Trailing zeros were being stripped with %e format.
2. %g/%G formats incorrect.
3. Lots of other nits.
From: Chris Torek <torek@bsdi.com>
Here is a semi-official patch (apply to /usr/src/lib/libc/stdio/fseek.c,
rebuild libc, install). The current code fails when the seek:
- is optimized, and
- is to just past the end of the block currently in the buffer, and
- is followed by another seek with no intervening read operation, and
- the destination of subsequent seek is within the block left in the
buffer (seeking to the beginning of a block does not force a read,
so the buffer still contains the previous block)
so it is indeed rather obscure.
I may have a different `final' fix, as this one `loses' the buffer
contents on a seek that goes just past the end of the current block.
[Footnote: seeks are optimized only on read-only opens of regular
files that are buffered by the file's optimal I/O size. This is
what you get with fopen(path, "r") and no call to setvbuf().]
Obtained from: [ BSDI mailing list ]
