From: Paul Eggert <eggert@cs.ucla.edu>
To: Wolfgang Jenkner <wjenkner@inode.at>
Cc: 19874@debbugs.gnu.org, Ashish SHUKLA <ashish.is@lostca.se>
Subject: bug#19874: 25.0.50; encode-time not working as expected
Date: Fri, 27 Feb 2015 15:54:01 -0800 [thread overview]
Message-ID: <54F10399.8010207@cs.ucla.edu> (raw)
In-Reply-To: <8561an5k8q.fsf@iznogoud.viz>
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]
On 02/27/2015 09:33 AM, Wolfgang Jenkner wrote:
> IIUC, the standard explicitly permits the FreeBSD behaviour, so the
> program above does not seem to be conforming:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html
>
> If the application switches to a complete new environment by
> assigning a new value to environ, this can be detected by
> getenv(), setenv(), unsetenv(), or putenv() and the
> implementation can at that point reinitialize based on the new
> environment. (This may include copying the environment strings
> into a new array and assigning environ to point to it.)
No, because that part of the rationale is not talking about the buggy FreeBSD
behavior. Although the test program does assign a new value to environ, that's
not a problem because everything still works: 'setenv' reinitializes based on
the new environment, as it's allowed to do. The problem doesn't occur until
after the assignment "env1[0] = 'x'", and this is a different matter.
As the getenv rationale points out, "conforming applications are required not to
directly modify the pointers to which /environ/ points", and it appears that's
the restriction you're thinking about. However, the test program obeys this
restriction. Although the restriction applies to environ[0], environ[1], etc.,
it does not apply to environ[0][0], environ[0][1], etc. Programs are allowed to
change the char objects in environ strings that they supply (either via putenv,
or directly by switching to a complete new environment), and Emacs relies on
this, as does the test program.
The reason Emacs relies on this, by the way, is that Emacs requires a
thread-safe way to set the TZ environment variable without dumping core if
different threads invoke 'setenv' and/or 'unsetenv' and/or 'putenv' at about the
same time. This was a real problem in Emacs before it started using the current
approach of modifying the environment's TZ value in-place (or zapping its name
to unset TZ). Please see:
http://bugs.gnu.org/8705
[-- Attachment #2: Type: text/html, Size: 2688 bytes --]
next prev parent reply other threads:[~2015-02-27 23:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-15 13:40 bug#19874: 25.0.50; encode-time not working as expected Ashish SHUKLA
2015-02-15 23:33 ` Ashish SHUKLA
2015-02-25 17:41 ` Paul Eggert
2015-02-26 0:24 ` Ashish SHUKLA
2015-02-26 8:15 ` Paul Eggert
2015-02-26 13:42 ` Wolfgang Jenkner
2015-02-26 17:36 ` Wolfgang Jenkner
2015-02-26 17:58 ` Paul Eggert
2015-02-26 16:03 ` Ashish SHUKLA
2015-02-26 6:51 ` Ashish SHUKLA
2015-02-26 8:39 ` Paul Eggert
2015-02-26 15:58 ` Ashish SHUKLA
2015-02-27 5:13 ` Paul Eggert
2015-02-26 19:00 ` Wolfgang Jenkner
2015-02-26 19:44 ` Ashish SHUKLA
2015-02-26 20:05 ` Wolfgang Jenkner
2015-02-26 21:47 ` Ashish SHUKLA
2015-02-27 0:16 ` Wolfgang Jenkner
2015-02-27 2:51 ` Wolfgang Jenkner
2015-02-27 4:59 ` Ashish SHUKLA
2015-02-27 6:38 ` Paul Eggert
2015-02-27 8:09 ` Paul Eggert
2015-02-27 8:49 ` Ashish SHUKLA
2015-02-27 6:31 ` Paul Eggert
2015-02-27 8:28 ` Ashish SHUKLA
2015-02-27 16:41 ` Paul Eggert
2015-02-27 17:33 ` Wolfgang Jenkner
2015-02-27 23:54 ` Paul Eggert [this message]
2015-02-28 14:10 ` Wolfgang Jenkner
2015-02-28 14:18 ` Wolfgang Jenkner
2015-02-28 19:43 ` Paul Eggert
2015-03-01 16:42 ` Wolfgang Jenkner
2015-03-01 18:28 ` Paul Eggert
2015-03-01 22:49 ` Wolfgang Jenkner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F10399.8010207@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=19874@debbugs.gnu.org \
--cc=ashish.is@lostca.se \
--cc=wjenkner@inode.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).