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

[Richard Copley <rcopley@gmail.com>]

On 2 November 2017 at 06:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
>> +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t),
>> GCALIGNMENT)
>> +
>> +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
>
> Three questions:
>
> The Gnulib manual
> <https://www.gnu.org/software/gnulib/manual/html_node/stdalign_002eh.html>
> says, "Some compilers require the operand of _Alignas/alignas to be a single
> integer constant, not an expression: MSVC 7.0 through at least 10.0." (Also,
> <https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro>
> suggests that this issue may also occur with VS2013, though VS2015 should be
> OK since it supports alignas.) Are any of these older compilers of concern
> when building Emacs?

I don't think so. How would one go about building Emacs with MSVC anyway?

>If so, the above change won't work for them.

> Why does the above code use 'alignof (max_align_t)' rather than 'alignof
> (struct thread_state)'? Doesn't the latter suffice?

For information, in the 64-bit GCC 7.2 toolchain from MinGW-W64, the two
are equal in value.

> C11 requires that a compiler must issue a diagnostic for a declaration like
> 'struct thread_state alignas (8) foo;' if the alignment of plain 'struct
> state' is greater than 8. Can I take it from this bug report that the
> Microsoft compilers do not conform to that part of the standard?

Microsoft compilers weren't mentioned at all. GCC didn't issue
a diagnostic.

> If so, we should add checks to verify this requirement where it is assumed elsewhere.

I think that is a good idea.

Thanks.