Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

On 2009-11-30 at 15:41 +0100, Marc Beyer wrote:
> I'm getting a compilation failure for the last two versions of exim
> under HP-UX, the error is:
> 
> gmake[2]: Entering directory
> `/var/tmp/eximtest/exim-4.71/build-HP-UX-ia64/pdkim'
> cc base64.c
> cc bignum.c
> "bignum.h", line 58: error #3089: there is no type with the width specified
>       typedef unsigned int t_dbl __attribute__((mode(TI)));
>                                                 ^

There's a GCC-ism in src/pdkim/bignum.h which is not wrapped by a check
for GCC.

Do you know how to get a 128-bit integer on your platform?

You "just" need to replace that line with a typedef which lets t_dbl be
a 128-bit int.

Perhaps int128_t or __int128_t exists, via <stdint.h> ?

Otherwise, if you can't get a 128 bit int, I think (but am not sure)
that you need to drop t_int down to 32 bits.  I've only glanced over it,
but it looks like things will just work after that.

-Phil

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

Hello,

Phil Pennock wrote:
> On 2009-11-30 at 15:41 +0100, Marc Beyer wrote:
>> gmake[2]: Entering directory
>> `/var/tmp/eximtest/exim-4.71/build-HP-UX-ia64/pdkim'
>> cc base64.c
>> cc bignum.c
>> "bignum.h", line 58: error #3089: there is no type with the width specified
>>       typedef unsigned int t_dbl __attribute__((mode(TI)));
> There's a GCC-ism in src/pdkim/bignum.h which is not wrapped by a check
> for GCC.

does that mean that AIX/HP-UX/Solaris users with their vendor's 
compilers will get stuck on this point?

> Do you know how to get a 128-bit integer on your platform?
> You "just" need to replace that line with a typedef which lets t_dbl be
> a 128-bit int.
> Perhaps int128_t or __int128_t exists, via <stdint.h> ?
> Otherwise, if you can't get a 128 bit int, I think (but am not sure)
> that you need to drop t_int down to 32 bits.  I've only glanced over it,
> but it looks like things will just work after that.

As far as I can see there is no 128bit integer in HP-UX 11.31. According 
to stdint.h(5) there is
   intmax_t              largest signed integer data type supported
                                  by implementation
which appears to be set to int64_t which boils down to
   #define INT64_MAX INT64_C(9223372036854775807)

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

Hi Phil,

thanks for your answer!

> There's a GCC-ism in src/pdkim/bignum.h which is not wrapped by a check
> for GCC.
> 
> Do you know how to get a 128-bit integer on your platform?

Unfortunately not :-/

> You "just" need to replace that line with a typedef which lets t_dbl be
> a 128-bit int.
> 
> Perhaps int128_t or __int128_t exists, via <stdint.h> ?

Neither of these exist in /usr/include/stdint.h .

> Otherwise, if you can't get a 128 bit int, I think (but am not sure)
> that you need to drop t_int down to 32 bits.  I've only glanced over it,
> but it looks like things will just work after that.

If I simply replace the line with

typedef unsigned int t_dbl;

the compile goes through fine. Is that what you meant?

We won't be using pdkim (for now at least), so if that part of the code
doesn't work properly  it won't be of any great concern to us.

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

On 2009-12-01 at 11:31 +0100, V. T. Mueller, Continum wrote:
> does that mean that AIX/HP-UX/Solaris users with their vendor's 
> compilers will get stuck on this point?

Yes.  It's a goof.

The solution is easy: when Release Candidates (RCs) are announced, try
to build them!  You don't need to deploy it, but if nobody using a
compiler other than GCC tries to build the release candidates with the
options they want enabled, then these problems will slip through into
the final releases.

If you can build it and run some basic tests, even better.

> which appears to be set to int64_t which boils down to
>    #define INT64_MAX INT64_C(9223372036854775807)
> 
> Will it be safe to just change occurences of 128 to 64 in bignum.c 
> without breakting anything somewhere else?

I'm not familiar with the bignum code and this is one of those weeks
where I don't have time to go diving (I get home and crash).

If memory serves, the code looked as though you need two int types, and
one needs to be twice the size of the other.  If you just lower the size
of the larger to be the same as the smaller, I would expect things to
break -- I'm guessing there is a reason for the differences.

-Phil

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

Hello Phil,

Phil Pennock wrote:
> On 2009-12-01 at 11:31 +0100, V. T. Mueller, Continum wrote:
>> does that mean that AIX/HP-UX/Solaris users with their vendor's 
>> compilers will get stuck on this point?
> Yes.  It's a goof.
> The solution is easy: when Release Candidates (RCs) are announced, try
> to build them!  You don't need to deploy it, but if nobody using a
> compiler other than GCC tries to build the release candidates with the
> options they want enabled, then these problems will slip through into
> the final releases.
 > If you can build it and run some basic tests, even better.

That's what we're intending to do. And I asked for (my) clarity; I 
didn't mean to complain. We're always short of time, even sometimes 
wondering whether we should switch to some black-bock SMTP app. So it's 
simply a matter of time that we never set up the test suite.

