Re: What's wrong with glibc-devel-2.2

<yoda@cef.org.tw> writes:
>   I think the key point is the define of accept() in 2.2.
>   accept() define in glibc 2.2

>   extern int accept (int __fd, __SOCKADDR_ARG __addr,
>                    socklen_t *__restrict __addr_len)
>      __THROW;

>   Definition of __SOCKADDR_ARG in glibc 2.2

> #if defined __cplusplus || !__GNUC_PREREQ (2, 7)
> # define __SOCKADDR_ARG         struct sockaddr *__restrict
> # define __CONST_SOCKADDR_ARG   __const struct sockaddr *
> #else

>   Definition of __restrict in glibc 2.2

> /* __restrict is known in EGCS 1.2 and above. */
> #if !__GNUC_PREREQ (2,92)
> # define __restrict     /* Ignore */
> #endif


After staring at this a little, I wonder whether the __restrict
qualifiers might be the problem.  However, my compiler (gcc 2.95.3)
does not complain about this test program:

struct sockaddr { int x; };
typedef int socklen_t;

extern int accept (int __fd, struct sockaddr *__restrict __addr,
                   socklen_t *__restrict __addr_len);

extern int accept (int __fd, struct sockaddr * __addr,
                   socklen_t * __addr_len);

int main() { return 0; }

so at least in this version of gcc, it should not be a problem to
probe for accept's argument types without worrying about __restrict.
What compiler version are you using?  Does it reject the above test
program?

            regards, tom lane