similar to: murmurhash3 test failures on big-endian systems

Hi Aki, On 15:55 Mon 26 Mar , Aki Tuomi wrote: > On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > > Hi, > > > > The dovecot 2.3.0.1 Debian package currently fails to build on all > > big-endian architectures[1], due to murmurhash3 tests failing. The > > relevant output from e.g. s390x is: > > > > test-murmurhash3.c:22: Assert(#8) failed:

Hi, On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > ... > > I'd be happy to test the patch, thanks! > > Ok, try the attached patch. (It is a first pass at the issue, so it may not > be the final diff that'll end up getting committed. It'd be good to know if > it actually

On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > Hi, > > The dovecot 2.3.0.1 Debian package currently fails to build on all > big-endian architectures[1], due to murmurhash3 tests failing. The > relevant output from e.g. s390x is: > > test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > test-murmurhash3.c:22: Assert(#11)

On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > It turns out there's a missing byte-inversion when loading the blocks > which should be addressed in getblock{32,64}. Murmurhash treats each > block as an integer expecting little-endian storage. Applying this > additional change fixes the build on s390x (and

On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > Hi, > > On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > > ... > > > I'd be happy to test the patch, thanks! > > > > Ok, try the attached patch. (It is a first pass at the issue, so it may not > > be

On Tue, Mar 27, 2018 at 08:46:20 -0400, Josef 'Jeff' Sipek wrote: > On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > It turns out there's a missing byte-inversion when loading the blocks > > > which

On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: ... > I'd be happy to test the patch, thanks! Ok, try the attached patch. (It is a first pass at the issue, so it may not be the final diff that'll end up getting committed. It'd be good to know if it actually fixes the issue for you - sadly, I don't have a big endian system to play with.) Thanks, Jeff.

On Tue, Mar 27, 2018 at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > It turns out there's a missing byte-inversion when loading the blocks > > which should be addressed in getblock{32,64}. Murmurhash treats each > > block as an integer

OpenSSL 1.1 features a cleanup function that is automatically run on shutdown using atexit(3). This function frees all OpenSSL-allocated resources. In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant dovecot crypto module and is finally unloaded using dlclose(3). Until OpenSSL 1.0.1c this worked fine, however OpenSSL 1.0.1c makes sure[1] that the library stays loaded

Hi, Apparently the "kick" doveadm_cmd_ver2 struct lacks a .mail_cmd member pointing to an appropriate allocation function, causing a NULL pointer dereference when used via `doveadm batch`. (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000555555585882 in doveadm_mail_cmd_init (cmd=cmd at entry=0x7fffffffe680, set=0x5555555f2440) at doveadm-mail.c:596 #2 0x0000555555586f68 in

This is driven by the fact that OpenSSL 1.1 does not know about SSLv2 at all and dovecot's defaults simply make OpenSSL error out with "Unknown protocol 'SSLv2'"[1]. So we change the defaults to refer to SSLv2 iff OpenSSL seems to know something about it. While at it, it's also a good idea to disable SSLv3 by default as well. [1] https://bugs.debian.org/844347

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

Control: tags -1 + moreinfo upstream [Forwarding this to the Dovecot mailing list, just in case someone can help] Hi, Thanks for the report! See my comments inline. On 11:56 Thu 21 Sep , Thurgood Angelou wrote: > Package: dovecot-core > Version: 1:2.2.32-2 > > I've just discovered a bug where the sieve plugin (especially IMAP) > will not work with a virtual mailbox. I

> On Jan 10, 2017, at 9:36 AM, Bruce Hoult <bruce at hoult.org> wrote: > > Both are not very sophisticated. > You should also look at the different MurmurHash versions, and descendants such as CityHash. I did a few benchmark this morning, trying to tweak the hashing for pointers (as many people seem to use pointers as keys). The hash function in LLVM is quite simple, but it

On Tue, Feb 14, 2012 at 2:44 AM, Chris Lattner <clattner at apple.com> wrote: > On Feb 13, 2012, at 2:00 AM, Talin wrote: >> >> Just out of curiosity, why not MurmurHash3 ? This page seems to >> suggest that #2 has some flaw, and #3 is better all round: >> >> https://sites.google.com/site/murmurhash/ >> > The main reason is because there's no

Hi, This patch: On 15/11/2016 10:46 PM, Aki Tuomi wrote: > > > On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: >> OpenSSL 1.1 features a cleanup function that is automatically run on shutdown >> using atexit(3). This function frees all OpenSSL-allocated resources. >> >> In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant >>

Sorry for belaboring on a possibly minor point here, but is my understanding correct that even assuming that the case function is always inlined so we don't have extra function call overhead, we have the redundant if (!Result) checks when we use StringSwitch as opposed to a bunch of if- elses. Thanks. On Mon, Feb 8, 2016 at 12:00 PM, Anupama Chandrasekhar < anupama.lists at gmail.com>

> On Feb 5, 2016, at 4:42 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Feb 5, 2016, at 2:43 PM, Anupama Chandrasekhar via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi: >> >> I have a question about the llvm StringSwitch class. Why is this more efficient than comparing the hashes of the strings or just

On Fri, Aug 20, 2010 at 1:03 PM, Bagel <bagel99 at gmail.com> wrote: > I propose a new intrinsic "llvm.memcmp" that compares a block of memory > for equality (a subset of the libc behavior).  Backends are free to use the > alignment to optimize using wider than byte operations.  Since the result is > only equal/not-equal, byte order is not important. > > For

If we are considering an optimization to convert calls to memcmp into bcmp, then does it make sense to add an intrinsic for bcmp like there is for memcmp? That way IR writers can express their requirements precisely: memcmp if you care about the direction of inequality, and bcmp if you do not. On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: