bug#19874: 25.0.50; encode-time not working as expected

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 8585 bytes --]


I'm running FreeBSD 10.1 (amd64). My /etc/localtime points to "Asia/Kolkata"
(Indian Standard Time, UTC+0530) timezone.

For "Date: Sun, 15 Feb 2015 06:42:44 +0000 (UTC)":

#v+
(encode-time 44 42 6 15 2 2015 0 nil 0)
=> (21727 62092) = 1423962764
#v-

#v+
>>> print gmtime(1423962764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=1, tm_min=12, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print localtime(1423962764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=6, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
#v-

If it was "Date: Sun, 15 Feb 2015 06:42:44 +0530":

#v+
(encode-time 44 42 6 15 2 2015 0 nil 19800)
=> (21727 62092)
#v-

The expected output for the time specified in UTC should be:
(21728 16356) = 1423982564

#v+
>>> print gmtime(1423982564)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=6, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print localtime(1423982564)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=12, tm_min=12, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
#v-

I've come across while trying to figure out cause for a bug[1] report while
ago.



In GNU Emacs 25.0.50.1 (amd64-portbld-freebsd10.1, GTK+ Version 3.14.7)
 of 2015-02-06 on chateau.d.if
Windowing system distributor `The X.Org Foundation', version 11.0.11407000
Configured using:
 `configure --localstatedir=/var --without-compress-install --with-dbus
 --with-file-notification=gfile --with-gconf --with-gif --with-gnutls
 --with-gsettings --with-jpeg --with-m17n-flt --with-imagemagick --with-libotf
 --with-png --with-toolkit-scroll-bars --with-rsvg --with-tiff --with-x
 --with-xft --with-xim --with-xml2 --with-xpm --with-x-toolkit=gtk3
 --with-sound=alsa --x-libraries=/usr/local/lib
 --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man
 --infodir=/usr/local/share/emacs/info/ --build=amd64-portbld-freebsd10.1
 'CFLAGS=-O2 -g -march=corei7 -fstack-protector -fno-strict-aliasing'
 CPPFLAGS=-I/usr/local/include 'LDFLAGS= -L/usr/local/lib
 -Wl,-rpath=/usr/local/lib -ltinfo -fstack-protector''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY ACL
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=scim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  paredit-mode: t
  shell-dirtrack-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  delete-selection-mode: t
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent messages:
Mark set [4 times]
(21727 62092)
Mark saved where search started
Quit
Mark saved where search started [3 times]
 [2 times]
Mark saved where search started [3 times]
Mark set [3 times]
delete-backward-char: Text is read-only
Making completion list...

Load-path shadows:
/home/abbe/.emacs.d/elisp/sx.el/sx hides /home/abbe/.emacs.d/elisp/sx
/home/abbe/.emacs.d/elisp/apel/env hides /usr/local/share/emacs/25.0.50/lisp/env
/home/abbe/.emacs.d/elisp/apel/timezone hides /usr/local/share/emacs/25.0.50/lisp/timezone
/home/abbe/.emacs.d/elisp/emms/lisp/tq hides /usr/local/share/emacs/25.0.50/lisp/emacs-lisp/tq

Features:
(shadow flyspell ispell hashcash footnote nnir emacsbug sendmail quail debug
edebug misearch multi-isearch eieio-opt help-mode compface gnus-fun mm-archive
qp sort smiley gnus-cite gnus-async gnus-bcklg gnus-ml disp-table gnus-topic
utf-7 nndraft nnmh nnmaildir network-stream nsm starttls bbdb-gnus bbdb-snarf
mail-extr nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
gnus-cache epa-file epa epg spam spam-stat bbdb-com warnings bbdb gnus-uu yenc
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig mm-url
nnmairix nnml gnus-sum gnus-group gnus-undo supercite regi gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec
gnus-int gnus-range message idna rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader
mail-utils server paredit sx-load sx-tab sx-switchto sx-search sx-notify
sx-interaction sx-inbox sx-question-list sx-question-mode sx-question-print
sx-user sx-favorites sx-networks sx-site sx-compose sx-tag markdown-mode
sx-babel sx-button sx-question sx-method sx-filter sx-auth sx-cache sx-request
sx-encoding json sx-time sx let-alist helm-config helm-autoloads
async-bytecomp async helm-aliases bison-mode cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs gtags quack
cmuscheme scheme tango-dark-theme caml tuareg_indent tuareg speedbar sb-image
ezimage dframe smie coffee-mode cider tramp-sh cider-mode cider-repl
cider-eldoc cider-interaction cider-doc org-table cider-test cider-stacktrace
cider-client nrepl-client queue cider-util ewoc dash emms-player-mpd tq
emms-cache emms-info-ogginfo emms-info-mp3info emms-info later-do
emms-playlist-mode emms-player-vlc emms-player-mplayer emms-player-simple
emms-source-playlist emms-source-file emms-setup emms emms-compat tramp
tramp-compat tramp-loaddefs trampver shell blog metaweblog xml-rpc timezone
pym static apel-ver product url-http tls url url-proxy url-privacy url-expand
url-methods url-history mailcap url-auth mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-cookie url-domsuf url-util url-parse auth-source gnus-util
mm-util mail-prsvr password-cache url-gw url-vars xml muse-html
muse-xml-common cus-edit cus-start cus-load muse-publish muse-project
muse-protocols info muse-regexps wid-edit muse muse-nested-tags muse-mode
org-agenda org org-macro org-footnote org-pcomplete pcomplete org-list
org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs
auto-complete-config auto-complete popup slime-fancy slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree slime-scratch slime-presentations bridge slime-fuzzy
slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands
slime-autodoc slime-repl elp slime-parse slime gud apropos compile etags xref
eieio byte-opt bytecomp byte-compile cl-extra seq cconv eieio-core cl-generic
pcase arc-mode archive-mode noutline outline easy-mmode pp comint ansi-color
ring hyperspec thingatpt browse-url slime-autoloads clojure-mode rx derived
edmacro kmacro easymenu imenu scim-bridge mule-util elscreen advice help-fns
dired iswitchb bbdb-autoloads w3m-load erlang-start boxquote cl-macs rect cl
gv cl-loaddefs cl-lib delsel time paren time-date tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese case-table
epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty
emacs)

Memory information:
((conses 16 789746 115688)
 (symbols 48 110602 0)
 (miscs 40 1234 2274)
 (strings 32 284138 30822)
 (string-bytes 1 15430510)
 (vectors 16 99528)
 (vector-slots 8 1286063 42005)
 (floats 8 509 1071)
 (intervals 56 8699 446)
 (buffers 976 41))

References:
[1]  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18899


Please let me know if you need more information.

Thanks!
-- 
Ashish SHUKLA

“It now costs more to amuse a child than it once did to educate his father.”

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Forgot to mention, the revision I'm running. I'm running "5c9ad35f" of git
master.

Thanks!
-- 
Ashish SHUKLA

“Only one thing is impossible for God: To find any sense in any copyright law on
the planet.” (Mark Twain)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Thanks for the bug report.  My guess is that there's an incompatibility with 
FreeBSD 10.1 amd64 mktime.  I can't reproduce the problem on FreeBSD 9.1 x86.

Please try the attached patch, just for debugging, and then run the following 
one-line shell command:

src/emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print 
(encode-time 44 42 6 15 2 2015 0 nil 0)))'

What output do you get?  Here's what I get on Fedora 21 x86-64, which seems correct:

oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 
06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423982564

Assuming you get different output, can you debug Emacs with GDB to send us more 
details about what's going wrong?  If not, can you give me access to a FreeBSD 
10.1 amd64 machine like yours?

[-- Attachment #2: debug-encode-time.patch --]
[-- Type: text/x-patch, Size: 1024 bytes --]

diff --git a/src/editfns.c b/src/editfns.c
index dbcb316..fca95d5 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -1423,10 +1423,28 @@ mktime_z (timezone_t tz, struct tm *tm)
       oldtz = strcpy (oldtzcopy, oldtz);
     }
   block_input ();
+  char const *oldTZ = getenv ("TZ");
+  if (oldTZ)
+    oldTZ = xstrdup (oldTZ);
   set_time_zone_rule (tz);
+  char const *TZ = getenv ("TZ");
+  fprintf (stderr,
+	   ("oldtz=%s tz=%s oldTZ=%s TZ=%s "
+	    "%.4d-%.2d-%.2d %.2d:%.2d:%.2d %d -> "),
+	   oldtz ? oldtz : "(null)",
+	   tz ? tz : "(null)",
+	   oldTZ ? oldTZ : "(null)",
+	   TZ ? TZ : "(null)",
+	   tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
+	   tm->tm_hour, tm->tm_min, tm->tm_sec,
+	   tm->tm_isdst);
   time_t t = mktime (tm);
   set_time_zone_rule (oldtz);
   unblock_input ();
+  fprintf (stderr, "%.4d-%.2d-%.2d %.2d:%.2d:%.2d %d = %ld",
+	   tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
+	   tm->tm_hour, tm->tm_min, tm->tm_sec,
+	   tm->tm_isdst, (long) t);
   SAFE_FREE ();
   return t;
 }

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1.1: Type: text/plain, Size: 2874 bytes --]

On Wed, 25 Feb 2015 09:41:45 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Thanks for the bug report.  My guess is that there's an
| incompatibility with FreeBSD 10.1 amd64 mktime.  I can't reproduce the
| problem on FreeBSD 9.1 x86.

| Please try the attached patch, just for debugging, and then run the
| following one-line shell command:

| src/emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print
| (encode-time 44 42 6 15 2 2015 0 nil 0)))'

| What output do you get?  Here's what I get on Fedora 21 x86-64, which seems correct:

| oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00
| 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423982564

| Assuming you get different output, can you debug Emacs with GDB to
| send us more details about what's going wrong?  If not, can you give
| me access to a FreeBSD 10.1 amd64 machine like yours?

Hi,

When I looked into this before filing this bug report, from what I noticed
that it's not using libc's `mktime' function, unlike what you seem to
indicate. I'm not sure quite why it's doing that when libc provided mktime
works just fine, as evident by output of attached program:

--8<---------------cut here---------------start------------->8---
% ./gmtime
Staying at localtime zone
Time (in seconds): 1423962764
Updated environment
Switching to UTC
Time (in seconds): 1423982564
Didn't update environment
Switching to UTC+1
Time (in seconds): 1423978964
Didn't update environment
Switching to UTC+3
Time (in seconds): 1423971764
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
>>> print gmtime(1423962764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=1, tm_min=12, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423982564)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=6, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423978964)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=5, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
>>> print gmtime(1423971764)
time.struct_time(tm_year=2015, tm_mon=2, tm_mday=15, tm_hour=3, tm_min=42, tm_sec=44, tm_wday=6, tm_yday=46, tm_isdst=0)
--8<---------------cut here---------------end--------------->8---

The built-in mktime implementation (__mktime_internal) in Emacs sources don't
seem to take into account timezone offsets. I might be completely wrong here,
but the code seemed to be doing it.

I'll get back to you with the output of your command-line from patched Emacs
in few, but the results of my past investigation were handy so I've attached
them.

HTH
-- 
Ashish SHUKLA

“"Intellectual Property" is nowhere near as valuable as "Intellect"” ("Ion-Mihai Tetcu")

Sent from my Emacs

[-- Attachment #1.2: gmtime.c --]
[-- Type: text/plain, Size: 1141 bytes --]

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define BUFSIZE 256

void
settz(const char* tz)
{
	static char *tzvalbuf;
	static size_t tzvalbufsize;

	if( tzvalbufsize <= 3 + strlen(tz)) {
		tzvalbuf = malloc(tzvalbufsize = BUFSIZE);
		snprintf( tzvalbuf, BUFSIZE, "TZ=%s", tz );
		putenv( tzvalbuf );
		puts( "Updated environment" );
	} else {
		puts( "Didn't update environment" );
		snprintf( tzvalbuf, BUFSIZE, "TZ=%s", tz );
	}
	tzset();
}

int
main()
{
	struct tm t = {
		.tm_sec = 44,
		.tm_min = 42,
		.tm_hour = 6,
		.tm_mday = 15,
		.tm_mon = 2 - 1,
		.tm_year = 2015 - 1900,
		.tm_isdst = -1,
	};
	time_t val;

	puts( "Staying at localtime zone" );
	val = mktime( &t );
	printf( "Time (in seconds): %ld\n", val );
	settz( "TZ=XXX-0:00:00" );
	puts( "Switching to UTC" );
	val = mktime( &t );
	printf( "Time (in seconds): %ld\n", val );
	settz( "TZ=XXX-1:00:00" );
	puts( "Switching to UTC+1" );
	val = mktime( &t );
	printf( "Time (in seconds): %ld\n", val );
	settz( "TZ=XXX-3:00:00" );
	puts( "Switching to UTC+3" );
	val = mktime( &t );
	printf( "Time (in seconds): %ld\n", val );

	return 0;
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 8908 bytes --]

On Wed, 25 Feb 2015 09:41:45 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Thanks for the bug report.  My guess is that there's an
| incompatibility with FreeBSD 10.1 amd64 mktime.  I can't reproduce the
| problem on FreeBSD 9.1 x86.

| Please try the attached patch, just for debugging, and then run the
| following one-line shell command:

| src/emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print
| (encode-time 44 42 6 15 2 2015 0 nil 0)))'

| What output do you get?  Here's what I get on Fedora 21 x86-64, which seems correct:

| oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00
| 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423982564

Tried, and following is what I get:

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423982564
(21728 16356)
--8<---------------cut here---------------end--------------->8---


Since I noticed that your code doesn't do any changes, rather just prints
some intermediate information, so I did this in X11 window (note the absence
of '-batch' option)

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
oldtz=(null) tz=XXX-0:00:00 oldTZ=(null) TZ=(null) 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423962764
--8<---------------cut here---------------end--------------->8---

in minibuffer in X11 window, "(21727 62092)" message was printed. I explicitly
eval-ed Emacs Lisp code in *scratch* buffer, and got same output as mentioned
above.

Ran "emacs -batch ...." under gdb, with breaking on `getenv' after `Fencode_time':

--8<---------------cut here---------------start------------->8---
Breakpoint 5, 0x00000008084beab4 in getenv () from /lib/libc.so.7
(gdb) bt
#0  0x00000008084beab4 in getenv () from /lib/libc.so.7
#1  0x0000000000677fa8 in emacs_mktime_z (tz=0x1385fd8 "XXX-0:00:00", tm=0x7fffffffb140) at editfns.c:1404
#2  0x0000000000679f6a in Fencode_time (nargs=9, args=0x7fffffffb1a0) at editfns.c:2150
#3  0x000000000068ac60 in eval_sub (form=18361299) at eval.c:2154
#4  0x000000000068ad06 in eval_sub (form=18361523) at eval.c:2167
#5  0x000000000068b4b6 in Fprogn (body=18360931) at eval.c:445
#6  0x000000000068aa06 in eval_sub (form=18361811) at eval.c:2131
#7  0x000000000068fb66 in Feval (form=18361811, lexical=0) at eval.c:1996
#8  0x0000000000690a7d in Ffuncall (nargs=2, args=0x7fffffffba78) at eval.c:2721
#9  0x00000000006f3114 in exec_byte_code (bytestr=11659316, vector=11659349, maxdepth=94, args_template=1030, nargs=1, args=0x7fffffffc458) at bytecode.c:919
#10 0x0000000000691aba in funcall_lambda (fun=11659269, nargs=1, arg_vector=0x7fffffffc450) at eval.c:2885
#11 0x0000000000690c6e in Ffuncall (nargs=2, args=0x7fffffffc448) at eval.c:2767
#12 0x00000000006f3114 in exec_byte_code (bytestr=11636164, vector=11636197, maxdepth=74, args_template=2, nargs=0, args=0x7fffffffce78) at bytecode.c:919
#13 0x0000000000691aba in funcall_lambda (fun=11636117, nargs=0, arg_vector=0x7fffffffce78) at eval.c:2885
#14 0x0000000000690c6e in Ffuncall (nargs=1, args=0x7fffffffce70) at eval.c:2767
#15 0x00000000006f3114 in exec_byte_code (bytestr=11633180, vector=11633213, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd730) at bytecode.c:919
#16 0x0000000000691aba in funcall_lambda (fun=11633133, nargs=0, arg_vector=0x7fffffffd730) at eval.c:2885
#17 0x000000000068ff01 in apply_lambda (fun=11633133, args=0, count=3) at eval.c:2826
#18 0x000000000068afdf in eval_sub (form=18458531) at eval.c:2226
#19 0x000000000068fb66 in Feval (form=18458531, lexical=0) at eval.c:1996
#20 0x00000000005cff4a in top_level_2 () at keyboard.c:1148
#21 0x000000000068e3d1 in internal_condition_case (bfun=0x5cff20 <top_level_2>, handlers=19488, hfun=0x5cff50 <cmd_error>) at eval.c:1348
#22 0x00000000005cfeb3 in top_level_1 (ignore=0) at keyboard.c:1156
#23 0x000000000068d981 in internal_catch (tag=46224, func=0x5cfe60 <top_level_1>, arg=0) at eval.c:1108
#24 0x00000000005b1190 in command_loop () at keyboard.c:1117
#25 0x00000000005b0fe1 in recursive_edit_1 () at keyboard.c:728
#26 0x00000000005b138a in Frecursive_edit () at keyboard.c:799
#27 0x00000000005aeda1 in main (argc=5, argv=0x7fffffffde88) at emacs.c:1607

