openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kovacs <>
Subject Re: Build errors
Date Thu, 09 Nov 2017 22:01:04 GMT
I have reviewd my Issue. It seems to be a side effect of enum construction.

My guess is that with the new standard there is a new implementation of 
enum, that triggers this logic shift as a sideeffect. Not sure but from 
what I read it seems bit shifting is not commonly used in c++.

I have not reached out to the gcc folk. I think this creative use of 
enumn is maybe not the best construct to use anyhow. No need to advertise.

What I did was isolation of the code in question. Starting with the 
bit_mask definiton and expanded slowly, line by line. Then I slowly 
extended the code.

I tried both variation with ~0u and ~0.

After I start embed the Code in the enum construct it worked only with 
~0u as expected. I even found out how to switch standard. So I will 
continue my OpenOffice Compiles on 98 standard.

I hope that reduces some issues and a lot of warnings I had.

So I would like to check in a least invasiv change and replace ~0 with ~0u.
However I would like to remove the enum in a second step, since the 
construction with the enum looks to creative for my taste. 2 const 
variables should do the same trick.
Plus I would like to, in a third step, reduce code, by introducing a 
hierarchy to the classes PackedPixelColumnIterator and 

So in result we would get

                                 nonstandard Iterator
PackedPixelColumnIterator  PackedPixelRowIterator

But that needs some doing.
I would put in all 3 Things in Bugzilla but only fix the 1) step now, 
and leave the other 2 things when I have build the Code at least once.


All the best

On 08.11.2017 07:40, Peter kovacs wrote:
> Thanks a lot! I am sorry I do not have in depth skill of c/c++ and did not know what
to search for.
> Will read this up!
> Thank you so much!
> Am 8. November 2017 04:59:52 MEZ schrieb Don Lewis <>:
>> On  7 Nov, Peter Kovacs wrote:
>>> Hi there,
>>> so I tried all solutions from Dennis E. Hammilton From 2.1.2017:
>>>> Try a couple of things:
>>>>    1. Put spaces in the "=~" to be something like " = ~" in the
>> definition of bit_mask.
>>>>    2. If that makes no difference, try
>>>>             bit_mask = ~ ((value_type)(~0 << bits_per_pixel))
>>>>       and if that doesn't work, see if
>>>>             bit_mask = ~ ((int)(~0 << bits_per_pixel))
>>>>       or even
>>>>             bit_mask = (int) (~(~0 << bits_per_pixel))
>>>>       get the job done.
>>>> It seems strange for an enum being used this way.  It is a clumsy
>> way to define two numeric constants that are not involved in an
>> enumeration at all.
>>>>>        };
>>> All failed now. The Compiler is allways complaining on on the <<
>> part, ignoring the casts.
>>> Patricia suggested that I work with a "wrong" configuration back
>> then. This is definitly true. My distro enables C++17 (Letest shit
>> yadada ;) )
>>> And I do not know how to switch it off. So it could well be that over
>> time the Code broke.
>>> One possibility could be to switch all modern Standards off. But
>> maybe we should simply consider to write this part of the code again,
>> with the goal that it works with the old and new ones.
>>> So I think I will try this. It does not make any differences if I can
>> compile anyhow.
>>> Opinions?
>>> On 07.11.2017 10:23, Peter Kovacs wrote:
>>>> Hi all,
>>>> 1)
>>>> I have a build error on latest trunk while building
>>>> /usr/bin/ld: cannot find -luno_salhelpergcc3
>>>> I worked around it with build --from salhelper
>>>> Maybe some dependency is missing in registry module?
>>>> 2)
>>>> Have a build error in registry
>>>> '../'
>> /home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
>>>> required from here
>>>> ../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
>>>> negative value [-Wshift-negative-value]
>>>>       return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst
>>>> ../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
>>>> shift expression '(-1 << 4)' is negative [-fpermissive]
>>>> ../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator
>> value
>>>> for 'bit_mask' is not an integer constant
>>>>       enum {
>>>>            ^
>>>> Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
>>>> tonight. However if someone has an idea. Help is apreciated.
>> On a two-complement machine, ~0 evaluates to -1, and in C, the result
>> of
>> shifting a negative value is undefined.  Most machines will do an
>> arithmetic shift, but some machines (powerpc?) don't have arithmetic
>> shift hardware and will do a logical shift.  Try changing ~0 to ~0u so
>> that it is treated as an unsigned value, which is probably what is
>> intended here.  It shouldn't make a difference for -1, but it does make
>> a difference for other negative values.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message