Re: new module 'tzname', tm_zone and tm_gmtoff

Paul Eggert wrote: > > tzname is used in three places: > >- time_rz, > > This should be fixed to use strftime instead. This seems wrong for two reasons: * time_rz is a small module, without textual I/O. strftime is a large module, doing string formatting. If time_rz depends on strf

Re: platforms without

Hi Eli, Eli Zaretskii writes: > Since this was brought up (and comes up from time to time), and since > Collin here is listening as well, let me explain the issues we have > with Gnulib in Emacs on MS-Windows. > > The main point to keep in mind is that Emacs is still striving to > support very o

Re: continuous integration for many platforms

On Thu, Jun 6, 2024 at 5:34 PM Bruno Haible wrote: > > The continuous integration of Gnulib for many platforms is now operational. > Congrats. That is a great accomplishment. Jeff

Re: new module 'tzname', tm_zone and tm_gmtoff

On 6/6/24 14:30, Bruno Haible wrote: tzname is used in three places: - time_rz, This should be fixed to use strftime instead. - parse-datetime, Likewise. (This usage of tzname is simply wrong, by the way, but it can be compatibly wrong.) - nstrftime, c-nstrftime. These are

continuous integration for many platforms

The continuous integration of Gnulib for many platforms is now operational. It tests a testdir of nearly all modules of Gnulib on the following platforms: - Ubuntu GNU/Linux 22.04 - CentOS 7 - Alpine Linux - macOS 11, 12, 13 (all x86

Re: new module 'tzname', tm_zone and tm_gmtoff

Paul Eggert wrote: > * Don't make tzname a module, as this mistakenly suggests that tzname is > useful. Instead, leave tzname's implementation as internal detail of the > nstrftime and c-nstrftime modules. This should be easy. > > * Since tzname should be an internal detail, Gnulib can still use

Re: new module 'tzname'

Some suggestions for improvement: * Don't make tzname a module, as this mistakenly suggests that tzname is useful. Instead, leave tzname's implementation as internal detail of the nstrftime and c-nstrftime modules. This should be easy. * Since tzname should be an internal detail, Gnulib can s

Re: tzname, daylight, timezone: Update documentation

Hi Eric, > You should also document that POSIX will be recommending that you > avoid these three globals, because they do not work with > location-based TZ settings (standardized in the soon-to-be-released > POSIX Issue 8): > > https://austingroupbugs.net/view.php?id=1816 Thanks for the pointer.

Re: tzname, daylight, timezone: Update documentation

On Thu, Jun 06, 2024 at 08:36:05PM GMT, Bruno Haible wrote: > This patch updates the documentation regarding the three variables > tzname > daylight > timezone > that are supposed to be set by tzset(). > > OpenBSD ≥ 5.8 supports these variables, but FreeBSD - to this day - > supports only 't

new module 'tzname'

On MSVC, the nstrftime and c-nstrftime tests fail, because the %Z directive produces an empty string instead of a time zone abbreviation. The cause is that strftime.c contains code for two cases: - HAVE_STRUCT_TM_TM_ZONE - HAVE_TZNAME but on MSVC both macros are undefined, since MSVC has '_tzn

tzname, daylight, timezone: Update documentation

This patch updates the documentation regarding the three variables tzname daylight timezone that are supposed to be set by tzset(). OpenBSD ≥ 5.8 supports these variables, but FreeBSD - to this day - supports only 'tzname'. On MSVC, these variables are not really missing; they just have a d

Re: Emacs portability requirements

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, collin.fu...@gmail.com, bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 17:39:46 +0200 > > Thanks, Eli. Everything is clear now (from my side). Glad I could help. > We will be able to avoid that Gnulib destabilizes Emacs, better than > we could in the

Re: Emacs portability requirements

Thanks, Eli. Everything is clear now (from my side). We will be able to avoid that Gnulib destabilizes Emacs, better than we could in the past. Bruno

Re: Emacs portability requirements

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, collin.fu...@gmail.com, bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 16:58:44 +0200 > > > Windows 9X in general don't have any _w* "wide" functions, and need to > > use UNICOWS.DLL to do so. > > You're confusing me now. I see many _w* "wide" function

Re: Emacs portability requirements

Hi Eli, > > 1) > > > On Windows 9X > > > Emacs loads the UNICOWS.DLL shared library at startup to be able to > > > use some functions ... > > > > Can the source code call the functions of UNICOWS.DLL directly, or > > do these functions all need to be call via pointers obtained via > > GetProcAdd

Re: Emacs portability requirements

> From: Bruno Haible > Cc: Paul Eggert , Collin Funk , > bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 09:47:30 +0200 > > 1) > > On Windows 9X > > Emacs loads the UNICOWS.DLL shared library at startup to be able to > > use some functions ... > > Can the source code call the functions of UNICOWS.

Re: Emacs portability requirements

Hi Eli, Thanks for explaining. Four more questions: 1) > On Windows 9X > Emacs loads the UNICOWS.DLL shared library at startup to be able to > use some functions ... Can the source code call the functions of UNICOWS.DLL directly, or do these functions all need to be call via pointers obtained v