Lisp Backtrace:
"encode-time" (0xffffb1a0)
"print" (0xffffb5e8)
"progn" (0xffffb848)
"eval" (0xffffba80)
"command-line-1" (0xffffc450)
"command-line" (0xffffce78)
"normal-top-level" (0xffffd730)
(gdb) next
Single stepping until exit from function getenv,
which has no line number information.
emacs_mktime_z (tz=0x1385fd8 "XXX-0:00:00", tm=0x7fffffffb140) at editfns.c:1405
1405      USE_SAFE_ALLOCA;
(gdb) list
1400    #ifndef HAVE_TZALLOC
1401    time_t
1402    mktime_z (timezone_t tz, struct tm *tm)
1403    {
1404      char *oldtz = getenv ("TZ");
1405      USE_SAFE_ALLOCA;
1406      if (oldtz)
1407        {
1408          size_t oldtzsize = strlen (oldtz) + 1;
1409          char *oldtzcopy = SAFE_ALLOCA (oldtzsize);
(gdb) print oldtz
$1 = 0x1364783 "Asia/Kolkata"
--8<---------------cut here---------------end--------------->8---

And with gdb-ing in non -batch mode, got this instead:

--8<---------------cut here---------------start------------->8---
Breakpoint 4, 0x00000008084beab4 in getenv () from /lib/libc.so.7
(gdb) bt
#0  0x00000008084beab4 in getenv () from /lib/libc.so.7
#1  0x0000000000677fa8 in emacs_mktime_z (tz=0x1d16ae8 "XXX-0:00:00", tm=0x7fffffffb150) at editfns.c:1404
#2  0x0000000000679f6a in Fencode_time (nargs=9, args=0x7fffffffb1b0) at editfns.c:2150
#3  0x000000000068ac60 in eval_sub (form=30524771) at eval.c:2154
#4  0x000000000068ad06 in eval_sub (form=30524755) at eval.c:2167
#5  0x000000000068b4b6 in Fprogn (body=30524947) at eval.c:445
#6  0x000000000068aa06 in eval_sub (form=30524675) at eval.c:2131
#7  0x000000000068fb66 in Feval (form=30524675, lexical=0) at eval.c:1996
#8  0x0000000000690a7d in Ffuncall (nargs=2, args=0x7fffffffba88) at eval.c:2721
#9  0x00000000006f3114 in exec_byte_code (bytestr=11659316, vector=11659349, maxdepth=94, args_template=1030, nargs=1, args=0x7fffffffc468) at bytecode.c:919
#10 0x0000000000691aba in funcall_lambda (fun=11659269, nargs=1, arg_vector=0x7fffffffc460) at eval.c:2885
#11 0x0000000000690c6e in Ffuncall (nargs=2, args=0x7fffffffc458) at eval.c:2767
#12 0x00000000006f3114 in exec_byte_code (bytestr=11636164, vector=11636197, maxdepth=74, args_template=2, nargs=0, args=0x7fffffffce88) at bytecode.c:919
#13 0x0000000000691aba in funcall_lambda (fun=11636117, nargs=0, arg_vector=0x7fffffffce88) at eval.c:2885
#14 0x0000000000690c6e in Ffuncall (nargs=1, args=0x7fffffffce80) at eval.c:2767
#15 0x00000000006f3114 in exec_byte_code (bytestr=11633180, vector=11633213, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffd740) at bytecode.c:919
#16 0x0000000000691aba in funcall_lambda (fun=11633133, nargs=0, arg_vector=0x7fffffffd740) at eval.c:2885
#17 0x000000000068ff01 in apply_lambda (fun=11633133, args=0, count=3) at eval.c:2826
#18 0x000000000068afdf in eval_sub (form=18458531) at eval.c:2226
#19 0x000000000068fb66 in Feval (form=18458531, lexical=0) at eval.c:1996
#20 0x00000000005cff4a in top_level_2 () at keyboard.c:1148
#21 0x000000000068e3d1 in internal_condition_case (bfun=0x5cff20 <top_level_2>, handlers=19488, hfun=0x5cff50 <cmd_error>) at eval.c:1348
#22 0x00000000005cfeb3 in top_level_1 (ignore=0) at keyboard.c:1156
#23 0x000000000068d981 in internal_catch (tag=46224, func=0x5cfe60 <top_level_1>, arg=0) at eval.c:1108
#24 0x00000000005b1190 in command_loop () at keyboard.c:1117
#25 0x00000000005b0fe1 in recursive_edit_1 () at keyboard.c:728
#26 0x00000000005b138a in Frecursive_edit () at keyboard.c:799
#27 0x00000000005aeda1 in main (argc=4, argv=0x7fffffffde98) at emacs.c:1607

Lisp Backtrace:
"encode-time" (0xffffb1b0)
"print" (0xffffb5f8)
"progn" (0xffffb858)
"eval" (0xffffba90)
"command-line-1" (0xffffc460)
"command-line" (0xffffce88)
"normal-top-level" (0xffffd740)
(gdb) next
Single stepping until exit from function getenv,
which has no line number information.
emacs_mktime_z (tz=0x1d16ae8 "XXX-0:00:00", tm=0x7fffffffb150) at editfns.c:1405
1405      USE_SAFE_ALLOCA;
(gdb) print oldtz 
$1 = 0x0
--8<---------------cut here---------------end--------------->8---

HTH
-- 
Ashish SHUKLA

<@abbe> give man ssh access, he'll still need computer. give him a computer,
he'll give ssh access to you.

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Ashish SHUKLA wrote:
> When I looked into this before filing this bug report, from what I noticed
> that it's not using libc's `mktime' function, unlike what you seem to
> indicate. I'm not sure quite why it's doing that when libc provided mktime
> works just fine

It may work for this example, but 'configure' checks for a number of mktime 
bugs, and perhaps mktime is not working for some other examples.

Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can tell by 
looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.

When 'configure' says 'checking for working mktime', what's the result?

If you compile and run the attached program, using the same flags that you use 
to build Emacs, what is its exit status?


[-- Attachment #2: mktime-test.c --]
[-- Type: text/x-csrc, Size: 5225 bytes --]

#define HAVE_UNISTD_H 1
#define HAVE_DECL_ALARM 1

/* Test program from Paul Eggert and Tony Leneis.  */
#include <limits.h>
#include <stdlib.h>
#include <time.h>

#ifdef HAVE_UNISTD_H
# include <unistd.h>
#endif

#if HAVE_DECL_ALARM
# include <signal.h>
#endif

/* Work around redefinition to rpl_putenv by other config tests.  */
#undef putenv

static time_t time_t_max;
static time_t time_t_min;

/* Values we'll use to set the TZ environment variable.  */
static char *tz_strings[] = {
  (char *) 0, "TZ=GMT0", "TZ=JST-9",
  "TZ=EST+3EDT+2,M10.1.0/00:00:00,M2.3.0/00:00:00"
};
#define N_STRINGS (sizeof (tz_strings) / sizeof (tz_strings[0]))

/* Return 0 if mktime fails to convert a date in the spring-forward gap.
   Based on a problem report from Andreas Jaeger.  */
static int
spring_forward_gap ()
{
  /* glibc (up to about 1998-10-07) failed this test. */
  struct tm tm;

  /* Use the portable POSIX.1 specification "TZ=PST8PDT,M4.1.0,M10.5.0"
     instead of "TZ=America/Vancouver" in order to detect the bug even
     on systems that don't support the Olson extension, or don't have the
     full zoneinfo tables installed.  */
  putenv ("TZ=PST8PDT,M4.1.0,M10.5.0");

  tm.tm_year = 98;
  tm.tm_mon = 3;
  tm.tm_mday = 5;
  tm.tm_hour = 2;
  tm.tm_min = 0;
  tm.tm_sec = 0;
  tm.tm_isdst = -1;
  return mktime (&tm) != (time_t) -1;
}

static int
mktime_test1 (time_t now)
{
  struct tm *lt;
  return ! (lt = localtime (&now)) || mktime (lt) == now;
}

static int
mktime_test (time_t now)
{
  return (mktime_test1 (now)
          && mktime_test1 ((time_t) (time_t_max - now))
          && mktime_test1 ((time_t) (time_t_min + now)));
}

static int
irix_6_4_bug ()
{
  /* Based on code from Ariel Faigon.  */
  struct tm tm;
  tm.tm_year = 96;
  tm.tm_mon = 3;
  tm.tm_mday = 0;
  tm.tm_hour = 0;
  tm.tm_min = 0;
  tm.tm_sec = 0;
  tm.tm_isdst = -1;
  mktime (&tm);
  return tm.tm_mon == 2 && tm.tm_mday == 31;
}

static int
bigtime_test (int j)
{
  struct tm tm;
  time_t now;
  tm.tm_year = tm.tm_mon = tm.tm_mday = tm.tm_hour = tm.tm_min = tm.tm_sec = j;
  now = mktime (&tm);
  if (now != (time_t) -1)
    {
      struct tm *lt = localtime (&now);
      if (! (lt
             && lt->tm_year == tm.tm_year
             && lt->tm_mon == tm.tm_mon
             && lt->tm_mday == tm.tm_mday
             && lt->tm_hour == tm.tm_hour
             && lt->tm_min == tm.tm_min
             && lt->tm_sec == tm.tm_sec
             && lt->tm_yday == tm.tm_yday
             && lt->tm_wday == tm.tm_wday
             && ((lt->tm_isdst < 0 ? -1 : 0 < lt->tm_isdst)
                  == (tm.tm_isdst < 0 ? -1 : 0 < tm.tm_isdst))))
        return 0;
    }
  return 1;
}

static int
year_2050_test ()
{
  /* The correct answer for 2050-02-01 00:00:00 in Pacific time,
     ignoring leap seconds.  */
  unsigned long int answer = 2527315200UL;

  struct tm tm;
  time_t t;
  tm.tm_year = 2050 - 1900;
  tm.tm_mon = 2 - 1;
  tm.tm_mday = 1;
  tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
  tm.tm_isdst = -1;

  /* Use the portable POSIX.1 specification "TZ=PST8PDT,M4.1.0,M10.5.0"
     instead of "TZ=America/Vancouver" in order to detect the bug even
     on systems that don't support the Olson extension, or don't have the
     full zoneinfo tables installed.  */
  putenv ("TZ=PST8PDT,M4.1.0,M10.5.0");

  t = mktime (&tm);

  /* Check that the result is either a failure, or close enough
     to the correct answer that we can assume the discrepancy is
     due to leap seconds.  */
  return (t == (time_t) -1
          || (0 < t && answer - 120 <= t && t <= answer + 120));
}

int
main ()
{
  int result = 0;
  time_t t, delta;
  int i, j;
  int time_t_signed_magnitude = (time_t) ~ (time_t) 0 < (time_t) -1;
  int time_t_signed = ! ((time_t) 0 < (time_t) -1);

#if HAVE_DECL_ALARM
  /* This test makes some buggy mktime implementations loop.
     Give up after 60 seconds; a mktime slower than that
     isn't worth using anyway.  */
  signal (SIGALRM, SIG_DFL);
  alarm (60);
#endif

  time_t_max = (! time_t_signed
                ? (time_t) -1
                : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
                   * 2 + 1));
  time_t_min = (! time_t_signed
                ? (time_t) 0
                : time_t_signed_magnitude
                ? ~ (time_t) 0
                : ~ time_t_max);

  delta = time_t_max / 997; /* a suitable prime number */
  for (i = 0; i < N_STRINGS; i++)
    {
      if (tz_strings[i])
        putenv (tz_strings[i]);

      for (t = 0; t <= time_t_max - delta && (result & 1) == 0; t += delta)
        if (! mktime_test (t))
          result |= 1;
      if ((result & 2) == 0
          && ! (mktime_test ((time_t) 1)
                && mktime_test ((time_t) (60 * 60))
                && mktime_test ((time_t) (60 * 60 * 24))))
        result |= 2;

      for (j = 1; (result & 4) == 0; j <<= 1)
        {
          if (! bigtime_test (j))
            result |= 4;
          if (INT_MAX / 2 < j)
            break;
        }
      if ((result & 8) == 0 && ! bigtime_test (INT_MAX))
        result |= 8;
    }
  if (! irix_6_4_bug ())
    result |= 16;
  if (! spring_forward_gap ())
    result |= 32;
  if (! year_2050_test ())
    result |= 64;
  return result;
}

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Ashish SHUKLA wrote:
> I did this in X11 window (note the absence
> of '-batch' option)
>
> --8<---------------cut here---------------start------------->8---
> emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
> oldtz=(null) tz=XXX-0:00:00 oldTZ=(null) TZ=(null) 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423962764

This makes it look like immediately after set_time_zone_rule ("XXX-0:00:00") was 
called, getenv ("TZ") returned NULL.  That shouldn't happen: set_time_zone_rule 
is supposed to arrange for TZ to have the specified value.

Could you please try similar tests with the attached patch instead?  It should 
tell us whether set_time_zone_rule is properly affecting the TZ environment 
variable.

[-- Attachment #2: getenv.patch --]
[-- Type: text/x-patch, Size: 457 bytes --]

diff --git a/src/editfns.c b/src/editfns.c
index dbcb316..4c542bd 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2359,6 +2359,11 @@ set_time_zone_rule (const char *tzstring)
       xputenv (tzval);
     }
 
+  char const *TZ = getenv ("TZ");
+  fprintf (stderr, ("set_time_zone_rule (\"%s\"); "
+		    "tzval = \"%s\"; getenv (\"TZ\") -> %s\n"),
+	   tzstring ? tzstring : "(null)", tzval, TZ ? TZ : "(null)");
+
 #ifdef HAVE_TZSET
   tzset ();
 #endif

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Thu, Feb 26 2015, Paul Eggert wrote:

> Ashish SHUKLA wrote:
>> When I looked into this before filing this bug report, from what I noticed
>> that it's not using libc's `mktime' function, unlike what you seem to
>> indicate. I'm not sure quite why it's doing that when libc provided mktime
>> works just fine
>
> It may work for this example, but 'configure' checks for a number of
> mktime bugs, and perhaps mktime is not working for some other
> examples.

Indeed, on amd64 time_t is a signed 64 bit type but something doesn't
really support that.  Adjusting time_t_max (and time_t_min) as if time_t
were a 32 bit type makes the mktime test pass, so that seems to be
a FreeBSD bug.

diff --git a/m4/mktime.m4 b/m4/mktime.m4
index 3f0e1ee..af60ef8 100644
--- a/m4/mktime.m4
+++ b/m4/mktime.m4
@@ -181,7 +181,7 @@ main ()
 
   time_t_max = (! time_t_signed
                 ? (time_t) -1
-                : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
+                : ((((time_t) 1 << (4 * CHAR_BIT - 2)) - 1)
                    * 2 + 1));
   time_t_min = (! time_t_signed
                 ? (time_t) 0



> Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
> tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.

What has this to do with FreeBSD?

> When 'configure' says 'checking for working mktime', what's the result?

The test fails with exit status 3 (without the work-around above).

Wolfgang

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]

On Thu, 26 Feb 2015 00:39:57 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Ashish SHUKLA wrote:
|| I did this in X11 window (note the absence
|| of '-batch' option)
|| 
|| --8<---------------cut here---------------start------------->8---
|| emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
|| oldtz=(null) tz=XXX-0:00:00 oldTZ=(null) TZ=(null) 2015-02-15 06:42:44 -1 -> 2015-02-15 06:42:44 0 = 1423962764

| This makes it look like immediately after set_time_zone_rule
| ("XXX-0:00:00") was called, getenv ("TZ") returned NULL.  That
| shouldn't happen: set_time_zone_rule is supposed to arrange for TZ to
| have the specified value.

| Could you please try similar tests with the attached patch instead?
| It should tell us whether set_time_zone_rule is properly affecting the
| TZ environment variable.

| diff --git a/src/editfns.c b/src/editfns.c
| index dbcb316..4c542bd 100644
| --- a/src/editfns.c
| +++ b/src/editfns.c
| @@ -2359,6 +2359,11 @@ set_time_zone_rule (const char *tzstring)
|        xputenv (tzval);
|      }
 
| +  char const *TZ = getenv ("TZ");
| +  fprintf (stderr, ("set_time_zone_rule (\"%s\"); "
| +		    "tzval = \"%s\"; getenv (\"TZ\") -> %s\n"),
| +	   tzstring ? tzstring : "(null)", tzval, TZ ? TZ : "(null)");
| +
|  #ifdef HAVE_TZSET
|    tzset ();
|  #endif

There you go:

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> (null)
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> (null)
oldtz=(null) tz=XXX-0:00:00 oldTZ=(null) TZ=(null) 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
2015-02-15 06:42:44 0 = 1423962764^C
--8<---------------cut here---------------end--------------->8---

In minibuffer, "(21727 62092)" is displayed. And with "-batch":

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ../src/emacs -batch -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> XXX-0:00:00
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423982564
(21728 16356)
--8<---------------cut here---------------end--------------->8---

Decided to explicitly set "TZ=Asia/Kolkata" in environment before invoking
Emacs, and it seems like now getenv("TZ") is returning "Asia/Kolkata"
everytime:

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % TZ=Asia/Kolkata ../src/emacs -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> Asia/Kolkata
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=Asia/Kolkata 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423962764
--8<---------------cut here---------------end--------------->8---

In minibuffer, "(21727 62092)" is displayed. And with "-batch":

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % TZ=Asia/Kolkata ../src/emacs -batch -Q -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> XXX-0:00:00
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423982564
--8<---------------cut here---------------end--------------->8---

Thanks!
-- 
Ashish SHUKLA

“The mirror sees the man as beautiful, the mirror loves the man; another mirror
sees the man as frightful and hates him; and it is always the same being who
produces the impressions.” (Marquis D. A. F. de Sade)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

On Thu, 26 Feb 2015 00:15:52 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Ashish SHUKLA wrote:
|| When I looked into this before filing this bug report, from what I noticed
|| that it's not using libc's `mktime' function, unlike what you seem to
|| indicate. I'm not sure quite why it's doing that when libc provided mktime
|| works just fine

| It may work for this example, but 'configure' checks for a number of
| mktime bugs, and perhaps mktime is not working for some other
| examples.

| Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
| tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.

--8<---------------cut here---------------start------------->8---
% fgrep APPLE_UNIVERSAL lib/Makefile
APPLE_UNIVERSAL_BUILD = 0
##            -e 's/@''APPLE_UNIVERSAL_BUILD''@/$(APPLE_UNIVERSAL_BUILD)/g' \
              -e 's/@''APPLE_UNIVERSAL_BUILD''@/$(APPLE_UNIVERSAL_BUILD)/g' \
#             -e 's/@''APPLE_UNIVERSAL_BUILD''@/$(APPLE_UNIVERSAL_BUILD)/g' \
--8<---------------cut here---------------end--------------->8---

| When 'configure' says 'checking for working mktime', what's the result?

--8<---------------cut here---------------start------------->8---
configure:25619: checking for working mktime
configure:25827: clang -o conftest -g -march=corei7  -g -fstack-protector -fno-strict-aliasing   -I/usr/local/include  -L/usr/local/lib -Wl,-rpath=/usr/local/lib -ltinfo -fstack-protector -L/usr/local/lib con
ftest.c   >&5 
configure:25827: $? = 0
configure:25827: ./conftest
configure:25827: $? = 3
configure: program exited with status 3
--8<---------------cut here---------------end--------------->8---

| If you compile and run the attached program, using the same flags that
| you use to build Emacs, what is its exit status?

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % clang -o /tmp/mktime-test  -g -march=corei7  -g -fstack-protector -fno-strict-aliasing   -I/usr/local/include  -L/usr/local/lib -Wl,-rpath=/usr/local/lib -ltinfo -fstack-protector -L/usr/local/lib /tmp/mktime-test.c
emacs-25.0.50.20150206.5c9ad35f/src % /tmp/mktime-test 
emacs-25.0.50.20150206.5c9ad35f/src % echo $?
3
--8<---------------cut here---------------end--------------->8---

Thanks!
-- 
Ashish SHUKLA

“The only things certain in life are death, taxes, and accidentally deleted
data.” (bazza)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Thu, Feb 26 2015, Wolfgang Jenkner wrote:

> Indeed, on amd64 time_t is a signed 64 bit type but something doesn't
> really support that.  Adjusting time_t_max (and time_t_min) as if time_t
> were a 32 bit type makes the mktime test pass, so that seems to be
> a FreeBSD bug.

Sigh.  It's localtime that is broken: It doesn't return a NULL pointer
(nor sets it errno) when the tm_year field (an int) can't hold the
result.  Hence mktime_test1 doesn't return 1 in this case.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=145341

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

On 02/26/2015 05:42 AM, Wolfgang Jenkner wrote:
>> Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
>> >tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.
> What has this to do with FreeBSD?
>

If 'configure' mistakenly set APPLE_UNIVERSAL_BUILD to 1, it would cause 
'configure' to guess that mktime was buggy, and I was worried that this 
would have caused the problem.  However, this was a red herring, as 
you've established that FreeBSD localtime and/or mktime is indeed buggy 
in this area, so 'configure' appears to be doing the right thing in 
rejecting FreeBSD mktime.

It also appears to be the case that FreeBSD 10.1's implementation of 
putenv is buggy, and that this is what is breaking Emacs's time code (as 
Emacs uses putenv to modify the TZ environment variable), but we haven't 
gotten to the bottom of that yet.  I'll try to write a little test 
program to narrow it down.

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Thu, Feb 26 2015, Paul Eggert wrote:

> On 02/26/2015 05:42 AM, Wolfgang Jenkner wrote:
>>> Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
>>> >tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.
>> What has this to do with FreeBSD?
>>
>
> If 'configure' mistakenly set APPLE_UNIVERSAL_BUILD to 1, it would
> cause 'configure' to guess that mktime was buggy, and I was worried
> that this would have caused the problem.  However, this was a red
> herring, as you've established that FreeBSD localtime and/or mktime is
> indeed buggy in this area, so 'configure' appears to be doing the
> right thing in rejecting FreeBSD mktime.

Thanks for the explanation!  However, there's no indication that mktime
is buggy (all tests pass when adjusting time_t_min, time_t_max), while
localtime (and localtime_r) certainly is.  Nevertheless, the configure
test causes mktime to be replaced but not localtime_r, which is actually
used in emacs.  If I may say so this seems a bit like pulling the wrong
tooth ;-)

> It also appears to be the case that FreeBSD 10.1's implementation of
> putenv is buggy, and that this is what is breaking Emacs's time code
> (as Emacs uses putenv to modify the TZ environment variable), but we
> haven't gotten to the bottom of that yet.  I'll try to write a little
> test program to narrow it down.

But putenv is already replaced on my 10-STABLE system (and emacs trunk):

$ nm src/emacs | grep putenv
00000000005b85a0 T rpl_putenv
0000000000527150 T xputenv

Ah, and the OP's example actually seems to give the expected result here
(my timezone is Europe/Vienna):

(encode-time 44 42 6 15 2 2015 0 nil 0)
=> (21728 16356)

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Thu, 26 Feb 2015 20:00:18 +0100, Wolfgang Jenkner <wjenkner@inode.at> said:
| On Thu, Feb 26 2015, Paul Eggert wrote:

|| On 02/26/2015 05:42 AM, Wolfgang Jenkner wrote:
|||| Is 'configure' setting APPLE_UNIVERSAL_BUILD to 1, or to 0?  You can
|||| >tell by looking for APPLE_UNIVERSAL_BUILD in lib/Makefile.
||| What has this to do with FreeBSD?
||| 
|| 
|| If 'configure' mistakenly set APPLE_UNIVERSAL_BUILD to 1, it would
|| cause 'configure' to guess that mktime was buggy, and I was worried
|| that this would have caused the problem.  However, this was a red
|| herring, as you've established that FreeBSD localtime and/or mktime is
|| indeed buggy in this area, so 'configure' appears to be doing the
|| right thing in rejecting FreeBSD mktime.

[...]


| Ah, and the OP's example actually seems to give the expected result here
| (my timezone is Europe/Vienna):

| (encode-time 44 42 6 15 2 2015 0 nil 0)
| => (21728 16356)

In interactive mode ? In interactive-mode it's broken for me, in batch mode it
works fine.

-- 
Ashish SHUKLA

“The English have no respect for their language, and will not teach their
children to speak it.” (George Bernard Shaw, "Pygmalion", 1912)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Fri, Feb 27 2015, Ashish SHUKLA wrote:

> | (encode-time 44 42 6 15 2 2015 0 nil 0)
> | => (21728 16356)
>
> In interactive mode ? In interactive-mode it's broken for me, in batch mode it
> works fine.

Yes, it gives the same result as above in both ways for me.

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Thu, 26 Feb 2015 21:05:52 +0100, Wolfgang Jenkner <wjenkner@inode.at> said:
| On Fri, Feb 27 2015, Ashish SHUKLA wrote:

|| | (encode-time 44 42 6 15 2 2015 0 nil 0)
|| | => (21728 16356)
|| 
|| In interactive mode ? In interactive-mode it's broken for me, in batch mode it
|| works fine.

| Yes, it gives the same result as above in both ways for me.

Very strange. FTR, following is output of `uname -a`:

FreeBSD chateau.d.if 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0 r279268: Wed Feb 25 12:37:13 IST 2015     root@chateau.d.if:/wrksrc/usr/src/sys/CHATEAU  amd64

and /etc/localtime points to the file in /usr/share/zoneinfo, and no TZ
environment variable is set, in my case.

Do you have TZ environment variable set, or you use /etc/localtime ? And also are
you on FreeBSD 10.1/amd64 as well ?

Thanks!
-- 
Ashish SHUKLA

“Now I’ve only been an OpenBSD developer for 11 years, one year less than this
header has existed, but in that brief time, I’ve learned a thing or two about
deleting obsolete code. It doesn’t delete itself. And worse, people will
continue using it until you force them onto a better path.” (Ted Unangst, OpenBSD)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Fri, Feb 27 2015, Ashish SHUKLA wrote:

> On Thu, 26 Feb 2015 21:05:52 +0100, Wolfgang Jenkner <wjenkner@inode.at> said:
> | On Fri, Feb 27 2015, Ashish SHUKLA wrote:
>
> || | (encode-time 44 42 6 15 2 2015 0 nil 0)
> || | => (21728 16356)
> || 
> || In interactive mode ? In interactive-mode it's broken for me, in batch mode it
> || works fine.
>
> | Yes, it gives the same result as above in both ways for me.
>
> Very strange. FTR, following is output of `uname -a`:
>
> FreeBSD chateau.d.if 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0 r279268: Wed Feb 25 12:37:13 IST 2015     root@chateau.d.if:/wrksrc/usr/src/sys/CHATEAU  amd64

My 10-STABLE version is actually a month or so older than 10.1-RELEASE
(which was announced on 14 Nov 2014):

FreeBSD iznogoud.viz 10.1-RC1 FreeBSD 10.1-RC1 #0 r272822M: Thu Oct  9 19:45:54 CEST 2014     adm@iznogoud.viz:/usr/obj/usr/src/sys/IZNOGOUD  amd64

Here's the output of `svn info' (I haven't updated since I compiled base
and kernel):