>> which appears to be set to int64_t which boils down to
>>    #define INT64_MAX INT64_C(9223372036854775807)
>> Will it be safe to just change occurences of 128 to 64 in bignum.c 
>> without breakting anything somewhere else?
> I'm not familiar with the bignum code and this is one of those weeks
> where I don't have time to go diving (I get home and crash).

Sounds familiar... ;)
Maybe "next year" we can have a colleague who speaks C take a look into 
it. Until then we're trying to build exim without dkim - which we won't 
need anyway I guess.

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

On Tue, 2009-12-01 at 00:11 -0800, Phil Pennock wrote:

> > "bignum.h", line 58: error #3089: there is no type with the width specified
> >       typedef unsigned int t_dbl __attribute__((mode(TI)));
> >                                                 ^
> 
> There's a GCC-ism in src/pdkim/bignum.h which is not wrapped by a check
> for GCC.
> 
> Do you know how to get a 128-bit integer on your platform?

Are you sure that's meant to be a 128 bit type? The other side of the
architecture ifdef uses 'unsigned long long' which typically is 64 bits,
no? OTOH, unsigned long will be 64 bits already on 64-bit platforms so
you're probably right about it wanting 128 bits -- it does appear to be
checking for all possible 64-bit platforms there.

However, looking at the code, it looks like you can get a (probably
slower) version of it that uses 16/32 bit types by defining
POLARSSL_HAVE_INT16.

johannes

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##

Re: compilation failure of 4.70 and 4.71 on HP-UX-11.31

On 2009-12-04 at 09:36 +0100, Johannes Berg wrote:
> On Tue, 2009-12-01 at 00:11 -0800, Phil Pennock wrote:
> 
> > > "bignum.h", line 58: error #3089: there is no type with the width specified
> > >       typedef unsigned int t_dbl __attribute__((mode(TI)));
> > >                                                 ^
> > 
> > There's a GCC-ism in src/pdkim/bignum.h which is not wrapped by a check
> > for GCC.
> > 
> > Do you know how to get a 128-bit integer on your platform?
> 
> Are you sure that's meant to be a 128 bit type?

http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/X86-Built-in-Functions.html

"""If SSE extensions are enabled, V4SF is used for a vector of four
32-bit floating point values. Some instructions use a vector of four
32-bit integers, these use V4SI. Finally, some instructions operate on
an entire vector register, interpreting it as a 128-bit integer, these
use mode TI."""

http://gcc.gnu.org/gcc-4.4/changes.html

In a section re MIPS support, there's now: """You can now achieve the
same effect using 128-bit types:

    typedef unsigned int uint128_t __attribute__((mode(TI)));
    result = ((uint128_t) x * y) >> 64;
"""

[Bug 926] New: clamd 0.95 deprecates "STREAM" command

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=926
           Summary: clamd 0.95 deprecates "STREAM" command
           Product: Exim
           Version: 4.70
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: low
         Component: Content Scanning
        AssignedTo: tom <at> duncanthrax.net
        ReportedBy: jethro.binks <at> strath.ac.uk
                CC: exim-dev <at> exim.org

Hi,

I just wanted to raise the issue that, as of clamd 0.95 I think, the
"STREAM" command (which receives a PORT to which the client should
re-connect in order to perform the scan) is deprecated, in favour of
"INSTREAM" where the data to be scanned is sent on the same connection.

  http://wiki.clamav.net/bin/view/Main/UpgradeNotes095

clamd man page:

       INSTREAM
              It is mandatory to prefix this command with n or z.

[Bug 926] clamd 0.95 deprecates "STREAM" command

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=926

Phil Pennock <exim-dev <at> spodhuis.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |exim-dev <at> spodhuis.org

--- Comment #1 from Phil Pennock <exim-dev <at> spodhuis.org>  2009-12-05 01:27:41 ---
Thanks for the heads-up.

Incidentally, it looks as though Exim has an undocumented feature (!!) in the
ClamAV scanning.

As well as using the SCAN command for unix-domain sockets, if you configure a
second option of "local" for network sockets, it tells Exim to assume common
storage (which, given Exim's spool ownership, had better mean "same machine")
and so again issues the SCAN command, instead of STREAM.

This would be a configuration of:

av_scanner = clamd:192.0.2.42 1234:local

Untested, but that's what the code appears to do.

This is more efficient (avoids sending the files around) so is a win, if this
configuration can work for you.

[Bug 926] clamd 0.95 deprecates "STREAM" command

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=926

Duane Hill <d.hill <at> yournetplus.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.hill <at> yournetplus.com

--- Comment #2 from Duane Hill <d.hill <at> yournetplus.com>  2009-12-05 06:56:47 ---
This is my first post in the bug report. Forgive if it was done incorrectly.

Does this include using the following config:

...
av_scanner = $acl_m0
...
acl_check_data:

  ...
  #       Reject the message if it is found to contain a virus or malware.
  deny    message       = Message content was found to be unsafe.
          hosts         = !+viriskip_hostaddr
          set acl_m0    = clamd:127.0.0.1 3310:local
          malware       = */defer_ok
          log_message   = Message content was found to be unsafe. \
                          $malware_name was found.
  ...