[gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On 10 Nov 2015 18:53, Mike Frysinger wrote:
> i randomly stumbled across an ebuild that was using ^^ to make a variable
> uppercase.  this is new to bash-4.0 and thus invalid for EAPI=[0-5].  only
> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.

Arfrever highlights these are not even safe to use.  bash is locale aware,
so it'll apply LC_COLLATE rules when processing the ^/, casemods.  while
you can fix this with external programs ala:
	LC_COLLATE=C tr ...

you can't do it with inline code like:
	LC_COLLATE=C SRC_URI=".../${PN^^}/..."

you can if you do something like:
	SRC_URI=".../$(LC_COLLATE=C; echo "${PN^^}")/..."

but at this point, you lose most (all?) advantage to using these in the first
place: nice & tight code.  not running tr in global scope is nice too, but it's
better all around to just hardcode something like:
	MY_PN="APINGER"
and be done with it.

thoughts ?  we could add a repoman check to detect & reject usage of it, and
for the cases where the value isn't a constant, we could add a safe helper to
eutils like:
	tolower() { LC_COLLATE=C tr '[:upper:]' '[:lower:]'; }
	toupper() { LC_COLLATE=C tr '[:lower:]' '[:upper:]'; }

yes, i'm aware that this runs the risk of mojibake when given some UTF-8
strings, but we already have that problem, and i don't think the uses so
far will hit it (as people generally feed USE flags and PN values).  it
would require the C.UTF-8 locale to address.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]