kconfig_compiler4

[Thomas Braxton]

On Tuesday 10 January 2006 14:42, David Faure wrote:
> On Tuesday 10 January 2006 21:34, Till Adam wrote:
> > On Thursday 29 December 2005 07:56, Thomas Braxton wrote:
> > > On Thursday 29 December 2005 00:13, Thiago Macieira wrote:
> > > > Thomas Braxton wrote:
> > > > >Int64 was already there I just changed Int -> Int32 to be more
> > > > > explicit about it's size, and got rid of Long which was ambiguous.
> > > > > Anyways how would you be able to tell if a single byte was an int8
> > > > > or a char?
> > > >
> > > > It's up to the implementation to decide that. My point is: using (or
> > > > not using) sizes to denote the various int types is an arbitrary
> > > > decision, just as using one single int type.
> > >
> > > so what do you think we should do about it? i haven't recieved any
> > > feedback on my post about kconfig_compiler/Int/Int32.
> > > http://lists.kde.org/?l=kde-core-devel&m=113562560619127&w=2
> >
> > I don't think it makes much sense to let users of kconfigXT speculate as
> > to the number of bits used for storing their integer config value. If
> > they worry it might not be enough, give them a "very large" type, in
> > addition to "UInt". I would propose to do as the QVariants do, and use
> > UInt and ULongLong, instead of the current Int32 and Int64.
>
> I agree; this is perfectly in line with the recent "port" of KConfig to
> QVariant; we'd better use the same type system otherwise it will be a mess.
How about this patch? The only problem I have is with kcfg.xsd, is there a way 
to make it output a warning for using deprecated types? If not, should we 
allow both types for now and just remove them before KDE4 ships. And does the 
version of kcfg.xsd need to change?

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: longlong.diff.gz
Type: application/x-gzip
Size: 2632 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060111/989e7cea/attachment.bin>