Re: Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote:
> On 1/18/19 1:53 AM, Dennis Clarke wrote:
> > 
> > Going in circles trying to compile 1.1.1a with strict C99 and no
> > optimizations and with a ready to debug and single step resultant
> > library.
> 
> Ignore all this.  Thou shalt not C99 here.

Our code base is currently C89/C90, with some extenions, but things
like gcc default to something like "gnu99", "gnu11" or "gnu17".
And we actually make use of some of those extensions not in C89.

The ones I know about:
- asm(): Most of those should go away if you define PEDANTIC. I
  think the only exception is code we compile when gcc is used.
- strdup() and strcasecmp() which are in POSIX, but not in C
- Setting the mutex type, which seems to be UNIX98 or XOPEN2K8
- isascii: XOPEN
- usleep: Was in POSIX, has been replaced by nanosleep
- long long: Since C99

Then we also use things like int32_t, but define the type ourself
if the compiler is C89. We detect C11 support for atomics.

Anyway, if you have a good patch to remove things that are no
longer in a standard, and it also works with older systems, I suggest
submit a patch.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux