Andries.Brouwer@cwi.nl writes:
| Jim Meyering writes:
|
| > I'm wondering if I've found a problem with the way the kernel
| > handles the ioctl calls resulting from my call to tcsetattr.
|
| One may read the lines
|
| "The tcsetattr() function shall return success if it was able
| to perform any of the requested actions, even if some of the requested
| actions could not be performed. It shall set all the attributes that
| the implementation supports as requested and leave all the attributes
| not supported by the implementation unchanged. If no part
| of the request can be honoured, it will return -1 and set errno to [EINVAL]."
In the example code I sent, there was only one action requested
(enable parity), and that wasn't performed.
| as saying that the tcsetattr() should have returned -1, but it is not
| entirely clear what the definition of `requested action' is.
IMHO, the requested action in my example code is `enable parity (PARENB)'.
Let me try to make my position clearer.
1. I agree with your interpretation of POSIX.1 in the sense that
that is probably similar to what was meant.
2. The POSIX wording is imprecise, even incorrect.
3. I do not think there is enough evidence to conclude that the
present Linux kernel source violates POSIX 7.2.1.
Let me try to formalize your interpretation.
"There is a vector of terminal properties `old', and a vector `new'.
Each place where they differ is an action request.
tcsetattr must fail when all requests failed, and succeed
when at least one request succeeded."
You see, there is a problem with this interpretation:
it would require tcsetattr to fail when `old' and `new'
are identical. Certainly that is not what is meant.
Of course it is easy to invent things they might have meant
but some phantasy is required to read such inventions into
the text of the standard. (And I already allowed some
phantasy in that the standard nowhere talks about the old
situation. So one cannot really conclude that actions
correspond to differences with the old situation.)
Is there any chance tcsetattr can be adjusted to return an indication
of its failure in this case?
Maybe someone changes the kernel source here.
But since the standard itself is not precise enough
I would say that a program that relies on the return value
of tcsetaddr is broken.
All references (even B7.2) seem to say: 1. do tcgetaddr()
2. change what you want to change and do tcsetaddr()
3. do tcgetaddr() to see how successful the tcsetaddr() was.
That is, no conclusions must be drawn from the fact that
tcsetaddr() returns 0 (except that the optional_actions argument
had one of the allowed values).
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/