I'm starting with the easy cases. The leftovers need to be looked at a
bit more closely.
Note that this change _does_ modify the code of the old tests. This is
required in order to allow the code to locate the data files in the
source directory instead of the current directory, because Kyua
automatically changes the latter to a temporary directory.
Also note that at least one test is known to be broken here. Actually,
the test is not really broken: it's marked as a TODO but unfortunately
Kyua's TAP parser currently does not understand that. Will have to be
fixed separately.
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
Obtained from: OpenBSD
Note: In the case of a full buffer the OpenBSD implementation will
leave in the format string an invalid escape sequence. This appears
to be harmless with our C library, but according to C99 this can
cause undefined behavior.
MFC after: 2 weeks
Note: It would be nice to be able to implement getformat() using
fmtcheck(3), but fmtcheck does not distinguish between signed and
unsigned types, a facility jot needs to perform range checks on its
output.
Submitted by: Per Kristian Hove
MFC after: 2 weeks
- Reduce the number of global variables
- Make global objects static
- Use bool consistently
- Sort getopt arguments and their processing
- Add function comments
- Change notlast != 0 into !last
Up to now jot would fail to generate the last character in the range
or skew the integer distribution in a way that would generate the numbers
in the range's limits with half the probability of the rest.
This modification fixes the program, rather than documenting the
strange behavior, as suggested in docs/54879.
Also, correctly specify the range of random(3).
PR: docs/54879
MFC after: 2 weeks
sequence of random numbers.
This functionality was lost in revision 1.9 when the random number
generator was switched to arc4random.
PR: docs/54879
MFC after: 2 weeks
would print it with probability 1/2**32. It seems that the correct
behavior is to print 4 with probability 1/4, but I'd like to avoid
breaking POLA until all the range inconsistencies in jot can be fixed
in one pass. See PR for details.
PR: 54878
Submitted by: David Brinegar <jot.3.brinegar@spamgourmet.com>
constant, just in case uint32_t turns into a `short' ten years from now.
If this is MFC'd it will be necessary to hard-code the constant since
-stable doesn't have UINT32_MAX.
Noteworthy changes include:
* Use getopt(3).
* Fix overflows in -b and -w options.
* Use strlcpy(3) and snprintf(3) in favor of strcpy(3) and
sprintf(3), respectively. Also check return values of the former
two.
* Fix lots of other gratuitous differences with OpenBSD.
Obtained from: OpenBSD
