[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdelibs/kdecore/kconfig_compiler
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2004-06-26 2:42:08
Message-ID: 200406252242.10775.mo002j () mail ! rochester ! edu
[Download RAW message or body]

On Friday 25 June 2004 09:41 pm, Scott Wheeler wrote:
> On Friday 25 June 2004 19:43, Reinhold Kainhofer wrote:
> > Hmm, okay. How can you ensure then that the enum always has enough bits,
> > so that in the future you can add values to the enum without breaking
> > binary compatibility?
>
> I can't say that I understand where this will be an issue.  These types are
> local to the autogenerated files that shouldn't be installed.  And besides
> that the KConfig compiler is mostly used for applications rather than
> libraries.
>
> I may just be missing something here -- but I don't really understand the
> problem that you're getting at.  If I did I would probably suggest using
> the ## operator to concatenate some symbols in a macro to make sure that
> it's specific to that enum.  :-)

What I think he was referring to is this --- if you have 
enum Foo
{
	F1,
	F2,
	F3
};

The type Foo has the logical size of 2 bits in C++, even though it may take a 
lot more in memory. This means that if you try to assign 7 to it, it'll do 
something unexpected, like truncate it or such. So adding values outside the 
current range can sometimes cause problems[1]. A solution is to put in 
something like MaxVal = 0xFFFF to the enum to reserve plenty of bits. 
-However- I fail to see how the original code addressed that.

[1] I think gcc-3.3 was the first g++ version where it happened, but it occurs 
with non-GNU compilers, too; the problem affected KHTML
[prev in list] [next in list] [prev in thread] [next in thread]