Path: .
Working Copy Root Path: /usr/src
URL: svn://svn0.eu.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: svn://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 272822
Node Kind: directory
Schedule: normal
Last Changed Author: mav
Last Changed Rev: 272798
Last Changed Date: 2014-10-09 07:28:11 +0200 (Thu, 09 Oct 2014)

> and /etc/localtime points to the file in /usr/share/zoneinfo, and no TZ
> environment variable is set, in my case.

In my case, /etc/localtime is a copy of the file in /usr/share/zoneinfo.
IIUC, `mergemaster -i' is supposed to automatically run `tzsetup -r' to
update /etc/localtime from /var/db/zoneinfo.  I have no TZ in the environment.

$ ls -li /etc/localtime /usr/share/zoneinfo/Europe/Vienna 
 211986 -r--r--r--  1 root  wheel  2211 Oct  9 20:42 /etc/localtime
7892691 -r--r--r--  1 root  wheel  2211 Oct  9 20:36 /usr/share/zoneinfo/Europe/Vienna
$ cmp /etc/localtime /usr/share/zoneinfo/Europe/Vienna 
$ echo $?
0
$ cat /var/db/zoneinfo 
Europe/Vienna
$ printenv | grep TZ
$ echo $?
1

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Fri, Feb 27 2015, Ashish SHUKLA wrote:

