[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23600: 25.1.50; encode-time returns wrong result

From: Eli Zaretskii
Subject: bug#23600: 25.1.50; encode-time returns wrong result
Date: Sat, 04 Jun 2016 20:37:26 +0300

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sat, 4 Jun 2016 10:15:04 -0700
> > Do callers of putenv expect the argument to be destroyed?
> Yes and no. POSIX says that the environment can be modified in-place, so a 
> caller of putenv (S) should be prepared for *S to be modified (which is what 
> I 
> assume you mean by "destroyed") because the string will be put into the 
> environment. Also, POSIX allows putenv to modify *S, as S is of type char * 
> and 
> there is no prohibition in the standard against putenv modifying the 
> pointed-to 
> storage. That being said, I don't know of any POSIXish implementation of 
> putenv 
> (S) that modifies *S and I doubt whether any mainstream implementation would 
> do 
> that.

Right, that's what I thought.

> Although the code you mention is stretching things a bit, it's not stretching 
> them beyond recognition: the intent of putenv ("TZ=<JST>-9") is not really 
> "set 
> the 'TZ' value to the byte-string '<JST>-9' in the environment array", it's 
> more 
> "set the time zone to 9 hours ahead of UTC and with abbreviation 'JST'", and 
> on 
> MS-Windows the code implements this intent more faithfully than doing nothing 
> would.

I think it would be cleaner if we copied the string before modifying
it.  I will do that when I have time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]