Re: Looking for a temporary account on Alpha

["Frank B. Brokken" <f.b.brokken@rug.nl>]

Dear Steve Langasek, you wrote:
> 
> ... I can point at the broken code:
> 
> void gram_DEFINEMACRO()
> ...
>     size_t nargs;
>  ...
>     if (parser_number_parlist(&parser, (int *)&nargs, true) == SUCCESS)
>  ...
>         if ((size_t)nargs > 9 + 26 + 26)          /* 1-9, a-z, A-Z    */
> 
> You can't take a variable of type size_t, pass its address to a function
> that takes an argument of type int*, and count on getting a meaningful
> result back.

Well, first of all, thanks for your help. I'm sure it'll solve the problem for
the time being. But I'm left with an uneasy feeling. On the one hand I know
that what you write is true in principle. But on the other hand, I'm curious
about what might be going on in the Alpha what apparently doesn't happen on
other architectures. What's a size_t in the Alpha? If it's not in fact an
unsigned int but something bigger then I understand what's happening. The
intention here is to use size_t in situations where the value is known to be
non-negative. So, it may very well be an initialization problem, which should
then also be solved by initializing nargs to 0 when it's defined.

So, maybe you could in addition to the already provided help provide me with
some additional bits of information? What's the size of a size_t as compared
to the size of an int on Alpha? And what happens if nargs is initialized to 0
when it's defined? 

Size_t was introduced in yodl's recent code to distinguish variables having
non-negative values from those having potentially negative values. But it's
possible that there are some situations (like the above) where I failed to
make the correct conversion from int to size_t. Maybe you can provide the
answers to my additional questions?

> Based on the usage in this function, I don't see any reason why it should be
> size_t at all.  Changing nargs to an int is sufficient to fix the build
> failure on my alpha.

For now, that's still amazing...

Thanks a lot for your help, so far!

Cheers,

-- 
    Frank B. Brokken
    Computing Center, University of Groningen
    (+31) 50 363 9281
    Public PGP key: http://pgp.surfnet.nl:11371/
    Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D  B19F DAC4 BE50 38C6 6170