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 > > > >
