Great, thanks! I was just writing an issue to have this noted somewhere. Best, Matias
On Wed, Mar 24, 2021, at 13:23, Gregory Nutt wrote: > 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 > >> > >> > >> > >> > >
