That doesn't help. Either library code is unaware of the numbered locale, and
so has no way of getting access to thread-local storage, or it is aware of the
numbered locale, in which case you have to pass it around everywhere which is
annoying. I didn't mean to imply that anyone would be forging pointers to
locales.
On Thu, 9 Jun 2022, Raul Miller wrote:
On Thu, Jun 9, 2022 at 5:53 AM Elijah Stone <elro...@elronnd.net> wrote:
I maintain--masochistically, perhaps :)--that the correct approach to language
design is 'punish the implementors'.
The issue with putting some 'tls' locale in the search path is that it is
anti-modular. If everybody has to share that one locale for tls
data--somehow; coordinating that is probably also difficult, though I am no
locale expert and don't love the mechanism--then there is the possibility of
name collisions--exactly the problem that locales are supposed to solve (and
which my approach solves)!
The convention here is that numbered locales are considered "off
limits" for general purpose code that was not specifically informed of
their existence.
This is not "cryptographically secure" but that sort of "hostile
environment" thing is not the sort of problem we're trying to solve
here.
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
