Warnings during building the current master on Win10 with MSYS2/MinGW64

Warnings during building the current master on Win10 with MSYS2/MinGW64

[Arash Esbati]

Hi all,

after a long time, I built Emacs (baf9f1210a) from master on my Win10
box and it occurred to me that I get more warnings than I used to.  This
is with

$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

It starts with (linebreaks added manually):

--8<---------------cut here---------------start------------->8---
boot-time-aux.h: In function 'get_windows_boot_time_fallback':
boot-time-aux.h:395:26: warning: the comparison will always evaluate as
                'true' for the address of 'GetTickCount64' will never be
                NULL [-Waddress]
  395 |   if (GetTickCount64Func != NULL)
      |                          ^~
In file included from C:/msys64/mingw64/include/winbase.h:36,
                 from C:/msys64/mingw64/include/windows.h:70,
                 from boot-time.c:48:
C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
   42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
      |                               ^~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

and goes on with:

--8<---------------cut here---------------start------------->8---
In file included from regex.c:69:
regex_internal.c: In function 'create_ci_newstate':
regex_internal.c:1599:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 1599 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
      |                                                ^~~~~~~~~~~~~
regex_internal.c:1599:48: note: earlier argument should specify number of elements, later size of each element
regex_internal.c: In function 'create_cd_newstate':
regex_internal.c:1647:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 1647 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
      |                                                ^~~~~~~~~~~~~
regex_internal.c:1647:48: note: earlier argument should specify number of elements, later size of each element
In file included from regex.c:70:
regcomp.c: In function 'init_dfa':
regcomp.c:834:38: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
  834 |   dfa->state_table = calloc (sizeof (struct re_state_table_entry), table_size);
      |                                      ^~~~~~
regcomp.c:834:38: note: earlier argument should specify number of elements, later size of each element
regcomp.c:865:60: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
  865 |           dfa->sb_char = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                                            ^~~~~~~~
regcomp.c:865:60: note: earlier argument should specify number of elements, later size of each element
regcomp.c: In function 'parse_bracket_exp':
regcomp.c:3058:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3058 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                              ^~~~~~~~
regcomp.c:3058:46: note: earlier argument should specify number of elements, later size of each element
regcomp.c:3059:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3059 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
      |                                             ^~~~~~~~~~~~
regcomp.c:3059:45: note: earlier argument should specify number of elements, later size of each element
regcomp.c: In function 'build_charclass_op':
regcomp.c:3551:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3551 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                              ^~~~~~~~
regcomp.c:3551:46: note: earlier argument should specify number of elements, later size of each element
regcomp.c:3557:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3557 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
      |                                             ^~~~~~~~~~~~
regcomp.c:3557:45: note: earlier argument should specify number of elements, later size of each element
In file included from regex.c:71:
regexec.c: In function 'get_subexp':
regexec.c:2724:47: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 2724 |               sub_top->path = calloc (sizeof (state_array_t),
      |                                               ^~~~~~~~~~~~~
regexec.c:2724:47: note: earlier argument should specify number of elements, later size of each element
regexec.c: In function 'build_trtable':
regexec.c:3269:29: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3269 |             calloc (sizeof (re_dfastate_t *), SBC_MAX);
      |                             ^~~~~~~~~~~~~
regexec.c:3269:29: note: earlier argument should specify number of elements, later size of each element
regexec.c:3341:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3341 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), SBC_MAX);
      |                                            ^~~~~~~~~~~~~
regexec.c:3341:44: note: earlier argument should specify number of elements, later size of each element
regexec.c:3372:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3372 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), 2 * SBC_MAX);
      |                                            ^~~~~~~~~~~~~
regexec.c:3372:44: note: earlier argument should specify number of elements, later size of each element
--8<---------------cut here---------------end--------------->8---

And others.  Is there an interest to see them all, should I post them
here or to the bug tracker?

I build Emacs with a small script like this:

--8<---------------cut here---------------start------------->8---
git clean -fdx --exclude=ChangeLog
./autogen.sh &&              \
CPPFLAGS='-DNDEBUG'          \
CFLAGS='-O2 -g0 -pipe'       \
LDFLAGS='-s -Wl,-s'          \
./configure                  \
--host=x86_64-w64-mingw32    \
--target=x86_64-w64-mingw32  \
--build=x86_64-w64-mingw32   \
--with-jpeg                  \
--with-gif                   \
--with-xpm                   \
--with-png                   \
--with-tiff                  \
--with-rsvg                  \
--with-webp                  \
--with-sqlite3               \
--with-xml2                  \
--with-gnutls                \
--with-lcms2                 \
--with-modules               \
--with-threads               \
--with-native-compilation    \
--with-native-image-api      \
--with-tree-sitter           \
--with-xdbe                  \
--without-imagemagick        \
--without-dbus               \
--without-gconf              \
--without-gsettings          \
--without-compress-install   \
--without-mailutils          \
--without-pop  &&            \
make  ...
--8<---------------cut here---------------end--------------->8---

Best, Arash

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> after a long time, I built Emacs (baf9f1210a) from master on my Win10
> box and it occurred to me that I get more warnings than I used to.  This
> is with
> 
> $ gcc --version
> gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

Sadly, the MS-Windows port of Emacs is basically not taken care of
anymore.  There are no active developers on board who seem to care
about it, except yours truly.  I see this in the (lack of) responses
to Windows-specific bugs and issues reported to the bug tracker: no
one chimes in, even if I deliberately leave a bug report without
responses for many days.  As my free time is severely limited, I only
care about aspects that affect me directly (and the 64-bit build and
GCC 14 are way outside that scope).

If no one comes forward and starts taking care of the MS-Windows
issues, I'm very close to the decision of declaring the Windows build
of Emacs "unsupported", meaning anyone who needs it are "on their
own", from my POV as the (co)maintainer.

This is not an April 1 joke: if there's a significant community
interested in being able to run and develop Emacs on MS-Windows,
someone should volunteer to take care of the build on a day to day
basis, or else the conclusion is that there's no general interest in
that platform among the Emacs community that is high enough to justify
the investment.

You _have_ been warned!

Re: Support for MS-Windows build of Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Sadly, the MS-Windows port of Emacs is basically not taken care of
> anymore.

Sad news, indeed.

> There are no active developers on board who seem to care about it,
> except yours truly.

Your work in that area was and is highly appreciated, of course.

> I see this in the (lack of) responses to Windows-specific bugs and
> issues reported to the bug tracker: no one chimes in, even if I
> deliberately leave a bug report without responses for many days.  As
> my free time is severely limited, I only care about aspects that
> affect me directly (and the 64-bit build and GCC 14 are way outside
> that scope).
>
> If no one comes forward and starts taking care of the MS-Windows
> issues, I'm very close to the decision of declaring the Windows build
> of Emacs "unsupported", meaning anyone who needs it are "on their
> own", from my POV as the (co)maintainer.

My impression is that the statement above also applies to the NS-port.

> This is not an April 1 joke: if there's a significant community
> interested in being able to run and develop Emacs on MS-Windows,
> someone should volunteer to take care of the build on a day to day
> basis, or else the conclusion is that there's no general interest in
> that platform among the Emacs community that is high enough to justify
> the investment.

I think there is a demand for Emacs on non-free systems, notably Windows
and macOS, so dropping the support isn't helpful.  But as you said, it
becomes a dead end if the official maintainers don't have the time
and/or willingness etc. to do the job there and no one else steps
forward.

> You _have_ been warned!

Thanks, I'm mostly on macOS nowadays, but that doesn't really mean
"problem solved".

Best, Arash

Re: Support for MS-Windows build of Emacs

[Po Lu]

Arash Esbati <arash@gnu.org> writes:

> My impression is that the statement above also applies to the NS-port.

That is correct, and is reflected in the condition of the NS port.

>> This is not an April 1 joke: if there's a significant community
>> interested in being able to run and develop Emacs on MS-Windows,
>> someone should volunteer to take care of the build on a day to day
>> basis, or else the conclusion is that there's no general interest in
>> that platform among the Emacs community that is high enough to justify
>> the investment.
>
> I think there is a demand for Emacs on non-free systems, notably Windows
> and macOS, so dropping the support isn't helpful.  But as you said, it
> becomes a dead end if the official maintainers don't have the time
> and/or willingness etc. to do the job there and no one else steps
> forward.

So let's hope that interested parties, having received this fair
warning, make their presence known.

Re: Support for MS-Windows build of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think there is a demand for Emacs on non-free systems, notably Windows
  > and macOS, so dropping the support isn't helpful.  But as you said, it
  > becomes a dead end if the official maintainers don't have the time
  > and/or willingness etc. to do the job there and no one else steps
  > forward.

Our primary goal is developing the GNU operating system.  Other
systems are inherently less important than that, and nonfree systems
even less so.  Given our limited resources, we have to do things this
way.

However, as long as people keep wanting to use Emacs on those nonfree
systems, I hope some of them will step forward and support Emacs there.

Is there a way we can encourage them to?  A good place to post?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Support for MS-Windows build of Emacs

[Arash Esbati]

Richard Stallman <rms@gnu.org> writes:

> Our primary goal is developing the GNU operating system.  Other
> systems are inherently less important than that, and nonfree systems
> even less so.  Given our limited resources, we have to do things this
> way.

I think this part should be crystal clear to everybody who enters the
scene here.

> However, as long as people keep wanting to use Emacs on those nonfree
> systems, I hope some of them will step forward and support Emacs there.
>
> Is there a way we can encourage them to?

I suggest to look back and ask what was the process until now that the
project is facing this situation.  It is hard to give a good answer
without knowing the past; and I'm not long enough around to have a good
judgement.  As a personal note, comments like[1]:

  It is useful for those interested in running Emacs on Losedows to test
  the MPS code on that system, but I request that we all join in
  refusing to refer to Microsoft Losedows as a "win".

don't sound encouraging for people the project is trying to recruit, at
least in my book.

> A good place to post?

I think emacs-devel is the right place.  Eli's last post is already
being noted; see the second link on this page[2].  So I suggest to post
a request for support here, the task and qualification needed, and let
others spread the word.  Let's see what happens then and take it from
there.

Best, Arash

Footnotes:
[1]  https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01204.html
[2]  https://sachachua.com/blog/2024/07/2024-07-29-emacs-news/

Re: Support for MS-Windows build of Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: eliz@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 30 Jul 2024 16:30:28 +0200
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > However, as long as people keep wanting to use Emacs on those nonfree
> > systems, I hope some of them will step forward and support Emacs there.
> >
> > Is there a way we can encourage them to?
> 
> I suggest to look back and ask what was the process until now that the
> project is facing this situation.

IMO, there's nothing to look at.  We used to have people here who were
both Emacs developers and used Emacs on Windows enough to care about
the port.  They have simply left, for reasons that AFAIR have nothing
to do with us or the way we do things here.

Re: Support for MS-Windows build of Emacs

[Juergen Fenn]

Am 30.07.24 um 18:03 Uhr schrieb Eli Zaretskii:
>>> However, as long as people keep wanting to use Emacs on those nonfree
>>> systems, I hope some of them will step forward and support Emacs there.
>>>
>>> Is there a way we can encourage them to?
>> I suggest to look back and ask what was the process until now that the
>> project is facing this situation.
> IMO, there's nothing to look at.  We used to have people here who were
> both Emacs developers and used Emacs on Windows enough to care about
> the port.  They have simply left, for reasons that AFAIR have nothing
> to do with us or the way we do things here.

I presume it's probably due to a change in the focus of interest from
one generation of developers to the next. What's more, there have been
many changes between macOS versions recently. It is a nuisance indeed to
deal with those because you keep constantly adapting to the next version
of macOS which keeps you from working on new features. I have been
watching this in the TeX Live project and the problems they had to deal
with for MacTeX. It could also be that free software is no longer as
attractive as it used to be when you mention it in the skills section of
your CV.

I suggest we spread the word as far as possible. Post it wherever you
can, blog about it, tell it on the social networks and listen to the
feedback. We could also host a session at EmacsConf.

I'm afraid there is little more that I could do because I feel a lot
like Tom in this thread. I'm not a developer, but I have been using
Emacs for over twenty years, first on Windows, and then and macOS, and I
cannot think of a different editor to use instead. I started using Emacs
when I wrote my dissertation thesis in NTEmacs with AUCTeX. So, your
statement that the non-free ports are mostly unmaintained indeed makes
me feel scared.

Best Regards,
Jürgen.

RE: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Tom Davey]

Eli Zaretskii writes: 

> This is not an April 1 joke: if there's a significant community interested in being able 
> to run and develop Emacs on MS-Windows, someone should volunteer to take care 
> of the build on a day to day basis, or else the conclusion is that there's no general 
> interest in that platform among the Emacs community that is high enough to justify 
> the investment.

More than one billion end-user computer systems run some version of Microsoft Windows. Emacs users on Windows usually have no say in their choice of an OS; the rules are set by their employers. 

Appendix H of the Emacs Info Manual expresses this sentiment -- "We support GNU Emacs on proprietary operating systems because we hope this taste of freedom will inspire users to escape from them." -- but this is not how corporate IT departments see the situation. Considerations of security, centralized management, and end-user support make Windows a hard requirement for tens of millions of desktops that could benefit from Emacs. 

Abandoning the behemoth that is Windows strikes me as self-defeating for Emacs. Nobody will get a "taste of freedom" if Emacs fails to provide it to Windows users in the first place.

I do not work as a computer programmer; my technical skills are infinitesimal compared to the people on this list. Emacs, for me, is a very powerful business tool for managing projects and tasks (via Org-mode) and an equally powerful tool for writing prose. I see it becoming my preferred client for generative AI as well. 

I support the Org-mode developers via an annual donation to Librepay. I would happily do the same to keep the Windows builds of Emacs on par with other OSes.

On my two computers, desktop and laptop, evaluating emacs-version() currently returns "GNU Emacs 29.3 (build 2, x86_64-w64-mingw32) of 2024-03-24". My heartfelt thanks to those who made and continue to make this possible. 

Eli, thank you for issuing the warning.

--
Tom Davey
tom@tomdavey.com
New York NY USA

-----Original Message-----
From: emacs-devel-bounces+tom=tomdavey.com@gnu.org <emacs-devel-bounces+tom=tomdavey.com@gnu.org> On Behalf Of Eli Zaretskii
Sent: Thursday, July 25, 2024 1:53 AM
To: emacs-devel@gnu.org
Cc: Arash Esbati <arash@gnu.org>
Subject: Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> after a long time, I built Emacs (baf9f1210a) from master on my Win10 
> box and it occurred to me that I get more warnings than I used to.  
> This is with
> 
> $ gcc --version
> gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

Sadly, the MS-Windows port of Emacs is basically not taken care of anymore.  There are no active developers on board who seem to care about it, except yours truly.  I see this in the (lack of) responses to Windows-specific bugs and issues reported to the bug tracker: no one chimes in, even if I deliberately leave a bug report without responses for many days.  As my free time is severely limited, I only care about aspects that affect me directly (and the 64-bit build and GCC 14 are way outside that scope).

If no one comes forward and starts taking care of the MS-Windows issues, I'm very close to the decision of declaring the Windows build of Emacs "unsupported", meaning anyone who needs it are "on their own", from my POV as the (co)maintainer.

This is not an April 1 joke: if there's a significant community interested in being able to run and develop Emacs on MS-Windows, someone should volunteer to take care of the build on a day to day basis, or else the conclusion is that there's no general interest in that platform among the Emacs community that is high enough to justify the investment.

You _have_ been warned!

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> boot-time-aux.h: In function 'get_windows_boot_time_fallback':
> boot-time-aux.h:395:26: warning: the comparison will always evaluate as
>                 'true' for the address of 'GetTickCount64' will never be
>                 NULL [-Waddress]
>   395 |   if (GetTickCount64Func != NULL)
>       |                          ^~
> In file included from C:/msys64/mingw64/include/winbase.h:36,
>                  from C:/msys64/mingw64/include/windows.h:70,
>                  from boot-time.c:48:
> C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
>    42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
>       |                               ^~~~~~~~~~~~~~

This should be reported to Gnulib folks, not here, as it's Gnulib
code.  (The warning is bogus, of course.)

> In file included from regex.c:69:
> regex_internal.c: In function 'create_ci_newstate':
> regex_internal.c:1599:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  1599 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
>       |                                                ^~~~~~~~~~~~~
> regex_internal.c:1599:48: note: earlier argument should specify number of elements, later size of each element
> regex_internal.c: In function 'create_cd_newstate':
> regex_internal.c:1647:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  1647 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
>       |                                                ^~~~~~~~~~~~~
> regex_internal.c:1647:48: note: earlier argument should specify number of elements, later size of each element
> In file included from regex.c:70:
> regcomp.c: In function 'init_dfa':
> regcomp.c:834:38: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>   834 |   dfa->state_table = calloc (sizeof (struct re_state_table_entry), table_size);
>       |                                      ^~~~~~
> regcomp.c:834:38: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:865:60: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>   865 |           dfa->sb_char = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                                            ^~~~~~~~
> regcomp.c:865:60: note: earlier argument should specify number of elements, later size of each element
> regcomp.c: In function 'parse_bracket_exp':
> regcomp.c:3058:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3058 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                              ^~~~~~~~
> regcomp.c:3058:46: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:3059:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3059 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
>       |                                             ^~~~~~~~~~~~
> regcomp.c:3059:45: note: earlier argument should specify number of elements, later size of each element
> regcomp.c: In function 'build_charclass_op':
> regcomp.c:3551:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3551 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                              ^~~~~~~~
> regcomp.c:3551:46: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:3557:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3557 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
>       |                                             ^~~~~~~~~~~~
> regcomp.c:3557:45: note: earlier argument should specify number of elements, later size of each element
> In file included from regex.c:71:
> regexec.c: In function 'get_subexp':
> regexec.c:2724:47: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  2724 |               sub_top->path = calloc (sizeof (state_array_t),
>       |                                               ^~~~~~~~~~~~~
> regexec.c:2724:47: note: earlier argument should specify number of elements, later size of each element
> regexec.c: In function 'build_trtable':
> regexec.c:3269:29: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3269 |             calloc (sizeof (re_dfastate_t *), SBC_MAX);
>       |                             ^~~~~~~~~~~~~
> regexec.c:3269:29: note: earlier argument should specify number of elements, later size of each element
> regexec.c:3341:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3341 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), SBC_MAX);
>       |                                            ^~~~~~~~~~~~~
> regexec.c:3341:44: note: earlier argument should specify number of elements, later size of each element
> regexec.c:3372:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3372 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), 2 * SBC_MAX);
>       |                                            ^~~~~~~~~~~~~
> regexec.c:3372:44: note: earlier argument should specify number of elements, later size of each element
> --8<---------------cut here---------------end--------------->8---

These are all correct, but again, they are about Gnulib code and
should be reported to the Gnulib mailing list.

> And others.  Is there an interest to see them all, should I post them
> here or to the bug tracker?

If the warnings are for Emacs's own sources, please submit a bug
report.  Gnulib-related warnings should be reported to the Gnulib
mailing list.

Thanks.

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Collin Funk]

Eli Zaretskii <eliz@gnu.org> writes:

>> C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
>>    42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
>>       |                               ^~~~~~~~~~~~~~
>
> This should be reported to Gnulib folks, not here, as it's Gnulib
> code.  (The warning is bogus, of course.)

I agree that it is bogus. Most Gnulib Windows modules will have this
warning. The code is something like:

-----------------------------------------------
# if !(_WIN32_WINNT >= _WIN32_WINNT_VISTA)

/* GetTickCount64 is only available on Windows Vista and later.  */
typedef ULONGLONG (WINAPI * GetTickCount64FuncType) (void);

/* NULL if not loaded from the DLL, else a function pointer.  */
static GetTickCount64FuncType GetTickCount64Func = NULL;
static BOOL initialized = FALSE;

# else /* No need to load DLL.  */

#  define GetTickCount64Func GetTickCount64

# endif
-----------------------------------------------

In the 'else' case the warning is triggered since it is just the
function symbol not a pointer to it.

I'm not sure if this idiom came before that warning existed or something
else. In any case if the compiler is smart enough to warn about it then
it is probably smart enough to optimize the check out.

Collin

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> If the warnings are for Emacs's own sources, please submit a bug
> report.  Gnulib-related warnings should be reported to the Gnulib
> mailing list.

Thanks, will do so.

Best, Arash

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Kepa]

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

> (and the 64-bit build and
GCC 14 are way outside that scope).

Hi Eli

Do you mean that 32-bit version would be maintained?

If no Windows OS would be maintained, I hope we could survive for decades with the last stable version of emacs.

Best regards

[-- Attachment #2: Type: text/html, Size: 963 bytes --]

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Eli Zaretskii]

> Date: Mon, 5 Aug 2024 16:48:42 +0000 (UTC)
> From: Kepa <gnu.cognition199@slmails.com>
> 
> > (and the 64-bit build and 
> GCC 14 are way outside that scope). 
> 
> Hi Eli 
> 
> Do you mean that 32-bit version would be maintained? 

As long as I'm actively use it, I will keep it working, yes.  I cannot
efficiently participate in Emacs development without having a
buildable, workable Emacs.

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Kepa]

Hi, Eli

Not sure if I am understanding.
That 32-bit emacs is for Windows?

Why is it not available here? (Or maybe I can't see it):
https://ftp.gnu.org/gnu/emacs/windows/emacs-29/

Best regards

From: eliz at gnu.org <aurrusoegbxgvaaexpqkbkv@simplelogin.co>
To: Kepa <gnu.cognition199@slmails.com>
CC: emacs-devel at gnu.org <jyjpyecdwzmdxrbazqiktimtfggvphuzawfdwxukshy@simplelogin.co>
Date: 2024-08-05T17:42:14Z
Subject: Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

>> Date: Mon, 5 Aug 2024 16:48:42 +0000 (UTC)
>> From: Kepa <gnu.cognition199@slmails.com>
>> 
>>> (and the 64-bit build and
>> GCC 14 are way outside that scope).
>> 
>> Hi Eli
>> 
>> Do you mean that 32-bit version would be maintained?
> 
> As long as I'm actively use it, I will keep it working, yes.  I cannot
> efficiently participate in Emacs development without having a
> buildable, workable Emacs.

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Corwin Brust]

On Mon, Aug 5, 2024 at 3:49 PM Kepa <gnu.cognition199@slmails.com> wrote:
>
> Hi, Eli
>
> Not sure if I am understanding.
> That 32-bit emacs is for Windows?

Yes, I believe Eli is referring to 32x builds of Emacs that he makes
for his own use.

>
> Why is it not available here? (Or maybe I can't see it):
> https://ftp.gnu.org/gnu/emacs/windows/emacs-29/

I make the binaries for Windows currently which you find at the above
link.  I don't currently publish any x32 bit versions because I'm
having cross-compile thiem on an x64 machine and I don't have a x32
bit machine running Windows that I could use to test them.  I'm
willing to do it; however, so far I have not had many requests.  (I
think you might be the first person to mention absence of x32 builds
for Windows since we stopped making them a year or three ago.)

Kind regards,
Corwin

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Mon, 5 Aug 2024 19:02:54 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > Why is it not available here? (Or maybe I can't see it):
> > https://ftp.gnu.org/gnu/emacs/windows/emacs-29/
> 
> I make the binaries for Windows currently which you find at the above
> link.  I don't currently publish any x32 bit versions because I'm
> having cross-compile thiem on an x64 machine and I don't have a x32
> bit machine running Windows that I could use to test them.  I'm
> willing to do it; however, so far I have not had many requests.  (I
> think you might be the first person to mention absence of x32 builds
> for Windows since we stopped making them a year or three ago.)

Let me remind you that we discussed this at some point and decided
that since everyone uses a 64-bit system nowadays, offering just the
64-bit build should be enough.

There's no advantage to a 32-bit build produced using MinGW64 over a
64-bit build produced by the same toolchain, only disadvantages.

So I don't think it is worth your time and efforts to produce also a
32-bit build.

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Corwin Brust]

On Tue, Aug 6, 2024 at 6:38 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> There's no advantage to a 32-bit build produced using MinGW64 over a
> 64-bit build produced by the same toolchain, only disadvantages.
>
> So I don't think it is worth your time and efforts to produce also a
> 32-bit build.
>

Thank you for the reminders.  FWIW, I am in complete agreement.  I'm
willing to make x32 builds but I see little point; especially, there
seems little point in building them currently with MINGW64 (as I
believe Phil had been doing).

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Eli Zaretskii]

> Date: Mon, 5 Aug 2024 20:49:42 +0000
> From: Kepa <gnu.cognition199@slmails.com>
> Cc: emacs-devel@gnu.org
> 
> Hi, Eli
> 
> Not sure if I am understanding.
> That 32-bit emacs is for Windows?

Yes.

> Why is it not available here? (Or maybe I can't see it):
> https://ftp.gnu.org/gnu/emacs/windows/emacs-29/

Because I'm not aware there's significant demand for a 32-bit build
these days, when almost everyone is running a 64-bit system.

If you still insist on using my build, you can find it here:

  https://sourceforge.net/projects/ezwinports/files/

But I didn't bother uploading Emacs 29 there, because I see very few
downloads of that port.

I think there's a misunderstanding here: this thread is not about
32-bit vs 64-bit build of Emacs; they both work the same AFAIK.  This
thread is about supporting _any_ Windows port of Emacs, and also about
making the UCRT build (as opposed to MSVCRT build, which is what I use
here) officially supported by the GNU project.

So the fact that I use a 32-bit build environment has only a very
tangential relevance to this thread: it explains why it is harder for
me personally to be the one who supports these builds.  But it would
have been hard enough even without this additional aspect.

IOW, you've taken a side issue which came up in this discussion and
made it the main issue.  It isn't.