Omar Polo wrote (2022-06-29 10:12 CEST):
> +cc kirby@ (maintainer)
>
> Stefan Hagen <sh+openbsd-ports@codevoid.de> wrote:
> > Abel Abraham Camarillo Ojeda wrote (2022-06-20 08:24 CEST):
> > > [...]
> > >
> > > I now applied the patch correctly, I can no longer reproduce the issue.
> > >
> > > upstream seems unresponsive about this, any chance of getting it on ports?
> >
> > The one that rips out all setlocale calls? No.
> >
> > Here is a better diff, which replaces the setlocale(3) calls with thread
> > local (and therefore thread-safe) uselocale(3) calls.
> >
> > I'm still testing this, because it is not exactly the same as the original.
> >
> > If it improves the situation on OpenBSD, I'm not opposed to commit these
> > patches. Please test and report back.
>
> I don't use rawtherapee, and my understanding of the locale api is
> (voluntarely) scarse, but I'm not sure the patch is right.
>
> On OpenBSD there shouldn't be issue, because freelocale (AFAIU) is a
> no-op, but on other OSes you need to free the locale returned by
> newlocale or duplocale.
In expanded form we have:
locale_t oldloc = duplocale(LC_GLOBAL_LOCALE);
locale_t modloc = newlocale(LC_NUMERIC_MASK, "C", oldloc);
locale_t newloc = uselocale(modloc);
I think we could:
locale_t oldloc = duplocale(LC_GLOBAL_LOCALE);
locale_t modloc = newlocale(LC_NUMERIC_MASK, "C", oldloc);
freelocale(oldloc);
locale_t newloc = uselocale(modloc);
freelocale(modloc);
From our uselocale(3) manpage:
The current thread uses newloc until uselocale() is called again
successfully with a non-null argument in the same thread, and
passing newloc to freelocale(3) or newlocale(3) before that results
in undefined behaviour.
I think calling freelocale(newloc) at this point would result in
undefined behavior.
Best Regards,
Stefan
> See (but not too closely!) the example from the GNU man page for
> newlocale:
>
> https://man.voidlinux.org/newlocale
>
> so the patch may be OK for us, but not to fed it to upstream.
No comments:
Post a Comment