Re: grdc: show timezone when TZ is set
> I disagree with the full-featured support of tzset() for all TZ paths. > > and, of course your private Monticello file is corrupt TZ file, which > exercises > a secret bug in the libc/time parser of the file, and you rely upon it to take > over control of this program, and other programs. > > > I despise this "feature". It basically says that tzset() requires full > filesystem access during the whole program lifetime. I agree. Anyone who's not actually developing time zone files should be plenty happy using what exists, or at worst lobbying a sysadmin to add a TZ file to /usr/share/zoneinfo. I think this feature exists only for historical developer convenience. Otherwise it's just exposure surface. My issues with the time system are (a) it has to "just work", so it flees to UTC the instant something goes wrong, but never makes available any status as to whether the asked-for time zone is the one returned, except for (b) my program aborts if I'm pledged and I go do something silly with the TZ. If the answer to (b) is "don't do silly things", I can live with that, although in that case I'd think the best answer would be to "just work" and default to UTC like everything else, rather than aborting -- just like our setugid() programs do (grdc is now, interestingly, a program that aborts on localtime() if TZ is outside zoneinfo... unless you make grdc setgid first, then it works). Sadly I can't promise I'll stop doing silly things. But I have no issue breaking with tradition, revising the documentation, and insisting that valid TZs are only relative paths inside zoneinfo. For (a), the issue is that I don't think grdc should display $TZ if TZ is an invalid timezone or at least not the timezone being used. Sadly, grdc has no easy way of telling. If only there were some API to tell. Further with grdc, I'd really like it if the string being displayed were not necessarily all of $TZ, but limited to up to the last characters (the end of the time zone string being more interesting than the start), for n on the order of 40. Paul Janzen.
Re: grdc: show timezone when TZ is set
The recent change to grdc(6), to display additional information if TZ is
set, has a few issues.
1. Time zone offset incorrectly reported in Newfoundland.
Some time zones have offsets of 30 or 45 minutes. The displayed time
offset is currently truncated to the closest hour. (Australia/Eucla
is a fun time zone too.)
2. The new, additional information disappears if the window is sized too
small (wintoosmall). There's basically room for it though... except
3. The TZ information is a string of unknown length, and so it doesn't
necessarily display correctly.
Yeah, I know with pledge() you can't do testing like
TZ=:/home/pjanzen/dev/usr/share/zoneinfo/testing/2022/America/Kentucky/Monticello
any more, even though that's a perfectly cromulent and functional TZ on my
system otherwise. So for the time being, probably any TZ that exists and
doesn't abort grdc is 38 bytes or shorter. Which works.
But, if your timezone exists, it already has its name in short form
included in tm->tm_zone. That's what I think should be
printed, even if "EDT" is way less cool than "America/Pangnirtung". I
mean, if the point is just to be able to label clocks with nice places,
instead of the time zone it's showing, maybe it could be a different option.
Counterpoint: some of the timezones have short names that are just the UTC
offset, which is really boring and duplicated given that we print out the
offset already. Hey, maybe we could just print the offset...
4. There's no indication if you type an invalid TZ--you get UTC and a
misleading label onscreen.
Timezone handling defaults to UTC if anything breaks along the chain, as
the tzset(3) man page makes clear. That means if you misspell Antarctica
while setting your TZ=Antartica/McMurdo, you'll end up half a day off from
all your pals at McMurdo as your screen happily tells you that you're
seeing McMurdo +0 time.
There's no simple way to tell if your $TZ is valid or not (if you get back
UTC, maybe that's really what it should be!). At least if we display
tm->tm_zone rather than $TZ, we're not misleading.
I was going to be upset that the man page for grdc(6) is way pickier on TZ
than tzset(3), but it's quite accurate given the pledge() call. Speaking
of which, I don't expect any one else plays with timezone files, and surely
one doesn't want one's general utilities to be pwned by possible bugs in
the time-handling code exploited with custom files created outside
/usr/share/zoneinfo. But it's still a touch irritating-should-be-fixable
that, because the pledge() has to be after initscr(), grdc has the
possibility of leaving the terminal in the wrong state when it aborts on
test TZ files.
Paul Janzen.
Index: grdc.c
===
RCS file: /cvs/src/games/grdc/grdc.c,v
retrieving revision 1.35
diff -u -p -r1.35 grdc.c
--- grdc.c 17 Sep 2022 10:32:05 - 1.35
+++ grdc.c 18 Sep 2022 05:30:04 -
@@ -41,6 +41,7 @@ volatile sig_atomic_t sigwinched = 0;
int hascolor = 0;
+void print_tz(int, int, int);
void getwinsize(int *, int *);
void set(int, int);
void standt(int);
@@ -184,11 +185,8 @@ main(int argc, char *argv[])
move(ybase, xbase + XLENGTH);
vline(ACS_VLINE, YDEPTH);
- if (tz != NULL) {
- move(ybase - 1, xbase);
- printw("[ %s %+d ]", tz,
- tm->tm_gmtoff / 60 / 60 );
- }
+ if (tz)
+ print_tz(ybase - 1, xbase, wintoosmall);
attrset(COLOR_PAIR(2));
}
@@ -199,6 +197,8 @@ main(int argc, char *argv[])
move(0, 0);
printw("%02d:%02d:%02d", tm->tm_hour, tm->tm_min,
tm->tm_sec);
+ if (tz)
+ print_tz(1, 0, wintoosmall);
} else for (k = 0; k < 6; k++) {
if (scrol) {
for(i = 0; i < 5; i++)
@@ -282,6 +282,22 @@ set(int t, int n)
}
if (mask & m)
mask |= m;
+}
+
+void
+print_tz(int y, int x, int sml)
+{
+ int i, j;
+
+ move(y, x);
+ i = tm->tm_gmtoff / 60 / 60;
+ j = tm->tm_gmtoff / 60 - i * 60;
+ if (i < 0)
+ j = -j;
+ if (!sml)
+ printw("[ %s %+dh%02d ]", tm->tm_zone, i, j);
+ else
+ printw("[%+dh%02d]", i, j);
}
void
Re: Copy/paste fix in phantasia(6)
My error from 1998. Your diff is correct.
Paul Janzen.
On Wed, 28 Apr 2021, trondd wrote:
> Looks like we picked up some extra loopty loops during an update from
> NetBSD back in 1998.
>
> I sanity checked against NetBSD to make sure this matches their
> source.
>
> Tim.
>
>
> Index: io.c
> ===
> RCS file: /cvs/src/games/phantasia/io.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 io.c
> --- io.c 10 Jan 2016 13:35:09 - 1.9
> +++ io.c 29 Apr 2021 00:20:18 -
> @@ -324,7 +324,6 @@ getanswer(char *choices, bool def)
> alarm(0); /* make sure alarm is off */
>
> for (loop = 3; loop; --loop)
> - for (loop = 3; loop; --loop)
> /* try for 3 times */
> {
> if (setjmp(Timeoenv) != 0)
>
Re: [patch] vis(3): NUL terminate -> NUL-terminate
The C standard says nothing at all about nul or NUL. '\0' is called the null character. [Basically, the C standard is written in English and uses English words to describe things.] A2.5.2 of my copy of K&R 2nd ed mentions the character NUL. The rest of the book, I guess, has to be EBCDIC-tolerant and just talks of the null character. Our man pages tend (and I used to encourage) using NUL-terminated as a short form of null-character-terminated, which is probably the most pedantic and correct way to say things. And actually, in the original diff, I think some of the sentences in question weren't even describing NUL-terminated strings, but pointing out that the function in question would ensure the presence of a terminating NUL... I doubt changing things is worth the bother, but using Amen. Paul Janzen.
Re: [patch] vis(3): NUL terminate -> NUL-terminate
On Fri, Apr 23, 2010 at 06:53:41PM +0200, Joachim Schipper wrote:
I noticed that vis(3) talks about "NUL terminated" strings, whereas
almost other sources (including e.g. strlcat(3), strtok(3), strpbrk(3))
talk about "NUL-terminated" strings (i.e. with a hyphen.)
The following patch fixes this.
Joachim
quite a few pages talk about "nul terminate". let's try and be
consistent - if there's a good reason, we can change them all. is there
a good reason? i don;t know, because i always get lost on the idea of
nul and null ;(
As one person who might possibly care, barely:
NUL is an ASCII character, '\0', used to indicate the end of a
standard C string.
null is an English word, and a null pointer doesn't point to an ASCII
NUL.
compound adjectives like "NUL terminated" get hyphenated before a
noun ("a NUL-terminated string") but not after a verb (e.g., "string foo
is NUL terminated"), according to at least many style guides.
Paul Janzen.
