RTEMS | fcntl(F_DUPFD) ignores its third argument (#5668)

[Joel Sherrill (@joel)]

Joel Sherrill commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5668#note_156151


Unfortunately, POSIX has changed the definition of F_DUPFD. I do not know when without digging more than I can really do on my phone. But the 1997 fcntl.h page and Issue 7 (2018) page are different. Issue 7 matches your expectations. It would be helpful to know when it changed. I can follow up on that but it doesn't matter to the end actions needed.

For score/objects, they are freed to the end of an allocation list so they will not be reused immediately. This was done to aid debug since there might be information in deleted objects. The same approach could be used here if the free iop set is a chain. That should increase the likelihood the fd is greater. But this needs a guarantee and that is going to require a different allocator for this one case. 

The impact on _dup()_ and _dup2() also needs to be considered.

This will impact user documentation and should be mentioned explicitly in the release notes.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5668#note_156151
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-0pzdfzsqu4yxl90d98mxys47a-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260731/022d52e8/attachment-0001.htm>