> Very strange.

Looking at the configure options from your original report I notice that
another difference (apart from the somewhat different FreeBSD 10
revisions) is that I don't compile emacs with gconf, gsettings, dbus or
gtk3.  I wonder if the bug is still present in, say, a minimally built
emacs with X support, viz.,

./configure --without-all --with-x --with-x-toolkit=no

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]

On Fri, 27 Feb 2015 03:51:00 +0100, Wolfgang Jenkner <wjenkner@inode.at> said:
| On Fri, Feb 27 2015, Ashish SHUKLA wrote:

|| Very strange.

| Looking at the configure options from your original report I notice that
| another difference (apart from the somewhat different FreeBSD 10
| revisions) is that I don't compile emacs with gconf, gsettings, dbus or
| gtk3.  I wonder if the bug is still present in, say, a minimally built
| emacs with X support, viz.,

| ./configure --without-all --with-x --with-x-toolkit=no

So, looks like you're right it only happens with X11 (Gtk3) build, and if I
invoke Emacs in '-nw', or with Xaw front-end, it does not happen as evident
From following tests:

Emacs in batch mode:

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ./emacs -Q -batch -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'                    
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> XXX-0:00:00
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423982564
(21728 16356)
--8<---------------cut here---------------end--------------->8---

Emacs in interactive mode in curses:

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ./emacs -Q -nw -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'  >/tmp/foo.txt 2>&1
chateau.d.if!abbe:~/tinderbox/redports/editors/emacs-devel/work2/emacs-25.0.50.20150206.5c9ad35f/src λ cat /tmp/foo.txt
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> XXX-0:00:00
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423982564
--8<---------------cut here---------------end--------------->8---

Emacs in interactive mode in X11 (GTK3):

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ./emacs -Q  -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'        
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> (null)
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> (null)
oldtz=(null) tz=XXX-0:00:00 oldTZ=(null) TZ=(null) 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
2015-02-15 06:42:44 0 = 1423962764
--8<---------------cut here---------------end--------------->8---

Emacs in interactive mode in X11 (Xaw) compiled with following ./configure line:

./configure --localstatedir=/var --without-compress-install --without-dbus --with-file-notification=gfile --without-gconf --without-gif --with-gnutls --without-gsettings --without-jpeg --without-m17n-flt --without-imagemagick --without-libotf --without-png --without-toolkit-scroll-bars --without-rsvg --without-tiff --with-x --without-xft --without-xim --with-xml2 --without-xpm --with-x-toolkit=athena --without-xaw3d --with-sound=oss --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/share/emacs/info/ --build=amd64-portbld-freebsd10.1

--8<---------------cut here---------------start------------->8---
emacs-25.0.50.20150206.5c9ad35f/src % ./emacs -Q  -eval '(progn (setenv "TZ" "Asia/Kolkata") (print (encode-time 44 42 6 15 2 2015 0 nil 0)))'        
set_time_zone_rule ("(null)"); tzval = "tZ="; getenv ("TZ") -> (null)
set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
set_time_zone_rule ("XXX-0:00:00"); tzval = "TZ=XXX-0:00:00"; getenv ("TZ") -> XXX-0:00:00
oldtz=Asia/Kolkata tz=XXX-0:00:00 oldTZ=Asia/Kolkata TZ=XXX-0:00:00 2015-02-15 06:42:44 -1 -> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> Asia/Kolkata
2015-02-15 06:42:44 0 = 1423982564
--8<---------------cut here---------------end--------------->8---

