libnetworking: function declaration for accept
ralf.corsepius at rtems.org
Tue Dec 11 16:19:20 UTC 2007
On Tue, 2007-12-11 at 16:04 +0100, Thomas Doerfler wrote:
> during a code review session we just came across an obscure divergence
> between the function declaration of "accept" and the real implementation:
> in cpukit/libnetworking/sys/socket.h, we have the following declaration
> (encapsulated in "#ifndef _KERNEL"):
> int accept(int, struct sockaddr * __restrict, socklen_t * __restrict);
> with socklen_t being mapped to a uint32_t.
> On the other hand, we have the implementation in
> int accept (int s, struct sockaddr *name, int *namelen)
> The last argument obviously has a different signedness.
> The declaration seems to comform to the one available under Linux.
> Any comments?
The answer is simple: The latter version is wrong.
int accept(int, struct sockaddr *restrict, socklen_t *restrict);
which corresponds to the version ins sys/socket.h (which is the BSD way
to use restrict)
> - Shall I check/modify the accept implementation?
> - Which other rtems_syscall functions might need a closer inspection?
> - How can we make sure, that function declaration and implementation are
> closer together?
They actually are together, because even though they diverge in their
notation, they actually are call compatible.
> Or, other question: Any idea why the declarations are
> encapsulated in "#ifndef _KERNEL"?
Original BSD-code. BSD shares headers between kernel and user-space. To
guard their kernel from receiving functions which are only available in
in user-space, they #ifndef _KERNEL their "user-space API".
For RTEMS these #if(n)def _KERNEL defines are widely meaningless.
More information about the users