bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#29040: Emacs 25 hangs on windows arbitrarily during search of a unic


From: Eli Zaretskii
Subject: bug#29040: Emacs 25 hangs on windows arbitrarily during search of a unicode file
Date: Thu, 02 Nov 2017 22:46:11 +0200

> Cc: rcopley@gmail.com, 29040@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 2 Nov 2017 13:35:16 -0700
> 
> Yes, we can stop using alignas entirely, since it doesn't work the way I 
> expected. I thought that it could only increase alignment, and that it 
> was a no-op if it specified a decreased alignment: this is how 
> __attribute__ ((aligned (8))) works. However, I now see that C11 says 
> that a compiler is supposed to report an error if alignas specifies a 
> decreased alignment. So I installed the attached patch to stop using 
> alignas.

Thanks, but I think the resulting code is confusing.  E.g.:

  static struct thread_state GCALIGNED main_thread;

This looks like we ask main_thread to be 8-byte aligned, which would
bring back the problems we had before.  Requiring readers to read the
C Standard is not a good thing.

Can we come up with a clearer code, please?

> * Remove my_endbss_static in lastfile.c, since we no longer need to 
> worry about the Alpha MSVC linker.

I don't know anything about that code, and I don't think anyone does.
Who will tell us that the comment is still accurate?

> * Remove the the _MSC_VER-specific code in lisp.h's definitions of 
> ENUM_BF and DEFUN and in regex.c's definition of re_char and const_re_char.

I don't think ENUM_BF is only for MSVC.  The condition there mentions
other compilers.

Anything that is conditioned by _MSC_VER can go.





reply via email to

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