Add checks to detect overflow, and also detect other invalid
(out of range) inputs for parsedate().
There could be more, and some of what is being added is not
perfect, but many calculation overflows will be detected now
(and cause an error return) and some of the most bizarre
inputs that were previously accepted no longer will be.
In apparently rare cases the (REPE) CMPS instruction can trigger an memory
assist. NVMM wouldn't recognize the instruction and thus couldn't assist and
Qemu would abort.
not offsets (i.e. *8 to get the offset).
- Define and use SIZEOF_SIGINFO and UC_GREGS constants, rather than
hard-code magic numbers.
NFC -- same object code is generated.
before committing to it being an 8601 format date, rather than after
(or the fall back grammar parser doesn't start with a clean slate).
This isn't likely to ever bother anyone, the chances of encountering
something that looks just like an 8601 format date, but with a year
field so large it overflows a long are kind of slim. If it did happen
the chances that the string could be correctly parsed (into something
different) by the grammar are even slimmer. But better to do it properly.
ISO-8601 format yyyy-mm-ddTHH:MM:SS[radix_and+frac][Z]
be accepted.
We didn't handle that, as in parsedate(), 'T' represents the
military timezone designator, not a padding separator between
date & time as POSIX specified it.
The way parsedate() is written, fixing this in the grammar/lexer
would be hard without deleting support for T as a zone indicator
(it is *my* timezone!).
So, instead of doing that, parse an ISO-8901 string which occurs
right at the start of the input (not even any preceding white space)
by hand, before invoking the grammar, and so not involving the lexer.
This is sufficient to make touch -d conform.
After doing that, we still need to allow earlier valid inputs,
where an ISO-8601 format (using space as the separator, but without
the 'Z' (Zulu, or UTC) suffix) followed by an arbitrary timezone
designation, and other modifiers (eg: "+5 minutes" work. So we
call the grammar on whatever is left of the input after the 8601
string has been consumed. This all "just works" with one exception,
a format like "yyyy-mm-dd hh:mm:ss +0700" would have the grammar parse
just "+0700" which by itself would be meaningless, and so wasn't
handled. Add a grammar rule & processing to Handle it.
Also note that while POSIX specifies "at least 4" digits in the YYYY
field, we implement "at least one" so years from 0-999 continue to be
parsed as they always have (nb: these were, and continue to be, treated
as absolute year numbers, year 10 is year 10, not 2010). Years > 2 billion
(give or take) cannot be represented in the tm_year field of a struct tm,
so there's a limit on the max number of digits as well.
actual specific years, values from 69-99 be treated as 20th century,
and values from 0-68 be treated as 21st century. This allows for those
unfortunate enough to reside in a timezone west of Greenwich to convert
the epoch (or a time very close to it) to text, write that with just two
digits, and correctly convert it back to a time near the epoch, rather
than to something in 2069.
We used to split things so 0-69 were 21st century, and 70-99 were 20th.
Change that (this requires a change in the parsedate ATF tests which
test this specific boundary).
While here, add support for another POSIX requirement, that the radix
char before fractional seconds can be either a ',' or a '.'. We used
to allow only '.', add support for ','. This is something of a meaningless
change, as parsedate() returns a time_t in which there is no way to
represent fractional seconds, so there's little point in ever specifying
them regardless of what char is used for the "decimal point" - they will
be ignored anyway. But at least fractional seconds using a ',' as the
radix char will no longer cause the conversion to fail (or do something else
bizarre).
In OSSv4 these are supposed to avoid the wrapping problems with the
older GET(I|O)PTR ioctls but we don't quite get the same benefit here.
XXX: We could probably fake it by maintaining some state in-between calls.
One or two calls from this API were supported previously and have been
moved to the correct place.
Mapping the controls correctly is a difficult task. There is a define
hidden in the OSS headers that would allow an AUDIO_MIXER_SET control
to be represented perfectly, but it seems to _only_ exist there, and
no software supports it. So for now only one member of a set can be
set at a time - unfortunate. I've hidden code that should unlock
doing this the proper way under #notyet.
I'm not too happy with the way this code is managing file descriptors.
Currently it has to open a new fd for each ioctl due to OSSv4 deciding
to specify the device number in a structure rather than in the filename.
In the future, we could reuse the file descriptor if the correct one is
detected open.
This allows the mixer programs provided with the OSSv4 sources to compile
and work cleanly. I've observed problems with it failing to work on
secondary devices, and should investigate this later. There may be
a fd leak somewhere.
SNDCTL_DSP_COOKEDMODE simply always returns 1.
"Cooked mode" is a silly way the OSSv4 authors chose to refer to allowing
for reprocessed streams. The NetBSD kernel always performs format
conversion and it can't be turned off.
SNDCTL_DSP_GETERROR provides access to the read/write over/underrun
counters. There are other things it might return, but they don't make
sense for our implementation.
- Per OSSv4, make this ioctl work on the main mixer device.
Since the native NetBSD API uses queries on individual audio devices,
we have to reopen the correct audio device specified in the input to the
ioctl and fetch information from that.
- Correctly return whether the device is for playback, capture, or both.
- Return the full name of the device in the name field.
- The "handle" has to be a globally unique identifier. The closest thing
we have to that is device numbers, so use device numbers.
- Return reasonable values in min_rate/max_rate and min_channels/max_channels.
This should allow Mumble's device enumeration to work with a lot less
patching.
reinoud