I think it is not very much work to implement. Perhaps I will submit a
draft PR for your review.
On 3/24/2021 9:34 AM, Matias N. wrote:
Yes, you're right, TLS is the way to go.
I only wonder how to minimize the impact. Could this array inside the TLS
struct be grown as needed during runtime? That way if no application calls to
getopt() (or any other function requiring similar solution), no extra space on
TLS is used.
On Wed, Mar 24, 2021, at 12:32, Gregory Nutt wrote:
Se we can either add something special just as for errno or use
entries in that array (which would require establishing a minimum
number of entries to satisfy the case of getopt en potentially
others). I think it is better to somehow "reserve" space for the
known required cases.
What i'm worried about is: how many other cases like this there could
be? Maybe there will be a considerable number of this entries added
to TLS structure (yes, four bytes, but they can add up quickly). I
would personally prefer to use reentrant versions when they are
available, instead of increasing memory use of every thread. Not sure
what is really best here...
Standardization is certainly the highest value of the OS and the thing
that makes NuttX what it is. Sacrificing standardization sacrifices
the core value of the OS.
Standardization supports portability. If we bring in code from Linux,
it will not use getopt_r(), it will use getopt() or getopt_long() and
may not work as expected without the TLS-based change. Similarly, if we
write applications that depend on the non-standard getop_r(), that code
will not compile or build under Linux. We will have lost portability.
Many people support code components that operate under either Linux or
NuttX and they depend on having this compatibility. Why break it? It
is not consistent with the principles set out in INVIOLABLES.md
