chmod/chown/chgrp (probably others) in the not too far distant past,
and causes the operation to be a no-op if no actual change would be
made (avoiding updating the file's ctime for no reason).
That is, with touch, -D causes no modifying sys call to be made to
a file if that file's atime and mtime are already set to the values
that would be used. A common case for this is when a "-r ref-file"
is also a target file for the operation.
Unfortunately -d was already taken in touch, so next best available is -D.
is a symbolic link, the times to use are taken from those of the symbolic
link itself, instead of from the file it references. If the reference file
is not a symbolic link, -R and -r are identical.
This allows the BUGS entry in the manual page to be removed.
fractional seconds. (Alternate ways to achieve that for the other
ways of specifying the date and time may be forthcoming in a future
update).
Also add a warning about the (still far) future likely change of
the interpretation of 2 digit years (the coming POSIX standard
contains a similar warning).
While here, clean up wording, some macro usage, etc etc etc...
alter any of the material fields of the struct tm that was handed
to it. If any were altered, then the time string passed in was
not a valid time representation, and so should be rejected.
This one is not an invisible change, it prevents use of things like
"-t 202402300000" (which previously would have been interpreted as
"-t 202403010000" - the day after the 29th of Feb in 2024).
I believe this is an improvement however, and in line with the
general intent that if you specify a date and time, that exact
date and time is what touch should be using. It does mean that
specifying "60" for the seconds field is almost guaranteed to
fail on any POSIX system, as leap seconds simply don't exist
there (on a non-POSIX-conforming system that uses leap seconds,
the :60 should work, if specified with the correct date and time
at which the leap second actually occurs).
The one exception is when parsedate(3) is used, as that does not
do this check (which allows things like "-1 day" on the 1st of
a month to work).
(This is the last of this sequence of updates to touch.c, an
update to touch.1 follows).
Previously we have hacked that using parsedate(3) - but parsedate()
returns a time_t and consequently while it "handles" fractional seconds,
all that meant (all it really can mean) is that they're ignored.
The POSIX spec expects that (at least if the filesystem supports them)
fractional seconds can be set using the -d option.
Handle that by first attempting to parse the -d arg as a posix format
date-time string (using a reasonably strict parser), and if that fails,
then fall back on parsedate(3) to parse the arg.
If the posix format parse succeeds, the result will be the same as
parsedate(3) would return for the same string - except any fractional
seconds will be handled properly. If it fails, then nothing changes
from what we currently do.
Note the POSIX string is
YYYY-MM-DDThh:mm:ss[.frac][Z]
where YYYY is (at least) 4 digits (leading 0's are acceptable if
you really must!) all the MM DD hh mm ss fields are exactly 2
digits, T is either 'T' or ' ', '.' is either itself, or ',',
and 'frac' is one or more digits. Z (if given) is 'Z'. The
[.,]frac and Z fields are optional. Specify a time in a
slight shorthand like 2024-2-8T7:44:20 and the POSIX parse
will fail, leaving parsedate() to handle that (which it should).
But any fractional seconds which were given would be ignored.
Doc update coming - note the doc will call the YYYY field CCYY
instead, that's just a convenience to make other parts of what
is there make more sense - it is still one 4 (or more) digit field.
This should be an almost invisible change.
to make it simpler to (eventually, many years hence) to change that rule
to be "if year is < NN it is 21xx and if >= NN it is 20xx" instead.
Avoid comparing a time_t to -1 directly, as time_t might be unsigned.
Instead define NO_TIME as ((time_t)-1) and compare with that instead.
This makes no difference at all when time_t is signed (as it is on
NetBSD).
Use "ss" rather than "SS" as the seconds indicators (in messages)
to match with hh (hours) and mm (minutes) rather than looking like
some relation to YY (year) MM (month) and DD (day). Why this was
ever written as SS is beyond me, but it has been that way forever.
(doc update will follow).
Minor improvement to the error message if the arg to a -t option
is unable to be parsed correctly.
NMFCI (No meaningful...)
The toggles INCLUDES, LIBRARIES, POSIX, SYSVINCLUDE, SYSVVARSUB,
GMAKEEXPORT and SUNSHCMD are no longer needed, they were unconditionally
set.
The toggle NO_REGEX was configurable from the command line, but
disabling it would result in various error messages about the unknown
':C' modifier.
OK sjg@.
By replacing block comments with end-of-line comments, the comments take
up less space and thus no longer require to be indented by 6 spaces.
The messages and their comments are used in 3 places: the manual page
lint.7, the err-msgs.h header for debug mode, and check-msgs.lua to
verify that the comments above the message IDs correspond to the actual
messages.
No functional change.
From a user's perspective, it's irrelevant whether a lint message is
generated using '%s' or '%.*s'; same for the integer widths, as they are
platform-dependent.
Previously, the arguments of a function call expression were arranged in
a linear tree structure, from right to left. To allow easier access to
the arguments, store them in an array instead.
Previously, the ':S', ':ts', ':tA' and ':from=to' modifiers were
evaluated in parse-only mode, unnecessarily. This is only noticeable
when an indirect modifier is evaluated in parse-only mode, which is
another bug that will be fixed in a follow-up commit.
The debug output contained too many newlines.
The buffer functions were built into lint2 even though they weren't
used.
Enable the query for invisible characters in string literals, to make
sure that a newline in a string literal does not trigger that query.
The plain char literals are needed for checking printf/scanf format
strings; lint has no similar check for wide strings. These format
strings are checked by modern compilers, making this check less
relevant.
An integer constant that is signed in traditional C but unsigned since
C90 is an edge case that should not clutter the main code of determining
the resulting type of the constant.
The code for lexing an integer constant doesn't implement the C99 rules
yet, which convert a constant to the 'long long' types if the 'long'
types don't suffice.
kre