openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kovacs <Pe...@Apache.org>
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 
PackedPixelRowIterator

So in result we would get

                                 nonstandard Iterator
                                             A
                                             |
                            PackedPixelIterator
                                   A              
A
                                    |               
|
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.

Opinions?

All the best
Peter

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 <truckman@apache.org>:
>> 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
>>>>
>>>> '../unxlngx6.pro/slo/bitmapdevice.obj'
>>>>
>>>>
>> /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: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message