Re: [patch]socket.h : OpenVMS has _CMSG_LEN/_CMSG_SPACE macros.

John E. Malmberg wrote: > >> This patch defines the CMSG_LEN and CMSG_SPACE macros for OpenVMS in > >> sys_socket.h. > > Sorry, here is the patch. Thanks, looks good. Two nits: * The argument names of C macros don't need to be protected; only K&R C preprocessors were not hygienic regarding C m

Re: [patch]socket.h : OpenVMS has _CMSG_LEN/_CMSG_SPACE macros.

On 7/15/2017 10:23 AM, Bruno Haible wrote: John E. Malmberg wrote: This patch defines the CMSG_LEN and CMSG_SPACE macros for OpenVMS in sys_socket.h. There was no patch attached to your mail. Sorry, here is the patch. Regards, -John 0001-socket-Add-support-for-OpenVMS.patch.gz Descriptio

Re: [patch]socket.h : OpenVMS has _CMSG_LEN/_CMSG_SPACE macros.

John E. Malmberg wrote: > This patch defines the CMSG_LEN and CMSG_SPACE macros for OpenVMS in > sys_socket.h. There was no patch attached to your mail. Bruno

[patch]socket.h : OpenVMS has _CMSG_LEN/_CMSG_SPACE macros.

This patch defines the CMSG_LEN and CMSG_SPACE macros for OpenVMS in sys_socket.h. Regards, -John

Re: socket.h

Jim Meyering <[EMAIL PROTECTED]> writes: >> I agree. I wish 'indent' could fix this >> too. Maybe it can? Even if I agree many code writing ideas given >> here, I forget them all the time. > > I tend to forget, too, so have automated quite a few policy checks, > over the years. You might try a

Re: socket.h

Paul Eggert wrote: > I don't see any technical reason to prefer the parentheses. While I agree that there are no technical reason to put the parentheses, I wouldn't be religious on the issue, because the majority of the C programmers does it the other way. The same argument as for "const char *":

Re: socket.h

Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Any objection to removing [useless parentheses]? > > No, please install them. Ok. I've checked that in. > I agree. I wish 'indent' could fix this > too. Maybe it can? Even if I agree many code writing ideas given > here, I forget them all the time

Re: socket.h

Jim Meyering <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> wrote: >> For some reason, mingw32 uses non-POSIX names for shutdown's > ... >> --- socket_.h09 Jan 2006 17:13:09 +0100 1.1 >> +++ socket_.h19 Jan 2006 14:39:07 +0100 >> @@ -34,4 +34,15 @@ >> # incl

Re: socket.h

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> +#if !defined(SHUT_WR) && defined (SD_SEND) >> +# define SHUT_WR 1 >> +#endif >> +#if !defined(SHUT_RDWR) && defined (SD_BOTH) >> +# define SHUT_RDWR 2 >> +#endif > > Is SD_SEND == 1 and SD_BOTH == 2 ? Yes, although it is a mist

Re: socket.h

Jim Meyering <[EMAIL PROTECTED]> writes: > I find that those parentheses provide no benefit. Although coreutils > doesn't use that module, it might be worthwhile to start following the > same guideline in gnulib. I've never run into a compiler that didn't support "defined FOO", and I don't see a

Re: socket.h

Simon Josefsson <[EMAIL PROTECTED]> wrote: > For some reason, mingw32 uses non-POSIX names for shutdown's ... > --- socket_.h 09 Jan 2006 17:13:09 +0100 1.1 > +++ socket_.h 19 Jan 2006 14:39:07 +0100 > @@ -34,4 +34,15 @@ > # include > #endif > > +/* For shutdown(). */ > +#if !defined(SHUT_RD)

Re: [bug-gnulib] socket.h

Simon Josefsson wrote: > +#if !defined(SHUT_WR) && defined (SD_SEND) > +# define SHUT_WR 1 > +#endif > +#if !defined(SHUT_RDWR) && defined (SD_BOTH) > +# define SHUT_RDWR 2 > +#endif Is SD_SEND == 1 and SD_BOTH == 2 ? Bruno ___ bug-gnulib mailing lis

socket.h

For some reason, mingw32 uses non-POSIX names for shutdown's 'how'. I have installed this. 2006-01-19 Simon Josefsson <[EMAIL PROTECTED]> * socket_.h: Map SHUT_RD, SHUT_WR, SHUT_RDWR correctly. --- socket_.h 09 Jan 2006 17:13:09 +0100 1.1 +++ socket_.h 19 Jan 2006 14:39:07

Re: sys/socket.h on mingw32 vs socklen (resend)

;> > on MacOS X.) >> >> How do I test for that in a portable way? > > Let rmdir do the test, and ignore a possible error: > > -rmdir sys 2>/dev/null Of course. Added. >> Applications that need socklen_t should probably depend on >> the sys/socket.h mo

Re: sys/socket.h on mingw32 vs socklen (resend)

y? Let rmdir do the test, and ignore a possible error: -rmdir sys 2>/dev/null > Applications that need socklen_t should probably depend on > the sys/socket.h module. Perhaps the socklen_t module should depend > on the sys_socket module? I don't think so: Application

Re: sys/socket.h on mingw32 vs socklen (resend)

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote on 2005-12-17: >> The sys_socket module below will create a sys/socket.h file, primarily >> for mingw32, but it could be extended for other systems or missing >> sys/socket.h features in the future.

Re: [bug-gnulib] sys/socket.h on mingw32 vs socklen (resend)

Simon Josefsson wrote on 2005-12-17: > The sys_socket module below will create a sys/socket.h file, primarily > for mingw32, but it could be extended for other systems or missing > sys/socket.h features in the future. > > This would solve the problem of accessing sys/so

Re: sys/socket.h on mingw32 vs socklen (resend)

Hi! The sys_socket module below will create a sys/socket.h file, primarily for mingw32, but it could be extended for other systems or missing sys/socket.h features in the future. This would solve the problem of accessing sys/socket.h stuff in applications. However, it does not solve the problem

sys/socket.h on mingw32 vs socklen

Hi! The sys_socket module below will create a sys/socket.h file, primarily for mingw32, but it could be extended for other systems or missing sys/socket.h features in the future. This would solve the problem of accessing sys/socket.h stuff in applications. However, it does not solve the