HTH
-- 
Ashish SHUKLA

<bazza> contracts are no match for geniuses

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

Ashish SHUKLA wrote:
> set_time_zone_rule ("Asia/Kolkata"); tzval = "TZ=Asia/Kolkata"; getenv ("TZ") -> (null)

This confirms that there's something wrong with set_time_zone_rule and/or 
getenv; the former is supposed to set the environment variable TZ to 
"Asia/Kolkata", but getenv ("TZ") returns NULL.

Can you run GDB and see why getenv is failing there?

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

Wolfgang Jenkner wrote:

> Thanks for the explanation!  However, there's no indication that mktime
> is buggy (all tests pass when adjusting time_t_min, time_t_max), while
> localtime (and localtime_r) certainly is.  Nevertheless, the configure
> test causes mktime to be replaced but not localtime_r, which is actually
> used in emacs.  If I may say so this seems a bit like pulling the wrong
> tooth ;-)

I suppose we could make Gnulib smarter, so that it replaces some other function 
if it finds a particular bug in mktime, a bug that can be chalked up to 
localtime_r etc.  However, the current approach is simpler to maintain and 
shouldn't hurt anything.  Ashish's problem seems not to be in mktime at all (nor 
in its replacement).

>> It also appears to be the case that FreeBSD 10.1's implementation of
>> putenv is buggy, and that this is what is breaking Emacs's time code
>> (as Emacs uses putenv to modify the TZ environment variable), but we
>> haven't gotten to the bottom of that yet.  I'll try to write a little
>> test program to narrow it down.
>
> But putenv is already replaced on my 10-STABLE system (and emacs trunk):
>
> $ nm src/emacs | grep putenv
> 00000000005b85a0 T rpl_putenv
> 0000000000527150 T xputenv

Yes, and that's because FreeBSD putenv is incompatible with GNU putenv; in GNU 
systems, putenv ("xxx") is equivalent to unsetenv ("xxx") but FreeBSD doesn't 
support this extension to POSIX.  I don't know whether Emacs needs this 
extension, but it shouldn't hurt to have it.

> Ah, and the OP's example actually seems to give the expected result here
> (my timezone is Europe/Vienna):

Yes.  I can't reproduce the problem either.  I finally got around to building a 
VM running FreeBSD 10.1 amd64, and I cannot reproduce the bug, even when 
/etc/localtime is a copy of /usr/share/zoneinfo/Asia/Kolkata and TZ is initially 
unset.  However, I am running it in a text window, not under Gtk3.

Perhaps Gtk3 is in some way interfering with Emacs's putenv substitute.

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Ashish SHUKLA wrote:
> So, looks like you're right it only happens with X11 (Gtk3) build

Possibly the Gtk3 code calls 'setenv', and this collides with Emacs's 
implementation of putenv.

Emacs's putenv implementation should be portable to any POSIX platform, but 
FreeBSD 10.1 getenv+setenv has a bug.  The attached program should work on any 
POSIX platform, and it does work on GNU/Linux and on Solaris, but it doesn't 
work on FreeBSD 10.1.  Emacs has similar code, which apparently also runs afoul 
of the FreeBSD bug.

[-- Attachment #2: putenv-test.c --]
[-- Type: text/x-csrc, Size: 345 bytes --]

#include <stdio.h>
#include <stdlib.h>
extern char **environ;
char env1[] = "abc=def";
char *small_environ[] = { env1, 0 };
int
main (void)
{
  environ = small_environ;
  if (setenv ("mno", "pqr", 0) != 0)
    return perror ("setenv"), 1;
  env1[0] = 'x';
  if (! getenv ("xbc"))
    return fprintf (stderr, "getenv failed\n"), 1;
  return 0;
}

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Ashish SHUKLA wrote:
> So, looks like you're right it only happens with X11 (Gtk3) build

Please try the attached patch, which I've installed in the Emacs master.  It 
should work around the bug in FreeBSD 10.1 getenv that was identified in 
<http://bugs.gnu.org/19874#68>.

[-- Attachment #2: 0001-Don-t-require-GNU-putenv.patch --]
[-- Type: text/x-patch, Size: 1546 bytes --]

From 1556eb079d0ce8207b17faad9861e52e07fd92f8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 27 Feb 2015 00:04:39 -0800
Subject: [PATCH] Don't require GNU putenv

* configure.ac: Use system putenv even if it lacks GNU features, as
we don't need them.  This works around a bug in FreeBSD 10.1 getenv.
Fixes: bug#19874
---
 ChangeLog    | 7 +++++++
 configure.ac | 5 +++++
 2 files changed, 12 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 47ef578..0bfdfbb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2015-02-27  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Don't require GNU putenv
+	* configure.ac: Use system putenv even if it lacks GNU features, as
+	we don't need them.  This works around a bug in FreeBSD 10.1 getenv.
+	Fixes: bug#19874
+
 2015-02-25  Paul Eggert  <eggert@cs.ucla.edu>
 
 	Merge from gnulib
diff --git a/configure.ac b/configure.ac
index 0bcc55c..e7408f1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -780,6 +780,11 @@ AC_DEFUN([gl_CRYPTO_CHECK])
 # Avoid gnulib's tests for HAVE_WORKING_O_NOATIME and HAVE_WORKING_O_NOFOLLOW,
 # as we don't use them.
 AC_DEFUN([gl_FCNTL_O_FLAGS])
+# Use the system putenv even if it lacks GNU features, as we don't need them,
+# and the gnulib replacement runs afoul of a FreeBSD 10.1 bug; see Bug#19874.
+AC_CHECK_FUNCS_ONCE([putenv])
+AC_DEFUN([gl_FUNC_PUTENV],
+  [test "$ac_cv_func_putenv" = yes || REPLACE_PUTENV=1])
 
 # Initialize gnulib right after choosing the compiler.
 dnl Amongst other things, this sets AR and ARFLAGS.
-- 
2.1.0

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

On Thu, 26 Feb 2015 22:38:31 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Ashish SHUKLA wrote:
|| So, looks like you're right it only happens with X11 (Gtk3) build

| Possibly the Gtk3 code calls 'setenv', and this collides with Emacs's
| implementation of putenv.

| Emacs's putenv implementation should be portable to any POSIX
| platform, but FreeBSD 10.1 getenv+setenv has a bug.  The attached
| program should work on any POSIX platform, and it does work on
| GNU/Linux and on Solaris, but it doesn't work on FreeBSD 10.1.  Emacs
| has similar code, which apparently also runs afoul of the FreeBSD bug.

In FreeBSD, every call to setenv() results in a rebuilding of "internal
environment" with strdup-ed copies of existing strings in "environ"[1], and
getenv only refers to "environ" iff environ is different than what "internal
environment" points to.

If your test program is modified a bit:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
char env1[] = "abc=def";
char *small_environ[] = { env1, 0 };
int
main (void)
{
  int i = 0;
  environ = small_environ;
  for( i = 0; NULL != environ[i]; i++ )
    printf( "environment[%d]: %p\n", i, environ[i] );
  if (setenv ("mno", "pqr", 0) != 0)
    return perror ("setenv"), 1;
  for( i = 0; NULL != environ[i]; i++ )
    printf( "environment[%d]: %p\n", i, environ[i] );
  environ[1][0] = 'x';
  if (! getenv ("xbc")) {
        printf("environ: %p\nsmall_environ: %p\n", environ, small_environ );
    return fprintf (stderr, "getenv failed\n"), 1;
  }
  return 0;
}
--8<---------------cut here---------------end--------------->8---

then it doesn't fail:

--8<---------------cut here---------------start------------->8---
% /tmp/putenv-test           
environment[0]: 0x600de0
environment[0]: 0x801008060
environment[1]: 0x801008058
--8<---------------cut here---------------end--------------->8---

which is definitely incompatible with GNU Emacs, and thus breaks its
expectations.

References:
[1]  http://svnweb.freebsd.org/base/releng/10.1/lib/libc/stdlib/getenv.c?revision=272461&view=markup#l349

HTH
-- 
Ashish SHUKLA

“echo pkill cat >curiosity ; chmod +x !$; ./curiosity” (abbe, 2010)

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Ashish SHUKLA]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Fri, 27 Feb 2015 00:09:21 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
| Ashish SHUKLA wrote:
|| So, looks like you're right it only happens with X11 (Gtk3) build

| Please try the attached patch, which I've installed in the Emacs
| master.  It should work around the bug in FreeBSD 10.1 getenv that was
| identified in <http://bugs.gnu.org/19874#68>.

Hi,

This works great now. We can close this bug.

References:
[1]  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18899

Thank you!
-- 
Ashish SHUKLA

“Snow and adolescence are the only problems that disappear if you ignore them
long enough.”

Sent from my Emacs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

On 02/27/2015 12:28 AM, Ashish SHUKLA wrote:
> If your test program is modified a bit:
> ...
> then it doesn't fail:

Sure, but the modified test program has unspecified behavior in POSIX, 
as there's no guarantee that environ[1] is "abc" (it might be "mno").  
Whereas the original test program has well-defined behavior in POSIX, 
but reports an error because FreeBSD 10.1 getenv is buggy.

Anyway, Emacs now works around the FreeBSD bug so I'm closing this Emacs 
bug report.  Thanks for checking the fix.

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Thu, Feb 26 2015, Paul Eggert wrote:

> Emacs's putenv implementation should be portable to any POSIX
> platform, but FreeBSD 10.1 getenv+setenv has a bug.  The attached
> program should work on any POSIX platform, and it does work on
> GNU/Linux and on Solaris, but it doesn't work on FreeBSD 10.1.  Emacs
> has similar code, which apparently also runs afoul of the FreeBSD bug.
>
> #include <stdio.h>
> #include <stdlib.h>
> extern char **environ;
> char env1[] = "abc=def";
> char *small_environ[] = { env1, 0 };
> int
> main (void)
> {
>   environ = small_environ;
>   if (setenv ("mno", "pqr", 0) != 0)
>     return perror ("setenv"), 1;
>   env1[0] = 'x';
>   if (! getenv ("xbc"))
>     return fprintf (stderr, "getenv failed\n"), 1;
>   return 0;
> }

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.)

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

