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.
