This set of modules implements the function tolower_l, toupper_l
for all platforms.
2025-02-16 Bruno Haible
toupper_l: Add tests.
* tests/test-toupper_l.c: New file, based on tests/test-c32toupper.c.
* modules/toupper_l-tests: New file.
toupper_l: New module.
Mitch Capper wrote:
> I am not sure
> how one just tests of a gnulib polyfill is being used.
There are two general mechanisms that Gnulib offers:
* #if GNULIB_
tests whether the module is in use.
* #if GNULIB_defined_
#if GNULIB_overrides_
are available for a few selected types a
Mitch Capper wrote:
> *Gating w/ CYGWIN support*
> While I have gone back and tried to gate the changes with proper windows
> only checks I generally use #ifdef _WIN32 and I don't know the effect
> that would have on other windows systems (ie cygwin). It might mean code
> that could work is ski
Mitch Capper wrote:
> *With Path accidental separator detection*
> The windows path branch tries to add either forward or backward path
> separator support in windows. Clearly \ is also the escape char so it is
> possible that there are places that A) windows paths that have escape chars
> used w
Mitch Capper wrote:
> *Build colorization*
> The build-aux compile/ar-lib debug/colorization patching is hacky and
> non-standard. While I have found it quite useful to just be able to turn
> an ENV var on to have debug logging probably should be done as a parameter
> instead. Downside of a para
Mitch Capper wrote:
> *Windows Security / Permissions*
> The no-op permissions/getuser/group branch is poor. Windows permissions are
> not considered at all, and all permission calls just silently succeed. Any
> user calls return the current user and group calls return a generic string.
> In addit
Mitch Capper wrote:
> *Excess Commits / proper gnu submission*
> As I have been at this for awhile while the branches are often rebased on
> top of master they have far more commits than required. If these things
> are for inclusion into the main repo certainly I can reduce it down to
> single fe
Mitch Capper wrote:
> > In Gnulib, we use
> > #if defined _WIN32 && !defined __CYGWIN__
>
> If I understand correctly anywhere I am using _WIN32 I should update it to
> this dual check as cygwin may have this _WIN32 definition but it should be
> treated not as _WIN32.
Yes.
> > Yes, that's an ad
Mitch Capper wrote:
> It is true that Windows historically hasn't had great symbolic and hard
> linking api's / compatibility but the largest barriers were largely removed
> back in 2016 with all in-support versions of Windows having full symbolic
> link support without any special developer option
Thanks Bruno for such detailed notes. I will start to work on cleaning up
the patches to prep for the mailing list.
> When a package has complicated fork/exec logic, generally it's advisable
to
> use the posix_spawn facility when possible. This provides not only
portability
> to native Windows; i
Hello Mitch,
> I have been working on a high level of windows compatibility for several
> GNU and other related open source software without the traditional
> emulation layers/mingw requirements. Overall it has had great success in
> my mind, multiple dozens of GNU related packages compiled from
11 matches
Mail list logo
