The remaining problem of converting highly incompatible pointer types
is done by "laundering" the value through a union.
This solves the problem (in my own mind) of how a "const char *" _ever_
actually gets a value in a WARNS=2 world.
Fixed macros for temporarily relinquishing and restoring setuid/setgid
privileges so that they never change the real user and group IDs of
the calling process.
The setre[ug]id() calls are still used in the REDUCE_PERM macro (with
the r[ug]id arguments of -1) so that the call changes the saved user
and group IDs of the process to that specified.
Also, the panic() and perr() functions had insufficient privileges to
delete the problematic file under /var/at.
documented behavior. Only a certain set of file flags were recognized,
and "no" flags did not match files that have corresponding flags bits
turned off.
Fix and extend the -flags functionality as follows:
: -flags [-|+]<flags>,<notflags>
: The flags are specified using symbolic names (see chflags(1)).
: Those with the "no" prefix (except "nodump") are said to be
: <notflags>. Flags in <flags> are checked to be set, and flags in
: <notflags> are checked to be not set. Note that this is different
: from -perm, which only allows the user to specify mode bits that
: are set.
:
: If flags are preceded by a dash (``-''), this primary evaluates
: to true if at least all of the bits in <flags> and none of the bits
: in <notflags> are set in the file's flags bits. If flags are pre-
: ceded by a plus (``+''), this primary evaluates to true if any of
: the bits in <flags> is set in the file's flags bits, or any of the
: bits in <notflags> is not set in the file's flags bits. Otherwise,
: this primary evaluates to true if the bits in <flags> exactly match
: the file's flags bits, and none of the <flags> bits match those of
: <notflags>.
MFC after: 2 weeks
fseek -> fseeko
ftell -> ftello
fseek(x, 0L, 0) -> rewind(x)
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.
fseek -> fseeko
ftell -> ftello
NOTE: 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.
long -> off_t
fseek -> fseeko
NOTE: that fseek not works for >long offsets files per POSIX:
[EOVERFLOW] For fseek( ), the resulting file offset would be a value which
cannot be represented correctly in an object of type long.
strtol -> strtoll
fseek -> fseeko
NOTE: that fseek not works for >long offsets files per POSIX:
[EOVERFLOW] For fseek( ), the resulting file offset would be a value which
cannot be represented correctly in an object of type long.
long -> off_t
strtol -> strtoll
fseek -> fseeko
NOTE: that fseek not works for >long offsets files per POSIX:
[EOVERFLOW] For fseek( ), the resulting file offset would be a value which
cannot be represented correctly in an object of type long.
asprintf(3) when creating the request string, as the length of
a path is defined as unlimited by the standard and limiting the
total request to 4K is awfully arbitrary.
PR: 30054
Submitted by: Joseph Mallett <jmallett@xMach.org>
MFC after: 8 days
* When the author of an utility also wrote its manual page (a rarety, I
know), it is not necessary to say that the utility "and this manual
page" were written by the author.
o This option is not available outside of the United States and Canada.
o Because of export controls, TELNET ENCRYPT option is not supported outside
of the United States and Canada.
src/crypto/README revision 1.5 commit log says:
> Crypto sources are no longer export controlled:
> Explain, why crypto sources are still in crypto/.
and actually telnet encryption is used outside of US and Canada now.
Pointed out by: OHSAWA Chitoshi <ohsawa@catv1.ccn-net.ne.jp>
Reviewed by:no objection on doc
the uses of it were wrong anyway.
o Always check for NULL returns on strdup(3).
o Fix a possible buffer overflow in strcpy(3).
o Fix a format string vulnerability.
o t->ty_type in stypeof() could be NULL and eventually cause
a segmentation fault in setenv(3), so check for that.
Eyeballed by: kris
Reviewed by: murray
MFC after: 3 days
message. Similar information is given by the talk daemon when a
connection is requested, but that part isn't on the screen when the
main "talk" screen appears, and sometimes it's nice to know who you're
talking to.
Reviewed by: ru
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
