Re: [exim] warnings during compilation

Top Page
Delete this message
Reply to this message
Author: Patrice
Date:  
To: exim-users
Subject: Re: [exim] warnings during compilation
I just changed the type to int , and it worked without warnings:

#define EXIM_SOCKLEN_T int


I had another warning:

    cc -c -O -I.   -I/usr/local/include/openssl/ -I/usr/local/include
    rfc2047.c
    cc: Warning: rfc2047.c, line 262: In this statement, the referenced
    type of the pointer value "(const char ...)(&dp
    tr)" is "pointer to const char", which is not compatible with
    "pointer to char". (ptrmismatch)
          (void)iconv(icd, (ICONV_ARG2_TYPE)(&dptr), &dlen, CSS &outptr,
    &outleft);
    -----------------------^


I corrected my os.h-OSF1 with adding :

#define ICONV_ARG2_TYPE char **


with this 2 corrections I have 0 warnings on my tru64  V5.1B      (OSF1 
V5.1 2650 alpha)



thank you very much Philip for you help !!
I have learned today how to deal with warnings !

Patrice


Patrice wrote:

> Thank you very much for your fast answer.
>
> I watched the man and is says :
>
>    /NAME/

>
>    /  getsockname - Get the socket name/

>
>    /SYNOPSIS/

>
>    /  #include <sys/socket.h>/

>
>    /  int getsockname(/
>    /          int socket,/
>    /          struct sockaddr *address,/
>    /          socklen_t *address_len );/

>
>    /  [XNS4.0]  The definition of the getsockname() function in XNS4.0
>    uses a/
>    /  size_t data type instead of a socklen_t data type as specified in
>    XNS5.0/
>    /  (the previous definition)./

>
>    /  [Tru64 UNIX]  The following definition of the getsockname()
>    function does/
>    /  not conform to current standards and is supported only for
>    backward compa-/
>    /  tibility (see standards(5)):/

>
>    /  #include <sys/socket.h>/

>
>    /  int getsockname(/
>    /          int socket,/
>    /          struct sockaddr *address,/
>    /          int *address_len );/

>
>
>
> I made the modification you told me but the compilation stop :
>
>    cc -c -O -I.   -I/usr/local/include/openssl/ -I/usr/local/include
>    daemon.c
>    cc: Error: daemon.c, line 145: In this declaration, "socklen_t" must
>    specify a type. (badparsedecl)
>    EXIM_SOCKLEN_T ifsize = sizeof(interface_sockaddr);
>    ^
>    cc: Error: daemon.c, line 1581: In this declaration, "socklen_t"
>    must specify a type. (badparsedecl)
>      EXIM_SOCKLEN_T len = sizeof(accepted);
>    --^
>    cc: Error: daemon.c, line 192: In this statement, "ifsize" is not
>    declared. (undeclared)
>         &ifsize) < 0)
>    ------^
>    cc: Error: daemon.c, line 1753: In this statement, "len" is not
>    declared. (undeclared)
>                  (struct sockaddr *)&accepted, &len);
>    ---------------------------------------------^
>    *** Exit 1
>    Stop.
>    *** Exit 1
>    Stop.

>
>
> Do you have another idea for my warnings ?
>
> thanks in advance
>
> Patrice
>
> Philip Hazel wrote:
>
>> On Fri, 17 Jun 2005, Patrice wrote:
>>
>>
>>
>>> Hello,
>>>
>>> I am compiling exim on a tru64 unix
>>>
>>
>>
>> Does that still think it is OSF1? You can tell by looking at the name
>> of the "build" directory that Exim creates. I would expect it to
>> start "build-OSF1".
>>
>>
>>
>>> I have some warnings:
>>>
>>> cc -c -O -I.   -I/usr/local/include/openssl/ -I/usr/local/include 
>>> exim.c
>>> cc: Warning: exim.c, line 3461: In this statement, the referenced 
>>> type of the
>>> pointer value "&size" is "unsigned lo
>>> ng", which is not compatible with "int". (ptrmismatch)
>>> if (getpeername(0, (struct sockaddr *)(&inetd_sock), &size) == 0)
>>> -------------------------------------------------------^
>>> cc: Warning: exim.c, line 3469: In this statement, the referenced 
>>> type of the
>>> pointer value "&size" is "unsigned lo
>>> ng", which is not compatible with "int". (ptrmismatch)
>>>     if (getsockname(0, (struct sockaddr *)(&interface_sock), &size) 
>>> == 0)
>>> ---------------------------------------------------------------^

>>>
>>>
>>> should I worry about this warnings or not ?
>>>
>>
>>
>> Almost certainly not. However, this is concerned with the definition
>> of the data type socklen_t. There is a macro for handling this. In
>> the configuration for OSF1 it reads
>>
>> #define EXIM_SOCKLEN_T    size_t

>>
>> That is what is used for the variable "size". Take a look at the man
>> pages for getpeername and getsockname on your box and see what data
>> type is expected for the third arguments.
>>
>> If it is socklen_t, it means that OSF1/tru64 has caught up with the
>> rest of the world. The fix would be to remove the line
>>
>> #define EXIM_SOCKLEN_T    size_t

>>
>> from the file OS/os.h-OSF1 and then "make clean", "make", to build it
>> all again. (Because the default is socklen_t.) If you do this and it
>> works, please let me know so I can change the distributed files.
>>
>>
>>
>