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 <[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
