headers
Richard Stallman | 1 Apr 2006 22:28
Picon
Picon

Re: Emacs current-time-string core dump on 64-bit hosts

       #ifndef TM_YEAR_IN_ASCTIME_RANGE
       # define TM_YEAR_IN_ASCTIME_RANGE(tm_year) \
	    (1000 - 1900 <= (tm_year) && (tm_year) <= 9999 - 1900)
       #endif

    and then in s/gnu-linux.h and src/s/gnu.h we'd put this:

       #define TM_YEAR_IN_ASCTIME_RANGE(tm_year) ((tm_year) <= INT_MAX - 1900)

I was thinking of something a little different, but this is fine too.

    Is that the sort of thing you have in mind?  If so, can you please
    suggest where the generic definition of TM_YEAR_IN_ASCTIME_RANGE
    should go?

Don't worry about it--just copy those 4 lines into each of the three
.c files.
Permalink | Reply | 1 comment |
headers
Paul Eggert | 3 Apr 2006 06:44
Favicon

Re: Emacs current-time-string core dump on 64-bit hosts

Richard Stallman <rms <at> gnu.org> writes:

> Don't worry about it--just copy those 4 lines into each of the three
> .c files.

OK, here's a patch that does this.  If I understand you correctly, you
want current-time-string to output a year that might contain more than
4 bytes (if it is greater than 9999, say) and might contain fewer (if
it is in the range 100-999, say).  I haven't installed this patch yet,
since I wanted to double-check this with you first.

With this patch, I assume that I should also put something like this line:

#define TM_YEAR_IN_ASCTIME_RANGE(tm_year) 1

into src/s/gnu-linux.h and into src/s/gnu.h, but I'm not sure exactly
where you'd prefer it.  At the end, perhaps?

2006-04-02  Paul Eggert  <eggert <at> cs.ucla.edu>

	* lib-src/b2m.c (main): Don't include <limits.h>.
	(TM_YEAR_BASE): New macro.
	(TM_YEAR_IN_ASCTIME_RANGE): Don't define if already defined, so
	that s/ files can override this.  Use the more-conservative range
	1000-9999.
	(main): Check for asctime returning NULL.
	* lib-src/fakemail.c: Likewise.
	* src/editfns.c (TM_YEAR_IN_ASCTIME_RANGE): New macro, identical to
	../lib-src/b2m.c and ../lib-src/editfns.c.
	(Fcurrent_time_string): Use it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kim Taavo | 3 Apr 2006 17:14
Picon
Favicon

ediff-setup-windows-plain problem

Hi!

I have Emacs 21.4.1, and have a problem with the control-buffer of ediff not 
showing up when using the 'plain' window setup and having the tool-bar 
turned off.

I start the ediff session without loading any site-file or local ~/.emacs 
file:

emacs --no-init-file --no-site-file --eval '(progn (setq 
ediff-window-setup-function (quote ediff-setup-windows-plain)) 
(tool-bar-mode -1) (ediff-files "/tmp/1.txt" "/tmp/2.txt"))'

However, when using three buffers the control-buffer shows up like it 
should. Eg;

emacs --no-init-file --no-site-file --eval '(progn (setq 
ediff-window-setup-function (quote ediff-setup-windows-plain)) 
(tool-bar-mode -1) (ediff-files3 "/tmp/1.txt" "/tmp/2.txt" "/tmp/3.txt"))'

I'm running the latest Gentoo Linux distribution, and have tried both the 
emacs that comes with the distribution and the vanilla emacs from 
ftp.gnu.org/pub/gnu/emacs/ on both x86 and amd64.

When compiling the vanilla emacs I tried all the different toolkits, but 
that didn't seem to make any difference (although I did not compile vanilla 
versions of the actual toolkits).

If you need additional information or testing, feel free to email me and 
I'll do my best to straighten out any question marks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Eggert | 4 Apr 2006 06:57
Favicon

Re: Emacs current-time-string core dump on 64-bit hosts

I got a response via private email from Ulrich Leodolter about that
old comment of his in w32.c and ntlib.c.  He wrote:

> I cant remember the context, but i think know the reason for this
> workaround:
>
> time_t t = -1;
> char *str = ctime(&t);
>
> I verified that str is a null pointer when this code is compiled with
> MS Visual C/C++ 6.0, but it returns a time string on Linux/GNU.

