[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

fcntl F_SETFL, F_GETFL



Itanium tests on fcntl(fd, F_SETFL, ...) fail because 
of (apparently) bad expectations.  And the spec seems
to be a little imprecise in this area. Before I push 
this up as a bugreport, I'd like some other views.

The three tests fcntl 6, 7, 8 test several combinations
of setting file status flags.

To give an example of the test method, the first part of 
test 6 opens a file with O_CREAT|O_RDWR. It then does an 
fcntl call to add O_NONBLOCK to the flags, and an fcntl 
F_GETFL to fetch the new flags, and tests that they are 
exactly equal to O_RDWR|O_NONBLOCK

The failure mode is that on my test system, the flags 
before are 0100002 and after they are 0104002 - in 
other words, the requsted flag got set correctly, but 
the test fails because "after" is not equal to 04002.

Now what about that 0100000 bit?

The SUS says (for F_SETFL): "Set the file status flags,
defined in <fcntl.h>, for the file description associated 
with fildes from the corresponding bits from the third 
argument, arg, taken as type int. Bits corresponding to 
the file access mode and the oflag values that are set in 
arg are ignored."

The flags defined in fcntl.h for use in this context are 
O_APPEND, O_DSYNC, O_RSYNC, O_SYNC and O_NONBLOCK
(O_DSYNC and O_RSYNC are tagged Realtime).

The Linux manpage is more explicit, suggesting that the 
test is wrong:  "Only O_APPEND, O_NONBLOCK and O_ASYNC 
may be set; the other flags are unaffected".

In the absence of special wording, however, the SUS
applies, and it's silent on the possible presence of
any other bits beyond file status and file access;
it does say that any effort to *set* any such bits is
unspecified.

So is this a test suite problem? Spec problem? Both?

I also notice that the set of valid file status flags
seems to differ between the SUS and Linux.

Mats


-- 
To UNSUBSCRIBE, email to lsb-test-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org



Reply to: