RTEMS | cpukit/libio: error ENAMETOOLONG when a path compenent is larger than NAME_MAX (!1095)

[Joel Sherrill (@joel)]

Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1095#note_144866


That is the function I was referring to. I was referencing it as an example of one you might have missed. [POSIX Issue 8](https://publications.opengroup.org/c243) can be browsed online or downloaded as a PDF. You need a free membership in The Open Group to download the PDF. Search in that document for _ENAMETOOLONG_ and see if the two places you covered leave any other paths needing attention oin libcsupport or posix were missed. Do not worry about the networking functions that return it.

If you can set a breakpoint on the error being returned and see it hit, it should be OK for code coverage purposes. But for functional verification against the POSIX standard, having a test for each file function that can return ENAMETOOLONG is better.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1095#note_144866
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260309/6ad60b00/attachment.htm>