On 4/24/19 3:36 PM, Hans-Bernhard Bröker wrote:
> 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?  
> 

Well, MSG_EOR is not an error, but we can certainly do better than not
defining it at all. My suggestion for the least-cost implementation:

- add a define for MSG_EOR to a non-zero value that is bitwise distinct
from other required MSG_ values
- return EOPNOTSUPP on attempts to use the flag in
send()/sendmsg()/sendto() (POSIX permits that failure for protocols that
don't support it - and none of Cygwin's protocols support it)
- optionally, document that MSG_EOR will never be set in the results
returned by recvmsg() (POSIX says it will only be set on protocols that
support it - and none of Cygwin's protocols support it)

This will at least let software compile that attempts to use it, and
hopefully that software is robust to the fact that send() may reject the
flag and that recvmsg() cannot reliably report use of that flag.

> 
> Either way, as Standardese goes, this is sufficiently unclear that it
> IMHO calls for a defect report to the governing body of this standard.

You're welcome to do so:
http://austingroupbugs.net/main_page.php

although I personally thought POSIX was clear enough that MSG_EOR is
required to be defined, even if only so that it can trigger send()
errors showing that it is unsupported.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org