This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FWD: Re: [ECOS] Problems with init_all_network_interfaces

Andrew Lunn <> writes:

> > > This patch should solve this problem. socket will return EINVAL.
> > 
> > Actually, I think it would be better to return EPROTONOSUPPORT, which
> > is what you would get if there were entries in the table but none of
> > them supported the protocol requested.
> Humm, POSIX says
>     int socket(int domain, int type, int protocol);
>     The socket() function shall fail if:
>         The implementation does not support the specified address family.
>     [EMFILE]
>         No more file descriptors are available for this process.
>     [ENFILE]
>         No more file descriptors are available for the system.
>         The protocol is not supported by the address family, or the
>         protocol is not supported by the implementation.
>         The socket type is not supported by the protocol.
> So for me, EPROTONOSUPPORT is talking about the third parameter,
> protocol. ie we have found something that supports the domain and the
> type, but not the protocol.
> In the case of the bug, we don't even support the domain, so
> EAFNOSUPPORT seems more appropriate.
> Having said that, i don't really case so long as its something
> sensible. 

I'll admit I was only looking at the BSD stack code which appears to
generate EPROTONOSUPPORT for this case. However, if the standard says
that it should be EAFNOSUPPORT, then that's what it should be.

Like you, I don't really care so long as something sensible happens :-)

Nick Garnett                    eCos Kernel Architect     The eCos and RedBoot experts

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]