file in the NFS file system when the underlying device is not a
network device. A Sparc64 specific hack for this exact problem was
already present (nfs.c:1.9, tftp.c:1.10), but the problem is not
specific to Sparc64. The hack has been promoted to a non-i386 test
because on non-i386 architectures it's either impossible to have
non-network devices coexist in the same loader with the NFS FS, or
network and non-network device coexist and NFS filesystems can only
be used on top of network devices. I believe i386 pxeboot is where
this does not hold.
The root cause of this problem is in open.c where each file system
is tried until no more file systems exist or a file system returns
success. There's no notion of a list of valid file systems given
the underlying device and the non-existence of a file can cause
the invalid combination to be tried.
in math.h; the consensus here was that __BSD_VISIBLE was correct instead.
- gamma_r, lgamma_r, gammaf_r, and lgammaf_r had no documentation in the
lgamma(3) manpage.
Reviewed by: standards@
Submitted by: Ben Mesander
The background info in this man page needs rewriting
in some parts since the last major changes
to the code, however it still accuratly reflects how to use the
API.
* use correct error detection of realloc failure
* strtol negative return check
* use strtol to validate string instead of rolling our own
validation code
* terminate the command sequence correctly
for the sorts of errors we run into[1]. This also gives us room to put in a
vaguely appropriate casts to silence warnings since our compiler doesn't like
when we compare ssize_t to size_t[2]. Add a cast in sblock.c[3] to silence
a warning because of signed vs. size_t hell (again). Clean up nearby
excessive parenthemutilation[4].
Reviewed by: bde [2] [3]
Suggested by: bde, many [1]
Submitted by: bde [4]
An aside about [4], bde notes that we do not check for a negative value for
the fs bsize. I'm nto going to do that in every situation we use it, one must
expect a reasonable program to pass down reasonable values. Some foot shooting
protection I will tolerate, some I will not. Also he suggests some possible
conditional improvements there, which I may take to heart.
PS: For me at least, this is now WARNS=5 clean...
seed->first value correlation. It breaks rand_r()... Other possible methods
like shuffling inside aray will breaks rand_r() too, because it assumes
only one word state, i.e. nothing extra can be added after seed assignment
in srand().
BTW, for old formulae seed->first value correlation is not so monotonically
increased as with other Linear Congruential Generators of this type only
becase arithmetic overflow happens. But overflow affects distribution
and lower bits very badly, as many articles says, such type of overflow
not improves PRNG.
So, monotonically increased seed->first value correlation problem remains...
Only warnings that could be fixed without changing the generated object
code and without restructuring the source code have been handled.
Reviewed by: /sbin/md5
