This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
Am 24.04.2019 um 19:54 schrieb Eliot Moss:
> On 4/24/2019 12:43 PM, Corinna Vinschen wrote:
>> Since MSG_EOR isn't implemented in the underlying transport layer,
>> there's no way to implement it in userspace. That's why it's not
>> defined in Cygwin's headers. If you have an idea how to implement
>> this in plain userspace, feel free to provide patches.
>
> I don't have a direct interest in this issue, but I do have a wondering.
> If Cygwin fails to define an error code -- even if the error cannot
> actually happen under Cygwin -- isn't that a problem when trying to
> compile imported software?
That, like the question whether Cygwin is in any way obliged to define
it, ends up in an issue of Interpretation of Standardese. The latter is
a language that looks deceptively much like ordinary English, but just
like Legalese, is not the same thing.
In the case at hand the point that needs interpretation is what that
parenthesis "(if supported by the protocol)" really means. What is "the
protocol" it refers to? What if several protocols are supported, which
differ in support for this?
The core issue, though, is: what is controlled by this "if", i.e. what
is the "then" effect? And what's the "else"?
Cygwin's interpretation (whether by design or by accident) is: if this
never is true, the "shall define" a few lines above does not apply any
more. If that's a correct interpretation, then source code would be
wrong to just assume presence of this macro unconditionally. In that
case the actual problem that software noticing would be written
incorrectly (they should #ifdef MSG_EOR before using it).
An alternative interpretation could be that this entire parenthesis is
ultimately just a superfluous that adds no meaning to the standard; the
macro would have to be defined always; software would be entitled to
blindly assume its existence, and Cygwin would be wrong about this.
Either way, as Standardese goes, this is sufficiently unclear that it
IMHO calls for a defect report to the governing body of this standard.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple