our Convert(). And check it for failure. This fixes three sets of
problems:
(1) depending on the passed-in value of Timezone it might
disassemble the time in one timezone and reassemble it in
another, causing mysterious offsets of a few hours;
(2) with the previous set of changes to this file, Convert() fails
if it ends up normalizing a date, so e.g. going three months
forward from March 31 would fail;
(3) previously if Convert() failed we passed -1 on to DSTcorrect(),
which made a mess.
PR 50574.
- Add validation to date/time strings by checking that mktime did not change
the fields of struct tm from the ones requested
- Allow the format "year monthname day".
From kre
- fix missing/inconsistent abbreviations
- set dst only if we are using localtime.
- properly check for errors where there were missing checks
- handle errno properly including saving and restoring.
Add vmemoryuse to login_cap(3)
Document vmemoryuse in login.conf(5)
Document proc.pid.rlimit.vmemoryuse and proc.pid.rlimit.maxlwp in sysctl(7)
Document SBSIZE, AS, VMEM and NTHR in share/doc/psd/05.sysman/1.6.t
Reviewed by <riastradh>
Approved by <pgoyette>
Tested by Dominik Bialy
Closes PR xsrc/49912
* A magic value USE_LOCAL_TIME (defined as 99999) may be passed as the
Timezone to Convert(), instructing it to use mktime() to work
in the local time zone, instead of using mktime_z to work in UTC
(and then adding the specified timezone offset).
* Some old code is removed now that there's no need to find the local
timezone offset.
* Allow either one or both of the now and zone arguments to
parsedate() to be NULL, treating them independently. Previously,
if either one was NULL, the other was ignored.
* If the zone argument is specified, then the current date is calculated
in the specified zone, not in local time.
Also add some disabled debug code.
This should fix PR lib/47916.
a numeric timezone. Move some productions from "time" to "time_numericzone".
Increment yyHaveZone when encountering one of these.
Previously, input of the form "HH:MM:SS +ZZZZ" would not have set the
yyhaveZone flag.
that was designed for handling two-digit abbreviated years.
For example, "1/2/70" still refers to the year 1970, as before,
but "70-01-02" now refers to the year 70.
* Add a new yyHaveFullYear member to struct dateinfo, to record whether
or not the year needs to be adjusted.
* Code that parses years sets yyHaveFullYear=1 if they know that the
year should not be adjusted (as is the case for ISO 8601 dates), or if
they perform their own adjustment (as is the case for CVS timestamps).
* Move the year adjustment code into a new function, AdjustYear,
instead of inline in Convert().
* Make Convert() assume the year doesn't need to be adjusted,
and make Convert's callers first call AdjustYear() if appropriate.
This works for BSD disklabels, providing full compatibility. Merge some
duplicated code. This means that at least for BSD labels, we can handle
both pre and post- autodiscover kernels with the same fstab.
Replace \*[Gt] and \*[Lt] with the simple characters > and < (OK wiz)
XXX Note that the examples currently do not compile with GCC! The hex
XXX character sequences such as \x10CACHE are being parsed as longer
XXX than 2-hex-digit strings!
setting tm_gmtoff doesn't work. Instead, call mktime_z(3)
with a null timezone (so it works in UTC) and adjust the
result afterwards. Now "date -d @0" correctly
prints the local equivalent of 1970-01-01 00:00:00 UTC.
requested, which is allowed by pertinent standards, honor it instead
of bombing.
Do not do this for calloc(x, y) where x != 0 && y != 0 but x*y == 0;
in that case bomb.
http://mail-index.netbsd.org/tech-userlevel/2011/08/25/msg005404.html
This is used by disk tools such as disklabel(8) to dynamically decide is
the undelyling platform uses a disklabel-in-mbr-partition or not
(instead of using a compile-time list of ports).
getlabelusesmbr() reads the sysctl kern.labelusesmbr, takes its value from the
machdep #define LABELUSESMBR.
For evbmips, make LABELUSESMBR 1 if the platform uses pmon
as bootloader, and 0 (the previous value) otherwise.
