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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dennis Clarke-2

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.  Ran headlong into crypto/bio/b_addr.c where we see :

    176  /*-
    177   * addr_strings - helper function to get host and service names
    178   * @ap: the BIO_ADDR that has the input info
    179   * @numeric: 0 if actual names should be returned, 1 if the numeric
    180   * representation should be returned.
    181   * @hostname: a pointer to a pointer to a memory area to store the
    182   * host name or numeric representation.  Unused if NULL.
    183   * @service: a pointer to a pointer to a memory area to store the
    184   * service name or numeric representation.  Unused if NULL.
    185   *
    186   * The return value is 0 on failure, with the error code in the
error
    187   * stack, and 1 on success.
    188   */
    189  static int addr_strings(const BIO_ADDR *ap, int numeric,
    190                          char **hostname, char **service)
    191  {
    192      if (BIO_sock_init() != 1)
    193          return 0;
    194
    195      if (1) {
    196  #ifdef AI_PASSIVE
    197          int ret = 0;
    198          char host[NI_MAXHOST] = "", serv[NI_MAXSERV] = "";
    199          int flags = 0;
    200
.
.
.

Where we see NI_MAXHOST and NI_MAXSERV used however those did exist in
RFC2553 and then were removed in RFC3493 and thus strict C99 halts in a
noisey way unless __EXTENSIONS__ is defined.

"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: error: variable length array can not be
initialized: host
"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: error: variable length array can not be
initialized: serv
c99: acomp failed for crypto/bio/b_addr.c

Right.

If I attempt to use "extensions" and other things then this compiles
just fine and the process fails in other places.  For now, however, the
values NI_MAXHOST and NI_MAXSERV don't really exist in netdb.h as
far as I can see.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Dennis Clarke-2
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.

Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Erik Forsberg-11
hmm, been reading this whole thread.
I dont have any current issues building with Sun Studio 12.6 in  2011 mode (but I only do Intel x86 and x86_64)
However, I do have a preference for using gcc for openssl builds though.
Do note however, that in my opinion, for Solaris, one MUST do the -R linker options
to avoid runtime issues with Solaris builds of OpenSSL, But I suppose thats for everyone to
discover for themselves. I discovered it the hard way during the 1.0.1 era.
The -strict mode I think is impossible as of now
(dot-asm) I do want to see your PR for adding support for -R to get incorporated, been sitting for a while -:)

Here are my preferred config settings for Solaris cc

   "efca-x64-cc" => {
       inherit_from    => [ "solaris-common", asm("x86_64_asm") ],
       CC              => "cc",
       CFLAGS          => add_before(picker(debug  => "-g",
                                             release => "-xO5 -xdepend -xbuiltin")),
       cflags          => add_before("-m64 -xarch=generic -xstrconst -std=gnu11"),
       cppflags        => add(threads("-D_REENTRANT")),
       lib_cppflags    => add("-DL_ENDIAN"),
       lflags          => add(threads("-mt")),
       ex_libs         => add(threads("-lpthread")),
       bn_ops          => "SIXTY_FOUR_BIT_LONG",
       perlasm_scheme  => "elf",
       shared_cflag    => "-KPIC",
       shared_ldflag   => add_before("-G -dy -z text -R\$(INSTALLTOP)/\$(LIBDIR)"),
       multilib        => "/64",
   },

>-- Original Message --
>
>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.
>
>Dennis
>
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Kurt Roeckx
In reply to this post by Dennis Clarke-2
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
Reply | Threaded
Open this post in threaded view
|

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

Dennis Clarke-2
On 1/22/19 2:58 PM, Kurt Roeckx wrote:

> 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.

I tend to look at anything 'gnu-foo' as clearly non-standard but still
very very popular and thus defacto standard.  Whatever that means. :-)

>
> The ones I know about:
> - asm(): Most of those should go away if you define PEDANTIC.

No need with the Oracle Studio compilers.  Just use c99 and strict
CFLAGS and watch it utter the endless complaints.

>   I think the only exception is code we compile when gcc is used.
> - strdup() and strcasecmp() which are in POSIX, but not in C

Yep .. that thing.

> - 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.

I think that Rich Salz has already weighed in on this battle and the
code base is C89 clean.  A leap to C99 compliance may not be on anyones
horizon at all and I am not sure how much work would be needed. Curious
to look at it however.

Dennis Clarke

ps: see excellent email from Michael Wojcik Fri Jan 18 01:25:10 UTC 2019
     where "strcasecmp is a heresy" :

https://mta.openssl.org/pipermail/openssl-users/2019-January/009735.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users