Rob Landley
2014-05-22 12:26:43 UTC
So I'm implementing a fresh set of posix commands
(http://landley.net/toybox/roadmap.html) and everything does nanoseconds
these days, and the gnu/dammit version has %N in the date format... but
they didn't extend strptime(). (Because why would you do a generic
solution when you can hack in a special case if you're the FSF?)
The fundamental problem seems to be there isn't a nanoseconds field in
struct tm. It's easy enough to append one, but if you then appended
something else in a future version it would break.
Just thought I'd mention it. I keep hitting fun little things like
wanting to make tr support UTF-8 but there's no way to get a count or
list of of isspace() or isalpha() entries for things like:
echo "one two three" | tr [:space:][:alpha:] abcdefghijklmnopqrstuvwxyz
zzzfzzzfzzzzz
Or the way Linux started using cpio heavily about the time you removed
it from the standard (it's the basis of RPM and initramfs) but _they_
use the version extended to 8 hex digits instead of 6 (which is still a
32 bit time_t but it's unsigned so won't blow up for most of a
century... Then again, you standardized "pax" which nobody uses, but not
"tar" which everybody does, so what posix has to say about archivers is
sort of a moot point really.)
And what _does_ happen to getline()'s lineptr field when you feed it
NULL requesting it allocate memory, but the read fails? Does it
reliably stay NULL or does it return a memory allocation you need to
free even in the failure case? (In theory it could even change the
pointer but free the memory itself so you DON'T free it for failure. I'd
say "no libc author is that sloppy" but dietlibc exists. Then again, I
don't care about supporting dietlibc...)
Rob
(Oh, speaking of date: I'm implementing 50 years back/forward from today
for 2 digit years, not from some magic date. I'm aware this is a
deviation from the standard, and am documenting it as such, but the
standard itself says it's going to change, so...)
(http://landley.net/toybox/roadmap.html) and everything does nanoseconds
these days, and the gnu/dammit version has %N in the date format... but
they didn't extend strptime(). (Because why would you do a generic
solution when you can hack in a special case if you're the FSF?)
The fundamental problem seems to be there isn't a nanoseconds field in
struct tm. It's easy enough to append one, but if you then appended
something else in a future version it would break.
Just thought I'd mention it. I keep hitting fun little things like
wanting to make tr support UTF-8 but there's no way to get a count or
list of of isspace() or isalpha() entries for things like:
echo "one two three" | tr [:space:][:alpha:] abcdefghijklmnopqrstuvwxyz
zzzfzzzfzzzzz
Or the way Linux started using cpio heavily about the time you removed
it from the standard (it's the basis of RPM and initramfs) but _they_
use the version extended to 8 hex digits instead of 6 (which is still a
32 bit time_t but it's unsigned so won't blow up for most of a
century... Then again, you standardized "pax" which nobody uses, but not
"tar" which everybody does, so what posix has to say about archivers is
sort of a moot point really.)
And what _does_ happen to getline()'s lineptr field when you feed it
NULL requesting it allocate memory, but the read fails? Does it
reliably stay NULL or does it return a memory allocation you need to
free even in the failure case? (In theory it could even change the
pointer but free the memory itself so you DON'T free it for failure. I'd
say "no libc author is that sloppy" but dietlibc exists. Then again, I
don't care about supporting dietlibc...)
Rob
(Oh, speaking of date: I'm implementing 50 years back/forward from today
for 2 digit years, not from some magic date. I'm aware this is a
deviation from the standard, and am documenting it as such, but the
standard itself says it's going to change, so...)