[-- 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 --]

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Fri, Feb 27 2015, Paul Eggert wrote:

> 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.


No, I think about the parenthetical remark above: It states `copying the
environment strings' and not `copying the pointers to the environment
strings'.  Normally, in documentation, copying a `string' refers to the
object, i.e the region in memory it occupies, not to the pointer
designating it.  And the program modifies env1 after it may have copied
to the new `environment'.

Wolfgang

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Sat, Feb 28 2015, Wolfgang Jenkner wrote:

>  may have copied

may have been copied

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

Wolfgang Jenkner wrote:
> No, I think about the parenthetical remark above: It states `copying the
> environment strings' and not `copying the pointers to the environment
> strings'.  Normally, in documentation, copying a `string' refers to the
> object, i.e the region in memory it occupies, not to the pointer
> designating it.

That interpretation of the rationale is inconsistent with how putenv is required 
to behave.  If one uses putenv to add a string to the environment, one can later 
alter the string (via strcpy, say), and this changes the environment; this is 
quite clear from the normative text.  Under the above interpretation, however, 
getenv could copy the string's contents somewhere else, which would mean that 
modifying the putenv-supplied string would not change the environment.

If the rationale were intended to discuss copying the strings' contents, then 
its sentence "copying the environment strings into a new array and assigning 
environ to point to it" would be incorrect, as one would not assign environ to 
point to the new array containing the strings' contents, but rather one would 
assign environ[0], environ[1], environ[2], etc. to point within the new array. 
The context of that part of the rationale makes it clear that "assign to 
environ" means "environ = SOMETHING", not "environ[0] = SOMETHING".

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Sat, Feb 28 2015, Paul Eggert wrote:

> Wolfgang Jenkner wrote:
>> No, I think about the parenthetical remark above: It states `copying the
>> environment strings' and not `copying the pointers to the environment
>> strings'.  Normally, in documentation, copying a `string' refers to the
>> object, i.e the region in memory it occupies, not to the pointer
>> designating it.
>
> That interpretation of the rationale is inconsistent with how putenv
> is required to behave.  If one uses putenv to add a string to the
> environment, one can later alter the string (via strcpy, say), and
> this changes the environment; this is quite clear from the normative
> text.  Under the above interpretation, however, getenv could copy the
> string's contents somewhere else, which would mean that modifying the
> putenv-supplied string would not change the environment.

Sure, if putenv is supported it must be compatible with getenv (as the
standard states) and the interpretation of the rationale in this case
implies that getenv can't copy the strings' content, but setenv may,
IIUC (I'm still just wondering if the test program you posted is
conforming).

> If the rationale were intended to discuss copying the strings'
> contents, then its sentence "copying the environment strings into
> a new array and assigning environ to point to it" would be incorrect,
> as one would not assign environ to point to the new array containing
> the strings' contents, but rather one would assign environ[0],
> environ[1], environ[2], etc. to point within the new array. The
> context of that part of the rationale makes it clear that "assign to
> environ" means "environ = SOMETHING", not "environ[0] = SOMETHING".

Yes, I was simply thinking about something like

	q = environ_tmp;
	for (p = environ; *p; p++, q++)
		*q = strdup(*p);
	environ = environ_tmp;

bug#19874: 25.0.50; encode-time not working as expected

[Paul Eggert]

Wolfgang Jenkner wrote:
> I was simply thinking about something like
>
> 	q = environ_tmp;
> 	for (p = environ; *p; p++, q++)
> 		*q = strdup(*p);
> 	environ = environ_tmp;

The behavior of getenv, setenv, etc. are undefined after a program modifies 
environ[0], environ[1], etc.  See POSIX 8.1 
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_01>. 
  So, although a POSIX-conforming program can do the above, it can't use getenv 
etc. afterwards.

In contrast the putenv-test.c program I sent earlier 
<http://bugs.gnu.org/19874#68> doesn't modify environ[0], environ[1], etc., so 
it can rely upon getenv etc.

Emacs's problem on FreeBSD occurred because Gnulib's workaround for FreeBSD 
putenv's incompatibility with GNU putenv ran afoul of the POSIX 8.1 restriction. 
  My recent patch worked around the workaround, by telling Emacs to not use 
Gnulib's workaround.  So fixing the FreeBSD bug exemplified by putenv-test.c 
isn't needed to get Emacs to work; still, it's a bug that may bite other programs.

bug#19874: 25.0.50; encode-time not working as expected

[Wolfgang Jenkner]

On Sun, Mar 01 2015, Paul Eggert wrote:

>> I was simply thinking about something like
>>
>> 	q = environ_tmp;
>> 	for (p = environ; *p; p++, q++)
>> 		*q = strdup(*p);
>> 	environ = environ_tmp;
>
> The behavior of getenv, setenv, etc. are undefined after a program
> modifies environ[0], environ[1], etc.  See POSIX 8.1
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_01>. So,
> although a POSIX-conforming program can do the above, it can't use
> getenv etc. afterwards.

The parenthetical remark in the getenv RATIONALE section is about what
the *implementation* may do.

    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.)

The code snippet above just illustrates a possible interpretation of the
parenthetical remark above.