Including <locale.h> unconditionally in Emacs

Including <locale.h> unconditionally in Emacs

[Paul Eggert]

<locale.h> was standardized in C89, and all C platforms in current use 
have it, if only to supply a dummy implementation with only a C locale. 
However, the Emacs C source code currently attempts to port to platforms 
lacking <locale.h> with code like this (though details vary):

  #ifdef HAVE_SETLOCALE
  # include <locale.h>
  #endif

This sort of code dates back to the 1990s when some older platforms 
predating C89 support presumably lacked <locale.h> and setlocale.

As Emacs surely long ago stopped porting to platforms so obsolete that 
they lack <locale.h>, I assume it would be OK for Emacs to start 
including <locale.h> unconditionally. I thought I'd ask here first, 
though, just to make sure.

This topic came up on the Gnulib mailing list, since Emacs uses Gnulib 
modules that currently have code to work around the absence of 
<locale.h>, code that is a bit of a hassle and that we'd rather stop 
maintaining and that is present only because Emacs uses those modules. 
You can see the Gnulib thread here:

https://lists.gnu.org/r/bug-gnulib/2024-06/msg00057.html

Re: Including <locale.h> unconditionally in Emacs

[Eli Zaretskii]

> Date: Wed, 5 Jun 2024 13:18:42 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> <locale.h> was standardized in C89, and all C platforms in current use 
> have it, if only to supply a dummy implementation with only a C locale. 
> However, the Emacs C source code currently attempts to port to platforms 
> lacking <locale.h> with code like this (though details vary):
> 
>   #ifdef HAVE_SETLOCALE
>   # include <locale.h>
>   #endif
> 
> This sort of code dates back to the 1990s when some older platforms 
> predating C89 support presumably lacked <locale.h> and setlocale.
> 
> As Emacs surely long ago stopped porting to platforms so obsolete that 
> they lack <locale.h>, I assume it would be OK for Emacs to start 
> including <locale.h> unconditionally. I thought I'd ask here first, 
> though, just to make sure.

I think this is okay as far as modern Posix systems, MS-Windows and
even MS-DOS are concerned, but I'd like to hear from Po Lu wrt the
Andriod port, as I'm not familiar with the situation there.  I think
Po Lu also builds Emacs on some ancient Solaris version, so maybe
there's an issue there?  And what about macOS?

In any case, please don't make this change in Emacs until after the
emacs-30 release branch is cut (which should happen soon).  And if the
Gnulib folks are going to make that change in Gnulib now, it means we
will have one more reason not to import from Gnulib before the branch
point.

Thanks.

Re: Including <locale.h> unconditionally in Emacs

[Paul Eggert]

On 2024-06-05 21:53, Eli Zaretskii wrote:

> I'd like to hear from Po Lu wrt the
> Andriod port, as I'm not familiar with the situation there.  I think
> Po Lu also builds Emacs on some ancient Solaris version, so maybe
> there's an issue there?  And what about macOS?

None of these are real issues. Android has had locale.h since day 1. 
Even ancient, ancient SunOS has it and besides, there's no point porting 
to anything older than Solaris 10 aka SunOS 5.10 (the oldest supported 
version). macOS has had it "forever" too.


> please don't make this change in Emacs until after the
> emacs-30 release branch is cut (which should happen soon).

Of course.


> we
> will have one more reason not to import from Gnulib before the branch
> point.

I can sync from Gnulib into the master branch after "soon" happens, and 
then people can copy those fixes into the emacs-30 branch if and when 
they feel the need. There's no rush. I wouldn't have even bothered to 
sync from Gnulib recently, except that somebody reported a 
Gnulib-related bug on the master branch.

Re: Including <locale.h> unconditionally in Emacs

[Eli Zaretskii]

> Date: Wed, 5 Jun 2024 22:44:39 -0700
> Cc: Emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-06-05 21:53, Eli Zaretskii wrote:
> 
> > I'd like to hear from Po Lu wrt the
> > Andriod port, as I'm not familiar with the situation there.  I think
> > Po Lu also builds Emacs on some ancient Solaris version, so maybe
> > there's an issue there?  And what about macOS?
> 
> None of these are real issues. Android has had locale.h since day 1. 
> Even ancient, ancient SunOS has it and besides, there's no point porting 
> to anything older than Solaris 10 aka SunOS 5.10 (the oldest supported 
> version). macOS has had it "forever" too.

Then I think we are good to go in this matter.

> > we
> > will have one more reason not to import from Gnulib before the branch
> > point.
> 
> I can sync from Gnulib into the master branch after "soon" happens, and 
> then people can copy those fixes into the emacs-30 branch if and when 
> they feel the need. There's no rush. I wouldn't have even bothered to 
> sync from Gnulib recently, except that somebody reported a 
> Gnulib-related bug on the master branch.

Right, thanks.

Re: Including <locale.h> unconditionally in Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 5 Jun 2024 22:44:39 -0700
>> Cc: Emacs-devel@gnu.org
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> 
>> On 2024-06-05 21:53, Eli Zaretskii wrote:
>> 
>> > I'd like to hear from Po Lu wrt the
>> > Andriod port, as I'm not familiar with the situation there.  I think
>> > Po Lu also builds Emacs on some ancient Solaris version, so maybe
>> > there's an issue there?  And what about macOS?
>> 
>> None of these are real issues. Android has had locale.h since day 1. 
>> Even ancient, ancient SunOS has it and besides, there's no point porting 
>> to anything older than Solaris 10 aka SunOS 5.10 (the oldest supported 
>> version). macOS has had it "forever" too.
>
> Then I think we are good to go in this matter.
>
>> > we
>> > will have one more reason not to import from Gnulib before the branch
>> > point.
>> 
>> I can sync from Gnulib into the master branch after "soon" happens, and 
>> then people can copy those fixes into the emacs-30 branch if and when 
>> they feel the need. There's no rush. I wouldn't have even bothered to 
>> sync from Gnulib recently, except that somebody reported a 
>> Gnulib-related bug on the master branch.
>
> Right, thanks.

Paul is correct, though if any Gnulib code relies on locale.h's being
useful rather than merely present during compilation, there will be
difficulties on Android 4.4 and earlier.  In general, there's no rhyme
or reason to the inexplicable decisions to exclude functions from
Android's libc, which might be obscure functions introduced in recent
POSIX standards one day, but as easily established functions the next,
getpwent being the "type specimen", so to speak.

On another note, where is this code of ours that is allegedly
conditioned on HAVE_LOCALE_H?  If there is any, I can't find it.

Re: Including <locale.h> unconditionally in Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> On another note, where is this code of ours that is allegedly
> conditioned on HAVE_LOCALE_H?  If there is any, I can't find it.

Grep for HAVE_SETLOCALE.

Re: Including <locale.h> unconditionally in 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. ]]]

  > As Emacs surely long ago stopped porting to platforms so obsolete that 
  > they lack <locale.h>, I assume it would be OK for Emacs to start 
  > including <locale.h> unconditionally. I thought I'd ask here first, 
  > though, just to make sure.

Maybe it is fine nowadays to stop supporting the old systems that lack
locale.h.  I gather they were in use 30 years ago.

But in general I have the feeling that there is a tendency in parts of
our community to drop support for old systems too fast.  For instance,
Coreboot has dropped support for the last server board that doesn't
have the Intel Management Engine.  You can still buy them, and that's
the model the FSF uses.

So let's stay cautious about this.

-- 
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: Including <locale.h> unconditionally in Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: Emacs-devel@gnu.org
> Date: Fri, 07 Jun 2024 22:54:09 -0400
> 
> But in general I have the feeling that there is a tendency in parts of
> our community to drop support for old systems too fast.  For instance,
> Coreboot has dropped support for the last server board that doesn't
> have the Intel Management Engine.  You can still buy them, and that's
> the model the FSF uses.
> 
> So let's stay cautious about this.

We are, at least in this project.  Some say we are too cautious.

Re: Including <locale.h> unconditionally in 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. ]]]

  > > But in general I have the feeling that there is a tendency in parts of
  > > our community to drop support for old systems too fast....
  > > 
  > > So let's stay cautious about this.

  > We are, at least in this project.  Some say we are too cautious.

If we are cautious enough, there will surely be people who say that.

-- 
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: Including <locale.h> unconditionally in Emacs

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: Emacs-devel@gnu.org
>> Date: Fri, 07 Jun 2024 22:54:09 -0400
>> 
>> But in general I have the feeling that there is a tendency in parts of
>> our community to drop support for old systems too fast.  For instance,
>> Coreboot has dropped support for the last server board that doesn't
>> have the Intel Management Engine.  You can still buy them, and that's
>> the model the FSF uses.
>> 
>> So let's stay cautious about this.
>
> We are, at least in this project.  Some say we are too cautious.

IMHO the recent discussion around fixing Windows 9x support has shown
that.

Re: Including <locale.h> unconditionally in Emacs

[Stefan Kangas]

Paul Eggert <eggert@cs.ucla.edu> writes:

>> please don't make this change in Emacs until after the
>> emacs-30 release branch is cut (which should happen soon).
>
> Of course.

I suppose this change could go in now.

Re: Including <locale.h> unconditionally in Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 23 Jun 2024 05:32:14 -0700
> Cc: Emacs-devel@gnu.org
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> >> please don't make this change in Emacs until after the
> >> emacs-30 release branch is cut (which should happen soon).
> >
> > Of course.
> 
> I suppose this change could go in now.

Fine by me.  But please wait for a day, as I'd first would like to see
if the new master branch and the release branch build okay, or whether
there are some problems.  Let's install the locale.h change after we
know there are no build problems without it.