Re: linux-next: kbuild tree build failure

[Sam Ravnborg <sam@ravnborg.org>]

Hi Roman.

I thought a bit more about this.

> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header.

We use Kconfig for a mixture of user editable values and fixed
configuration values.
And I agree that asking the user to input a 64 bit number is not usefull.

But keeping support for 64 bit values is what I would consider
expected functionality.
So removing support for 64 bit is not good IMO.

> This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).

We use strtol() in a few places in symbol.c already where we do an
implicit conversion to int. Why did this not cause us problems before?

Is it because these code paths are only triggered when we deal with ranges?
If so we could 'fix' strdup_type() to not use strto{,u}l() so it
is 64 bit clean and we are back to old behaviour.

	Sam