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]
