Peter Samuelson wrote:
> [Branko Cibej]
>
>>> No need for the conditional - the following is simpler and faster.
>>>
>>>
>> Quite likely, yes -- except that you'd probably see signed-char
>> inconsistencies if you change the types involved the way you did.
>>
>
> I thought about that for awhile, and since all you're really doing is
> checking for equality / inequality, I didn't think the unqualified char
> type could be a problem. But since you want an int return value, the
> temp variables would have to be converted to int anyway at some point
> in the assembly code, so just using int might be better.
>
This is not an (in)equality check; the function should mimic the
behaviour of str(case)cmp, which is an ordering comparator, so the sign
of the return value does matter. I don't believe in gratuitously fooling
around with comparator semantics.
>> Please, make the change. :) And I'd be happier if genctype.py was
>> still used to generate the tables.
>>
>
> I can do that, but.... This isn't a terribly complex table like the
> other one genctypes.py is for. The one-line comment I put in at the
> top should be more than sufficient for anyone wondering what the table
> does. As for the current generated table format, it may be cute to
> have ASCII code names in comments, but it's rather annoying to have to
> scroll 256 lines instead of 16 lines just to read the next function.
>
> Also, I don't understand the desire to generate it automatically. If
> this table will _never_ be updated again, which I think is likely, then
> it doesn't matter whether there is code to generate it. But if it
> _will_ be updated in the future, whoever updates it will have to not
> only update the generator, but also manually cut/paste the output from
> the generator into the file. That seems like a lot more work than just
> editing the C file directly. And I say that as someone who _did_
> decide to edit the table today, and I thought it would be easiest to
> retype it by hand (with a bit of help from seq and xemacs).
>
Oh well ... I suppose you're right. It's not consistent, but the bit
about "a foolish consistency ..." has been quoted before. :)
Might as well revert the changes to genctype.py while we're at it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 28 12:27:46 2007