trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2016

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

From: Michele Calgaro <michele.calgaro@...>
Date: Thu, 18 Aug 2016 00:18:23 +0800
On 2016/08/17 09:00 AM, 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?
> 
> Cheers
> 

I think the int/long values would simply be truncated when stored into a short int, giving unpredictable values.
Does -1 have any special meaning when used in "value" field? If not, it should be safe to use it.

Cheers
  Michele


Attachments: