You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/03/27 04:15:38 UTC
[GitHub] [incubator-nuttx] Donny9 opened a new pull request #3202: limits.h: modify _POSIX_OPEN_MAX to 255
Donny9 opened a new pull request #3202:
URL: https://github.com/apache/incubator-nuttx/pull/3202
## Summary
Modify _POSIX_OPEN_MAX to 255 because we may use it to create variable, but INT_MAX is too bigger so that stack overflow or compiling break.
example:
mq_open/speculative/26-1.c:46:8: error: size of array 'queue' is negative
mqd_t queue[_POSIX_OPEN_MAX + _POSIX_MQ_OPEN_MAX + 1];
## Impact
## Testing
--
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:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #3202: limits.h: modify _POSIX_OPEN_MAX to 255
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #3202:
URL: https://github.com/apache/incubator-nuttx/pull/3202#issuecomment-808748290
Looking at the documentation I found (https://www.gnu.org/software/libc/manual/html_node/Minimums.html) it would seem that these values are to actually guarantee a minimum. This is confirmed by the comment on `lib_sysconf.c`:
```
* Otherwise, sysconf() will return the current variable value on the
* system. The value returned will not be more restrictive than the
* corresponding value described to the application when it was compiled
* with the implementation's <limits.h> or <unistd.h>. The value will not
* change during the lifetime of the calling process, except that
* sysconf(_SC_OPEN_MAX) may return different values before and after a
* call to setrlimit() which changes the RLIMIT_NOFILE soft limit.
```
So I think this value should actually be lower. In fact, it appears that glibc defines 16, which is more conservative.
--
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:
users@infra.apache.org
[GitHub] [incubator-nuttx] davids5 merged pull request #3202: limits.h: modify _POSIX_OPEN_MAX to 16
Posted by GitBox <gi...@apache.org>.
davids5 merged pull request #3202:
URL: https://github.com/apache/incubator-nuttx/pull/3202
--
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:
users@infra.apache.org
[GitHub] [incubator-nuttx] Donny9 commented on pull request #3202: limits.h: modify _POSIX_OPEN_MAX to 255
Posted by GitBox <gi...@apache.org>.
Donny9 commented on pull request #3202:
URL: https://github.com/apache/incubator-nuttx/pull/3202#issuecomment-809054040
> Looking at the documentation I found (https://www.gnu.org/software/libc/manual/html_node/Minimums.html) it would seem that these values are to actually guarantee a minimum. This is confirmed by the comment on `lib_sysconf.c`:
>
> ```
> * Otherwise, sysconf() will return the current variable value on the
> * system. The value returned will not be more restrictive than the
> * corresponding value described to the application when it was compiled
> * with the implementation's <limits.h> or <unistd.h>. The value will not
> * change during the lifetime of the calling process, except that
> * sysconf(_SC_OPEN_MAX) may return different values before and after a
> * call to setrlimit() which changes the RLIMIT_NOFILE soft limit.
> ```
>
> So I think this value should actually be lower. In fact, it appears that glibc defines 16, which is more conservative.
Done. Thanks.
--
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:
users@infra.apache.org