trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2016

Re: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect

From: Slávek Banko <slavek.banko@...>
Date: Thu, 18 Aug 2016 20:55:38 +0200
On Wednesday 17 of August 2016 16:26:26 Jim wrote:
> On Wed, Aug 17, 2016 at 03:00 (+0200), Slávek Banko wrote:
> > Hi all,
> >
> > I noticed during current builgs, on Ubuntu 16.10 (Yakkety) and now
> > also on Debian 9 (Stretch) was changed the default compiler to GCC6.
> > This brings the number of new FTBFS. That's why I started to
> > concentrate on these FTBFS. Note - for this reason the packages for
> > Yakkety in Preliminary Stable Builds are now inconsistent.
> >
> > As a first, of course, I started with tdelibs. Most were simple
> > conflict signed / unsigned char or int. However, one serious problem
> > is here.
> >
> > In the 'kjs' and 'tdehtml/ecma' is used HashEntry structure that
> > contains the item 'value' of type short int - see 'kjs/lookup.h'.
> > Into this item was stored values DOM::NodeFilter::ShowCode::SHOW_ALL
> > = 0xFFFFFFFF (see tdehtml/dom/dom2_traversal.h) and kjs event CHANGE
> > with value 32768 (see tdehtml/ecma/kjs_events.cpp). Both are
> > therefore outside the range of short int.
> >
> > Changing the type of 'value' in HashEntry from short to long would
> > apparently cause a change in ABI - kjs/lookup.h is part of the public
> > includes. That's why I made the change values 0xFFFFFFFF and 32768 to
> > -1. I think that GCC compilers version less than 6 will store these
> > values in the same way. Therefore, I believe that the proposed patch
> > would not cause problems == can be pushed. What is your opinion?
>
> Is anyone compiling this for a 1's complement hardware platform?
> If so, that could be an issue (now or in the future).
>
> I don't have any gcc 6.0 machine to play with, so here are some
> alternative thoughts, for what they are worth.
>
> Would (short)0xFFFFFFFF make it happy?  Or how about ~0 (or ~(short)0)
> to get all 1 bits?
>
> Cheers.
>                                 Jim
>

It does not make sense to have in the code (short)0xFFFFFFFF. 
Combination 'short' together with the value for which is insufficient 
signed long, with the idea 'compiler will do something with this' has no 
meaningful reason.

Format ~0 looks good, but I'm afraid of possible complications:

1) hash tables are generated by kjs/create_hash_table (perl script) - it 
would have to verify what would be the behavior with expressions instead 
of simple values.

2) enum values can be used in the code for the bindings to other 
languages - such as python. Use expressions instead of simple values 
could cause problems.

Therefore, I believe that the use of the simple value -1 makes more sense.

-- 
Slávek