Support #15297
closedread does not reset errno anymore
0%
Description
Hi.
I found a strange problem with metaflac which cannot read (and write) tags anymore.
Just try metaflac --list <some flac audio file>.
Even my own compiled executables show this error.
I boiled the problem down to a little test program, see attachment.
With truss you can see that before the read there is an ioctl which sets errno to ENOTTY.
The read just thereafter succeeds but does not reset errno.
I have an older system which does not behave that way and seems to reset errno to zero:
what /lib/64/libc.so.1
/lib/64/libc.so.1:
illumos illumos-cf56021bf3 October 2022
The actual OpenIndiana does show this problem:
what /lib/64/libc.so.1
/lib/64/libc.so.1:
illumos illumos-f137b22e73 December 2022
Note that strictly speaking the code of the program and of metaflac is not correct
since they should not look at the errno if the read call gets data.
There are also some Linux discussions how libc should behave concerning errno
and changes of the standards in libc.
Best regards,
Thomas.
Files
Related issues
Updated by Andy Fiddaman 5 months ago
- Is duplicate of Bug #15294: Successful read/write calls should not set errno added
Updated by Andy Fiddaman 5 months ago
This appears to be another symptom of what was found in #15294 (which probably needs a better title). There is a fix up for review which will hopefully be integrated in the next day or two, and the change will propagate to OpenIndiana shortly afterwards.
Updated by Robert Mustacchi 5 months ago
- Project changed from site to illumos gate
Updated by Joshua M. Clulow 5 months ago
- Related to Bug #15220: isatty should return reasonable errnos added
Updated by Electric Monk 5 months ago
- Status changed from New to Closed
git commit 06ca4e396ecc93ed45a333664a51558b7e84e8f5
commit 06ca4e396ecc93ed45a333664a51558b7e84e8f5 Author: Andy Fiddaman <illumos@fiddaman.net> Date: 2023-01-09T23:07:27.000Z 15294 Successful read/write calls should not set errno Reviewed by: Robert Mustacchi <rm+illumos@fingolfin.org> Reviewed by: Dan Cross <cross@oxidecomputer.com> Approved by: Gordon Ross <gordon.w.ross@gmail.com>