16 Aug
2016
16 Aug
'16
6 p.m.
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
--
Slávek
17 Aug
17 Aug
7:26 a.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
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
9:18 a.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
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
18 Aug
18 Aug
11:55 a.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
On Wednesday 17 of August 2016 16:26:26 Jim wrote:
On Wed, Aug 17, 2016 at 03:00 (+0200), Slávek Banko
wrote:
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
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
12:05 p.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
On Wednesday 17 of August 2016 18:18:23 Michele Calgaro wrote:
On 2016/08/17 09:00 AM, Slávek Banko wrote:
There is generated more hash tables where the 'value' has the meaning
specific for each table. The tables, for which two mentioned changes
concern, has no other item with the value -1. I dare to say that values
even today could not be stored as anything other than -1.
Any other ideas, suggestions, objections?
Cheers
--
Slávek
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
3:05 p.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
On Thu, Aug 18, 2016 at 20:55 (+0200), Slávek Banko wrote:
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,
Various irrelevancies <snip>ed...
>> 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.
> how about ~0 (or ~(short)0) to get all 1 bits?
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.
Is that verification difficult?
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.
Is it difficult to check that?
Therefore, I believe that the use of the simple value
-1 makes more sense.
(FWIW) Wikipedia says
The representation used in most current computing devices is
two's complement, although the Unisys ClearPath Dorado series
mainframes use ones' complement.
Putting a -1 in there will not give you 0xFFFF on such machines.
Maybe no one cares...
Jim
7:53 p.m.
New subject: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect
On 2016/08/19 03:05 AM, Slávek Banko wrote:
There is generated more hash tables where the
'value' has the meaning
specific for each table. The tables, for which two mentioned changes
concern, has no other item with the value -1. I dare to say that values
even today could not be stored as anything other than -1.
Any other ideas, suggestions, objections?
Cheers
I will try to take a look in more detail over the weekend. I will come back on this.
Cheers
Michele
2828
days inactive
2830
days old
6 comments
3 participants
participants (3)
-
Jim -
Michele Calgaro -
Slávek Banko