[FFmpeg-devel] [PATCH] Adds support parsing the QuickTime Metadata Keys.

[wm4]

On Sun, 25 Oct 2015 12:39:08 +0100
Nicolas George <george at nsup.org> wrote:

> Le quartidi 4 brumaire, an CCXXIV, Derek Buitenhuis a écrit :
> > Perhaps wm4 or Michael or someone can chime in... I don't know of a single good
> > way to handle this. Just failing if the locale has a radix point as a comma instead
> > of a period seems less bad than mucking with the thread/process locale inside a
> > library.  
> 
> Personally, I consider that users setting locale variables other than
> LC_CTYPE and LC_MESSAGES mean literally "please break random programs on my
> system"; I am convinced of this since more than fifteen years when initing
> Gtk in the OCaml toplevel would cause "let pi = 3.14" to set pi to 3.0.

Well, I'm not sure if this only affects LC_NUMERIC and maybe LC_COLLATE?

On the other hand, setting LC_CTYPE could have some bad effects too.

> Therefore, my opinion on this is: let us document that for all FFmpeg
> libraries, setting any locale except these two to anything other than
> C/POSIX yields undefined behaviours.

I'd be fine with that, but then we should maybe check the current
locale for sanity at certain points, and raise a clear error if it's
broken.

Many programs set locale by default, including GUI toolkits like Qt (!).
Qt in particular document this explicitly:

http://doc.qt.io/qt-5/qcoreapplication.html#locale-settings

So we shouldn't silently break everything. But again, breaking loudly
is ok IMHO.

> If people want to write applications using various locales, they should use
> the version with explicit locale argument introduced in the latest version
> of the standard.

You could demand the same from FFmpeg. It's impractical because not all
systems support these functions.

PS:

I think we don't need to block the patch on this issue anymore, because:
1. We don't have any workarounds in place this patch could use,
2. Lots of other code is probably affected anyway