> On 27 Sep 2018, at 16.53, James <l...@xdrv.co.uk> wrote:
>
> On 27/09/2018 13:40, Stephan Bosch wrote:
>
>>> Address Line Code
>>> 00000000: DEBUG BLOCK: 3
>>> 00000001: EXTENSIONS [1]:
>>> 00000002: vacation
>>> 00000004: 2: VACATION
>>> 00000007: 4: seconds: NUM 5
>>> 00000009: Binary is corrupt.
>>>
>>> The line numbers differs and 86400 is read as 5. It is like it has
>>> forgotten the size of an integer or is confused about endianness.
>>> There is something strange, like an #if that guesses wrong. At least
>>> I have somewhere to start looking.
>>>
>>> Thank you for checking at your end, I was worried the RC had
>>> introduced an error and your result suggests not. RCs are for testing
>>> and I am.
>>
>> The number is stored as a chain of bytes of which the most significant
>> bit indicates whether the next byte still belongs to the number. If this
>> bit is somehow interpreted wrong, the first byte of this number would
>> read as 5, thereby returning '5' as the result and ignoring subsequent
>> bytes (causing corruption at the next item to read).
>>
>> Since you're using SunOS, your compiler may be doing something funky.
>> Which compiler is used anyway? Perhaps different versions for the
>> Dovecot releases that do and don't work?
>
> It was studio cc. gcc doesn't make it through configure and I didn't ask
> why. I have some other things to do but will look at this again later.
> Thank you for the byte code explanations. The coding at this point is hard
> to follow with the pointers-to-functions and #defines.
Can you share a little bit more info on how did the compile (or configure even)
fail with gcc on Solaris 11?
as I have no problems in compiling dovecot and pigeonhole on my Solaris 11.3
system with gcc. The version that ships with my Solaris is 4.5.2.
I also have Sun Studio 12.5 installed but I have not even tried to compile
dovecot wit that yet.
Sami
