complain about paths starting with `-', by not calling getopt(3).
Submitted by: Tim J. Robbins <tim@robbins.dropbear.id.au>
Obtained from: NetBSD (partially)
MFC after: 1 month
after making test(1) a sh(1) builtin; sh(1) coredumps when you run
something like this:
sh -c 'test ! `true 1`'
The cause is that the test(1) code totally depends on the presence of
two extra cells at the end of argv that are filled with NULL's. The
reason why the bug hasn't been exposed would be because the C startup
code kindly prepares argv with some extra zeroed cells for a program.
I know this is not the best fix, but since there are argv++'s without
boundary checks everywhere, I'd rather patch it up like this
(preparing a copy of argv with extra NULL's) for the moment.
MFC after: 3 days
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 Change
int
foo() {
...
to
int
foo(void)
{
...
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 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)
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.
Approved by: arch@, new style(9)
o __P has been reoved
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.
Approved by: arch@, new style(9)
o __P has been reoved
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.
Approved by: arch@, new style(9)
Fixed setting of WARNS in rev.1.16. Options should normally be set using
using "?=", not using "=", so that the setting is easy to override on the
command line, and setting WARNS to 0 should not be an exception.
file sizes to be displayed with unit suffixes; Byte, Kilobyte,
Megabyte, Gigabyte, Terabyte and Petabyte in order to reduce the
number of digits to three or less.
Submitted by: nik
are now defined using the characters a-h and A-H for the bold
variants. The old way using 0-7 for the colours still works, but
prints a message asking the user to switch.
PR: bin/27374
circumstances. This is a reworked version of the same fix, that does
not have this defect, and which fixes some style bugs at the same time.
Bug reported and fix reviewed by: bde
(which somehow now seems to be the default for compiling -current).
This error popped up while doing a PicoBSD cross-compile on a 4.3-ish system,
it may well be that there are other apps which have similar problems,
but I did not spot them as they are not included in my picobsd config.
Whether adding prototypes for main() is the correct solution or not
I have no idea, a request to -current on the matter went basically
unanswered. Those who have better ideas are welcome to back this out
and replace it with the correct fix.
of the recent WARNS commits. The idea is:
1) FreeBSD id tags should follow vendor tags.
2) Vendor tags should not be compiled (though copyrights probably should).
3) There should be no blank line between including cdefs and __FBSDIF.
o explicitly check return values and variables against a value
o return x; -> return (x);
o fix inconsistent sysexits usage by nuking it (partially
suggested by bde)
Obtained from: TrustedBSD Project
group ACL entry in relation to the existing group and mask
ACL entries.
o Move the explanation of multiple ACL entries on the command
line to the ACL ENTRIES section.
Obtained from: TrustedBSD Project
used so often that it's worth keeping it as a builtin.
Now that all the printf invocations from within the system startup
scripts, we can safely remove it.
Urged by: sheldonh :)
No MFC is planned so far because it may break compatibility and
violate POLA.
binary size increase is 3,784 bytes (about 0.6%).
I don't drop the printf builtin while I'm here because some /etc/rc.*
scripts seem to use it before mounting /usr where printf(1) resides.
Reviewed by: arch (sheldonh)
Inspired by: NetBSD, ksh
Clued by: ume (on how the printf builtin is used)
setvar() and passed to setvareq(). When the VTEXTFIXED flag is set,
that copy is never freed, causing a memory leak.
PR: 31533
Submitted by: maxim@macomnet.ru
characters. Use quad conversion functions rather then long conversion
where appropriate to handle the available range. Mainly fixes time_t
but there was also a st_size ulong conversion in there that has to be
quad or cpio cannot be used to copy files > 2G.
MFC after: 1 day
Restore the code that avoided closing and reopening
stdin. This is also required by POSIX. As a bonus,
enable multiple stdin reads with the -benstv flags,
by resetting the EOF condition on stdin.
value CTLARI since this might break expansion of arithmetic expressions.
Don't access memory below start of stackblock.
Problem analyzed by hunt@iprg.nokia.com, slightly different patch applied.
PR: 24443
Submitted by: hunt@iprg.nokia.com
