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.
a malloc. The signal handler creates a thread which requires a malloc...
For now, the only thing to do is to block signals. When we move user
pthreads to use the kernel threads, mutexes will be implemented in kernel
space and then malloc can revert.
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.
Note this ONLY affects the function version - the macro version is always
used unless for some reason you put #undef sigismember in your code before
calling it.
PR: 3615
Submitted by: Nanbor Wang <nw1@cs.wustl.edu> (slightly amended patch)
Obtained from: Whistle Communications tree
Add an option to the way UFS works dependent on the SUID bit of directories
This changes makes things a whole lot simpler on systems running as
fileservers for PCs and MACS. to enable the new code you must
1/ enable option SUIDDIR on the kernel.
2/ mount the filesystem with option suiddir.
hopefully this makes it difficult enough for people to
do this accidentally.
see the new chmod(2) man page for detailed info.
Ever since I first say the way the mount flags were used I've hated the
fact that modes, and events, internal and exported, and short-term
and long term flags are all thrown together. Finally it's annoyed me enough..
This patch to the entire FreeBSD tree adds a second mount flag word
to the mount struct. it is not exported to userspace. I have moved
some of the non exported flags over to this word. this means that we now
have 8 free bits in the mount flags. There are another two that might
well move over, but which I'm not sure about.
The only user visible change would have been in pstat -v, except
that davidg has disabled it anyhow.
I'd still like to move the state flags and the 'command' flags
apart from each other.. e.g. MNT_FORCE really doesn't have the
same semantics as MNT_RDONLY, but that's left for another day.
PR: 4555
Submitted by: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>
[0x0400 - 0xffff] [bbbbbbbb.bbbbbbbb] -> 1110bbbb, 10bbbbbb, 10bbbbbb
.Ed
.Pp
If more than a single representation of a value exists (for example,
0x00; 0xC0 0x80; 0xE0 0x80 0x80) the shortest representation is always
used (but the longer ones will be correctly decoded).
.Pp
The final three encodings provided by X-Open:
.Bd -literal
[00000000.000bbbbb.bbbbbbbb.bbbbbbbb] ->
11110bbb, 10bbbbbb, 10bbbbbb, 10bbbbbb
[000000bb.bbbbbbbb.bbbbbbbb.bbbbbbbb] ->
111110bb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb
[0bbbbbbb.bbbbbbbb.bbbbbbbb.bbbbbbbb] ->
1111110b, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb
.Ed
.Pp
which provides for the entire proposed ISO-10646 31 bit standard are currently
not implemented.
.Sh "SEE ALSO"
.Xr mklocale 1 ,
.Xr setlocale 3
@
1.4
log
@Don't use hardcoded *roff font change requests. Do it
via mdoc macros instead.
@
text
@d37 1
a37 1
.Dd "June 4, 1993"
@
1.3
log
@Very minor mdoc cleanup.
@
text
@d44 2
a45 1
\fBENCODING "UTF2"\fP
@
1.2
log
@Another round of various man page cleanups.
@
text
@d65 1
a65 1
.sp
d81 1
a81 1
.sp
@
1.2.2.1
log
@YAMFC:
Commit all of the -current changes that apply to 2.2. These fall into
several categories:
- Cosmetic/mdoc changes. They don't really afect the output
at all, but having them in 2.2 will make it easier to diff the man
pages later when looking for real changes.
- Update some man pages to reflect the current 2.2 header files.
- Sort xrefs.
- A few typo fixes.
- And a few changes that actualy added text to the man page that should
be reflected in 2.2.
- Add some missing MLINKS.
Requested by: bde
@
text
@d44 1
a44 2
.Nm ENCODING
.Qq UTF2
d65 1
a65 1
.Pp
d81 1
a81 1
.Pp
@
1.2.2.2
log
@MFC: Just the locale fixes (small doc tweaks for the most part)
and the new strptime(3) call. Having added something, does this
require a version bump? Haven't we bumped once already?
There are a *LOT* of additional 3.0 changes to be merged but I'm not
entirely comfortable with some of them so I'll take the conservative
(read: cowardly :) way out and just merge this much.
@
text
@d37 1
a37 1
.Dd June 4, 1993
@
1.1
log
@Initial revision
@
text
@d41 1
a41 1
.Nm UTF2
@
1.1.1.1
log
@BSD 4.4 Lite Lib Sources
@
text
@@
1.1.1.1.6.1
log
@Phase 2 of merge - also fix things broken in phase 1.
Watch out for falling rock until phase 3 is over!
libc completely merged except for phkmalloc & rfork (don't know if David
wants that).
Some include files in sys/ had to be updated in order to bring in libc.
@
text
@d41 1
a41 1
.Nm utf2
@
1.1.1.1.6.2
log
@This 3rd mega-commit should hopefully bring us back to where we were.
I can get it to `make world' succesfully, anyway!
@
text
@d41 1
a41 1
.Nm UTF2
@
partway through its attempt to decode the result structure sent by
the server. If this happens, it can leave the result partially
populated with dynamically allocated memory. In this event, the
xdr_replymsg() failure is detected and RPC_CANTDECODERES is returned,
but the memory in the partially populated result struct is not
free()d.
The end result is that memory is leaked when an RPC_CANTDECODERES
error occurs. (This condition can occur if a CLIENT * handle is created
using clntudp_bufcreate() with a receive buffer size that is too small
to handle the result sent by the server.)
Fixed by setting reply_xdrs.x_op to XDR_FREE and calling
xdr_replymsg() again to free the memory if an RPC_CANTDECODERES error
is detected.
I suspect that the clnt_tcp.c, clnt_unix.c and clnt_raw.c modules
may ha a similar problem, but I haven't duplicated the condition with
those yet.
Found by: dbmalloc
to fail under certain circumstances.
1. In one spot, the ifr_flags member was being examined in the
wrong structure, thus it contained garbage. On a machine in which
only the loopback interface was up, this caused everything that
wanted to talk to the portmapper to fail -- a particular problem
with laptops, where the pccard ethernet interface is likely to come
up long after the attempt to start mountd, nfsd, amd, etc.
2. Compounding the above problem, get_myaddress() returned a
successful status even though it failed to find an address that it
considered good enough.
This fixes bugs in the manual handling. abs.[cS] was handled too
specially and the wrong (.c) variant for each of div.[cS], labs.[cS]
and ldiv.[cS] was added to SRCS. This caused the .c variant to be
used if `depend' was made and the .S version to be used otherwise.
The names of m-d variants are now added (manually) to MDSRCS instead
of to SRCS, and the names of all machine-independent (m-i) variants
that can reasonably be replaced by an m-d variant are now added
(manually) to MISRCS instead of to SRCS, so that a simple substitution
can be used to discard the unused m-i variants. MISRCS is potentially
all m-i sources, but the substitution is too simple to be fast, so
MISRCS should be kept reasonably small.
libc/Makefile.inc:
Do the substitution.
libc/i386/string/Makefile.inc:
Add to MDSRCS instead of to SRCS. Add the names of all sources in this
directory, but no others.
libc/string/Makefile.inc
Add to MISRCS instead of to SRCS. Add the names of all sources in this
directory. Don't use (broken) explicit rules for special cases.
for the entire time that it was there, so obviously nothing needs it
anymore.
Note, unix98/single-unix spec v2 says that usleep() returns an int rather
than a void, to indicate whether the entire time period elapsed (0) or an
error (eg: signal handler) interrupted it (returns -1, errno = EINTR)
It is probably useful to make this change but I'll test it locally first
to see if this will break userland programs [much]...
Reviewed by: ache, bde
back to the original single nanosleep() implementation. This is POSIX and
Unix98 (aka single-unix spec v2) compliant behavior. If a program sets
alarm(2) or an interval timer (setitimer(2)) without a SIGALRM handler
being active, sleep(3) will no longer absorb it, and the program will get
what it asked for..... :-]
The original reason for this in the first place (apache) doesn't seem to
need it anymore, according to Andrey.
Reviewed by: ache, bde
made to the RPC code some months ago. The value of __svc_fdsetsize is being
calculated incorrectly.
Logically, one would assume that __svc_fdsetsize is being used as a
substitute for FD_SETSIZE, with the difference being that __svc_fdsetsize
can be expanded on the fly to accomodate more descriptors if need be.
There are two problems: first, __svc_fdsetsize is not initialized to 0.
Second, __svc_fdsetsize is being calculated in svc.c:xprt_registere() as:
__svc_fdsetsize = howmany(sock+1, NFDBITS);
This is wrong. If we are adding a socket with index value 4 to the
descriptor set, then __svc_fdsetsize will be 1 (since fds_bits is
an unsigned long, it can support any descriptor from 0 to 31, so we
only need one of them). In order for this to make sense with the
rest of the code though, it should be:
__svc_fdsetsize = howmany(sock+1, NFDBITS) * NFDBITS;
Now if sock == 4, __svc_fdsetsize will be 32.
This bug causes 2 errors to occur. First, in xprt_register(), it
causes the __svc_fdset descriptor array to be freed and reallocated
unnecessarily. The code checks if it needs to expand the array using
the test: if (sock + 1 > __svc_fdsetsize). The very first time through,
__svc_fdsetsize is 0, which is fine: an array has to be allocated the
first time out. However __svc_fdsetsize is incorrectly set to 1, so
on the second time through, the test (sock + 1 > __svc_fdsetsize)
will still succeed, and the __svc_fdset array will be destroyed and
reallocated for no reason.
Second, the code in svc_run.c:svc_run() can become hopelessly confused.
The svc_run() routine malloc()s its own fd_set array using the value
of __svc_fdsetsize to decide how much memory to allocate. Once the
xprt_register() function expands the __svc_fdset array the first time,
the value for __svc_fdsetsize becomes 2, which is too small: the resulting
calculation causes the code to allocate an array that's only 32 bits wide
when it actually needs 64 bits. It also uses the valuse of __svc_fdsetsize
when copying the contents of the __svc_fdset array into the new array.
The end result is that all but the first 32 file descriptors get lost.
Note: from what I can tell, this bug originated in OpenBSD and was
brought over to us when the code was merged. The bug is still there
in the OpenBSD source.
Total nervous breakdown averted by: Electric Fence 2.0.5
to POSIX.2. In particular:
- don't retry for ETXTBSY. This matches what sh(1) does. The retry code
was broken anyway. It only slept for several seconds for the first few
retries. Then it retried without sleeping.
- don't abort the search for errors related to the path prefix, in
particular for ENAMETOOLONG, ENOTDIR, ELOOP. This fixes PR1487. sh(1)
gets this wrong in the opposite direction by never aborting the search.
- don't confuse EACCES for errors related to the path prefix with EACCES
for errors related to the file. sh(1) gets this wrong.
- don't return a stale errno when the search terminates normally without
finding anything. The errno for the last unsuccessful execve() was
usually returned. This gave too much precedence to pathologies in the
last component of $PATH. This bug is irrelevant for sh(1).
The implementation still uses the optimization/race-inhibitor of trying
to execve() things first. POSIX.2 seems to require looking at file
permissions using stat(). We now use stat() after execve() if execve()
fails with an ambiguous error. Trying execve() first may actually be a
pessimization, since failing execve()s are fundamentally a little slower
than stat(), and are significantly slower when a file is found but has
unsuitable permissions or points to an unsuitable interpreter.
PR: 1487
'slow' lookup if we get a YPERR_MAP (no such map in server's domain) error
instead of failing over on any error. In the latter case, if the 'fast'
search fails legitimately (i.e. the user or host really isn't a member
of the specified netgroup) then we end up doing the 'slow' search and
failing all over again. The result is still correct, but cycles are
consumed for no good reason.
Also removed the #ifdef CHARITABLE since the compat kludge is no longer
optional.
Andrey A. Chernov
Bruce Evans
John Birrell
James Raynard
John Polstra
Bill Paul
Julian Elischer
KATO Takenori
John-Mark Gurney
Steve Price
Wolfgang Helbig
Joerg Wunsch
Masafumi Max NAKANE
Peter Wemm