So it appears that my analysis was correct.  That is, the problem was
unrelated to whether the working directory was a network drive.  The
problem (which is documented by Microsoft) is that, if a time stamp is
negative, ctime returns a null pointer.  This null pointer caused the
circa 1995 edition of Emacs to crash, since 1995 Emacs assumed that
ctime always returns a valid pointer.

If a future edition of Emacs uses ctime, it won't be able to assume
that ctime must return a nonnull pointer.  Even assuming reliable
implementations like glibc, a ctime-using Emacs would have to check
whether ctime's returned value is null; and to be portable to
less-reliable implementations like Solaris 8, Emacs would have to
check that ctime's argument is in an implementation-dependent range.
And either way, the w32 wrapper would not be needed.

With that in mind I'd like to re-propose the following minor cleanup
patch to the w32 code.  It doesn't fix any bugs, since Emacs no longer
uses ctime.  But it simplifies the Emacs code (e.g., it means we don't
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 4 Apr 2006 20:20
Picon

Re: Emacs current-time-string core dump on 64-bit hosts

> Cc: bug-gnu-emacs <at> gnu.org
> From: Paul Eggert <eggert <at> CS.UCLA.EDU>
> Date: Mon, 03 Apr 2006 21:57:04 -0700
> 
> So it appears that my analysis was correct.  That is, the problem was
> unrelated to whether the working directory was a network drive.  The
> problem (which is documented by Microsoft) is that, if a time stamp is
> negative, ctime returns a null pointer.  This null pointer caused the
> circa 1995 edition of Emacs to crash, since 1995 Emacs assumed that
> ctime always returns a valid pointer.

The comment clearly mentions ``network directories'', and he says he
doesn't remember the reason.  Even if the argument passed to ctime was
negative, as long as that is a result of legitimate sequence of system
calls, IMO it is a very bad idea to signal an error.

> With that in mind I'd like to re-propose the following minor cleanup
> patch to the w32 code.  It doesn't fix any bugs, since Emacs no longer
> uses ctime.  But it simplifies the Emacs code

The simplification is minimal, unlike the risks, so I'd like to leave
those functions alone.
Permalink | Reply | 0 comments |
headers
Dan Jacobson | 4 Apr 2006 23:11
Favicon
Gravatar

describe-char-after vs. Unicode

(Might have reported already.)
All I know is for Unicode char
       ā &#257;       &#x101;
describe-char-after says a lot,
  character: ā (05140, 2656, 0xa60)
    charset: latin-iso8859-4
	     (Right-Hand Part of Latin Alphabet 4 (ISO/IEC 8859-4): ISO-IR-110)
 code point: 96
     syntax: word
   category: l:Latin
buffer code: 0x84 0xE0
  file code: 0xC4 0x81 (encoded by coding system utf-8-unix)
       font: -Adobe-New Century Schoolbook-Medium-R-Normal--14-140-75-75-P-82-ISO8859-4
but doesn't mention the numbers &#257; or &#x101;
Permalink | Reply | 2 comments |
headers
Dan Jacobson | 4 Apr 2006 20:38
Favicon
Gravatar

capitalize-word lags behind Unicode

capitalize-word can capitalize á but not ǎ nor ａ. I didn't test
Greek, Russian or lowercasing functions.
Permalink | Reply | 1 comment |
headers
Dan Jacobson | 4 Apr 2006 20:17
Favicon
Gravatar

detect <?xml> at first line of files

Emacs doesn't auto-detect <?xml version="1.0"?> on the first line of
files. It should in order to pick some good major mode or whatever.
Permalink | Reply | 1 comment |
headers
Dan Jacobson | 4 Apr 2006 19:57
Favicon
Gravatar

mouse can't resize side by side windows

With the mouse I can resize the windows made with C-x 2, but not C-x 3.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 5 Apr 2006 05:27
Picon

Re: describe-char-after vs. Unicode

> From: Dan Jacobson <jidanni <at> jidanni.org>
> Date: Wed, 05 Apr 2006 05:11:28 +0800
> Cc: handa <at> etl.go.jp
> 
> describe-char-after says a lot,
> [...]
> but doesn't mention the numbers &#257; or &#x101;

Because your Emacs version still doesn't support Unicode well enough.
One of the future versions will.
Permalink | Reply | 0 comments |

Gmane