Page MenuHomeFreeBSD

libc: fix WRONLY/RDONLY test in fmemopen
ClosedPublic

Authored by emaste on Oct 23 2024, 1:43 PM.
Tags
None
Referenced Files
F107228515: D47265.diff
Sat, Jan 11, 4:47 PM
Unknown Object (File)
Fri, Jan 3, 12:28 AM
Unknown Object (File)
Dec 8 2024, 9:10 PM
Unknown Object (File)
Nov 28 2024, 8:25 PM
Unknown Object (File)
Nov 27 2024, 12:25 PM
Unknown Object (File)
Nov 21 2024, 7:55 AM
Unknown Object (File)
Nov 19 2024, 5:29 PM
Unknown Object (File)
Nov 16 2024, 6:25 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

emaste created this revision.
This revision is now accepted and ready to land.Oct 23 2024, 3:28 PM
fuz requested changes to this revision.Oct 23 2024, 3:35 PM
fuz added a subscriber: fuz.

Code should account for O_RDWR case.
The earlier test if (!(flags & O_RDWR) && buf == NULL) in the same file fmemopen.c is also dubious and should be adjusted similarly.
Test should also check a read/write mode like "r+" or "w+".

lib/libc/stdio/fmemopen.c
141

What happens if fmemopen() is called with mode "r+" or "w+", yielding (flags & O_ACCMODE) == O_RDWR?

This revision now requires changes to proceed.Oct 23 2024, 3:35 PM
lib/libc/stdio/fmemopen.c
141

oops, that's a nice catch.

lib/libc/stdio/fmemopen.c
141

Then both tests are false and we use fmemopen_read and fmemopen_write?

lib/libc/stdio/fmemopen.c
141

yep, that sounds correct.

r+ and w+ are implicitly tested in other test cases; I'm not sure we need to duplicate that (but could add a comment).

add a comment, fix another case reported by @fuz (that worked by accident, as it turns out)

This revision is now accepted and ready to land.Oct 23 2024, 4:28 PM
This revision was automatically updated to reflect the committed changes.
jrtc27 added inline comments.
lib/libc/tests/stdio/fmemopen2_test.c
298

as above