bug#30738: Invalid timezone (tzalloc failure) treated as out-of-memory

[Valery Ushakov <uwe@stderr.spb.ru>]

On Sun, Mar 11, 2018 at 00:33:03 -0800, Paul Eggert wrote:

> Thanks for reporting the problem.  I have installed the attached two
> patches, which I think should fix the problem so I'm closing the bug
> report.  Please give them a try on NetBSD (as I typically don't use
> NetBSD).

Thank you for your prompt response.  This helps but only partially.

Now emacs doesn't freak out with a scary message when tzalloc()
returns NULL, but tzlookup() still calls tzalloc("XXXhh:mm:ss") for
integer "zone".  Unfortunately, as I mentioned in the original
submission, tzcode in NetBSD-6 doesn't grok that (support for that
appeared in tzcode only around 2014 I think), so each time you open a
file under CVS control you get the "Invalid time zone" error.

Perhaps in the long term configure should try to detect if host's
tzalloc() understands that kind of direct timezone specification.

However in the case of CVS the offending zone value is zero that comes
from parsed-time-string, so the following quick hack can be used

--- editfns.c.dist	2017-04-14 18:02:47.000000000 +0300
+++ editfns.c	2018-03-12 21:46:58.000000000 +0300
@@ -153,7 +147,8 @@
 
   if (NILP (zone))
     return local_tz;
-  else if (EQ (zone, Qt))
+  else if (EQ (zone, Qt)
+	   || (INTEGERP (zone) && XINT (zone) == 0))
     {
       zone_string = "UTC0";
       new_tz = utc_tz;

I don't know if CVS always uses UTC or it's just because the CVS repos
I work with all use UTC as an adminsitrative decision.  Though I guess
it can be argued that special-casing zone 0 like that to return utc_tz
is the right thing to do regardless.

Thanks.

-uwe