libnetworking: function declaration for accept

[Ralf Corsepius]

On Tue, 2007-12-11 at 16:04 +0100, Thomas Doerfler wrote:
> Hi,
> 
> 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
> cpukit/libnetworking/rtems/rtems_syscall.c:
> 
> 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.

SUSv3 mandates:

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.

Ralf