[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.
> 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).
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on Fri Dec 28 06:48:47 2007