bug-gnulib
[Top][All Lists]
Advanced

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

Re: localename: Fix gettext test failures on mingw


From: Eli Zaretskii
Subject: Re: localename: Fix gettext test failures on mingw
Date: Sun, 25 Nov 2018 20:50:11 +0200

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Sun, 25 Nov 2018 19:27:44 +0100
> 
> > I think it's important to share my experience here, ...
> > The problems I describe are not theoretical, I actually bumped into
> > them when porting Guile 2.0.x.
> 
> Ah, I wasn't aware that you were describing a problem. What was the
> problem that you encountered with Guile? You say:
> 
> > It defines symbols based on LC_MESSAGES and exposes them
> > to Scheme.
> 
> What was the problem with that? Since guile is based on the
> platform's runtime + gnulib, not the platform's runtime alone,
> what issue actually arose?

It's still based on platform runtime, since setlocale eventually goes
to libc.

I don't remember the details, it was a long time ago.  I just know
that I needed to disable LC_MESSAGES that crept in with gettext.h (I
think you should be able to see that change in the current Guile
sources).  I don't know if I will have time to reproduce all those
problems and describe the details to you.  The i18n module of Guile
and its test suite was a major headache, that much I remember.

> > There were also other issues.  One of them, AFAIR, was that
> > LC_MESSAGES was defined to a large arbitrary value, but LC_MAX was not
> > updated to cover that
> 
> LC_MAX is not a macro that should be visible to Guile users, since it
> is platform-dependent.

I didn't say it was either.  I'm saying that code which expects any
LC_* value to be between LC_MIN and LC_MAX might be surprised if
Gnulib's LC_MESSAGES is used.

> > Instead, applications that
> > need these facilities should adapt according to their needs by using
> > the Windows native facilities.
> 
> There is and will always be a debate whether a language implementation
> (like Guile, but the same applies to C and CLISP) should tend to offer
> APIs closer to the platform's particularities or closer to platform-
> independent standards like POSIX. As you can see, my opinion is on the
> "closer to platform-independent standards" side.

Mine too, but we are the minority around here.  Just look at the APIs
provided by libguile.



reply via email to

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