of releases. The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.
Approved by: re (scottl), markm
Discussed on: freebsd-current, in late April 2004
and a warning that this "restricted mode" can be bypassed easily by
using symlinks, so that users don't depend too much on it.
PR: docs/35940
Submitted by: Gary W. Swearingen <swear@blarg.net>
Reviewed by: jmallett
MFC after: 1 week
proper parens mean that fd is always set by open(2) [in any part of C],
and so we can accurately check for it returning -1, without feeling like
we need to initialise fd to -1 in its declaration.
In other words, fix a stylistic/bogus nit.
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
o gc some #ifdef sun ... #endif code
Approved by: arch@, new style(9)
fseek -> fseeko
ftell -> ftello
NOTE: that fseek/ftell not works for >long offsets per POSIX:
[EOVERFLOW] For fseek( ), the resulting file offset would be a value which
cannot be represented correctly in an object of type long.
[EOVERFLOW] For ftell ( ), the current file offset cannot be represented
correctly in an object of type long.
o Add consts where appropriate.
o Rename some variables that were shadowing global declarations.
o Remove register storage-classes.
o Make errmsg a const, so we can just set error messages instead
of using sprintf/strcpy.
o Set WARNS=2
Reviewed by: bde, des
which is also called from handle_hup(), uses stdio(3). Furthermore,
this means that calling exit(3) (via quit()) there is required to
flush the buffer write_file() was working on.
Submitted by: bde
error caused by the -1 being on the wrong side of the comparison.
This would not cause an overflow, as near as I can tell, because we
truncate later anyway. We'd just fail to get a diagnostic for 1024
and 1025 byte file names.