codebje commented on pull request #3170: URL: https://github.com/apache/incubator-nuttx/pull/3170#issuecomment-806371713
> > btw, strictly speaking, this should be per-process (task group?) instead of per-thread. > > probably it doesn't matter for usual usage patterns of this api though. > > Yes, but since only the main thread has argc and argv it is kind of hard coming up with a scenario where a pthread would call getopt(). Certainly, you could design a thread that does that. It is just not something you would expect to see often. Some other variables in libc will need to be per-process: the syslog mask, the umask, and potentially timezone settings. Some will benefit from being per-thread: strtok(), getpwnam(), gethostbyname() etc. For getopt it might not matter, but being thread-safe isn't required to be standards compliant anyway. > to me, it seems impossible to support the api properly in flat memory model. > it might be possible to resolve it with some fancy compiler or linker features. > but i guess it isn't something we want to do either. I don't think there's trickery that can be done with a linker. The compiler will output something more or less equivalent to `mov optind, %eax` to read the value for `extern int optind`. The linker can't provide a relocation value for `optind` when `optind` will be dynamically allocated at runtime. The trickery that's possible with a compiler is what's being done here - it's just not compatible with the (IMO significantly outdated) practice of redeclaring bits of an API in your own code. You could solve it at load time for relocatable binaries. The system code for `geotpt` would continue to call the indirect functions for the variables (since it's likely to be residing in `rodata` and is shared by all processes) but would need to switch to per-process data rather than per-thread. The relocation code would need to support callbacks for symbols such that `_getoptvars` or a wrapper could be invoked if a loaded binary needs the address of a task-local variable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
