Re: [Monotone-devel] nvm.options

[Thomas Keller]

Am 26.07.10 15:00, schrieb Thomas Keller:
> Am 26.07.10 05:40, schrieb Timothy Brownawell:
>> On 07/21/2010 05:25 PM, Thomas Keller wrote:
>>> Am 21.07.10 01:10, schrieb Thomas Keller:
>>>> Am 20.07.10 04:58, schrieb Timothy Brownawell:
>>>>> On 07/18/2010 08:19 AM, Stephen Leake wrote:
>>>>>> Tim,
>>>>>>
>>>>>> Just letting you know I've been keeping up with nvm.options, and it
>>>>>> all
>>>>>> looks very good so far.
>>>>>
>>>>> I think it's ready to merge now. See anything I missed?
>>>>
>>>> The current head (44c1dd7bbc276790c51463a83823d2e1339c7ff6) fails to
>>>> compile for me:
>>>>
>>>> base.hh: In function ‘void dump(const T&, std::string&) [with T = long
>>>> unsigned int]’:
>>>> sanity.hh:451:   instantiated from ‘void Musing<T>::gasp(std::string&)
>>>> const [with T = size_t]’
>>>> cmd.cc:640:   instantiated from here
>>>> base.hh:45: error: invalid application of ‘sizeof’ to incomplete type
>>>> ‘dump_must_be_specialized_for_this_type’
>>>> make[1]: *** [cmd.o] Error 1
>>>> make: *** [all] Error 2
>>>
>>> I added a specialization for size_t in
>>> 760adcf3915f59a0ba8e2c55ea652ef29deac477 and it compiles now.
>>
>> That *breaks* it here, since apparently u64 and size_t are the same
>> thing (while your size_t / unsigned long doesn't match u64 or u32).
> 
> TYPE_U32 is defined as `unsigned int' in my config.h and when I look at
> my stddef.h then I see that size_t is defined as `long unsigned int' and
> while sizeof(unsigned int) and sizeof(long unsigned int) are size-wise
> equal (4, ie. 32bit), the compiler doesn't pick the u32 (unsigned int)
> specialization for size_t. So maybe the bug is already that TYPE_U32
> isn't defined as `unsigned long' ?
> 
>> I guess we need an autoconf thingy for this?
> 
> I read a bit about size_t in general and it seems to be only defined as
> "unsigned integral type" saying nothing about its size. I wrote a
> minimal test which shows the problem:
> 
> 
> #include <iostream>
> using namespace std;
> 
> template <typename T> void dump(T const &)
> { cout << "no specialization picked" << endl; }
> template <> void dump(unsigned int const & v)
> { cout << "uint picked: " << v << endl; }
> template <> void dump(unsigned long const & v)
> { cout << "ulong picked: " << v << endl; }
> 
> int main(int argc, char ** argv)
> {
>    size_t t = 3;
>    dump(t);
>    return 0;
> }
> 
> When I execute this on Mac OS X, I get "ulong picked", when I execute
> this on my Fedora VM, I get "uint picked". What is now the best way to
> put something like this into an autoconf macro and what should be the
> result? Adding a specialization for size_t in case we detect the problem
> now seems to be a bit hacky from this perspective...

I've talked with Thomas Moschny and he asked on ##c++ for a proper
solution of the problem. The answers were mainly to replace all "custom
type" specializations with "real types", i.e. basically what I did
above, so u32, u64, size_t and all the others pick the proper
specialization based on their underlying type.

Now this might introduce the problem that we forget one or two
specializations on less common platforms which worked until now, because
our autoconf machinery picks different expansions for them.

For example, for s32, s64, u32 and u64 I have defined in config.h for
Mac OS X:

int
long long
unsigned int
unsigned long long

and we probably also need (at least for Linux)

long
unsigned long

(and cross fingers that they don't collide on some platforms)

What about Solaris, Windows (visualc/config.h has hardcoded int /
unsigned int for s32 / u32) and the BSDs?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature