Python 2.2 chr representation errors with embedded C

[John Machin]

"Mark Szigety" <mszigety at cisco.com> wrote in message news:<mailman.1017411238.31523.python-list at python.org>...
> Hello,
> 
> I have recently made the upgrade to Python 2.2 from 1.5.2.  In the
> Python application which I develop, we have several embedded C
> functions, one of which is a simple function to convert a hex string to

Please post *examples*: (a) a "hex string" (b) its corresponding "100%
accurate" conversion to octal by a C routine when called by Python
1.5.2 (c) its corresponding incorrect conversion to octal by a C
routine when called by Python 2.2

> octal--it simply chars each byte and returns the new buffer.

Please explain (or post the *relevant* parts of C routine) -- the verb
"to char" has to me at least connotations not of C but of possibly
injudicious application of heat in cookery :-) -- seriously, you don't
convert from a hex representation to an octal representation by
"simply charring" each byte, for any conceivable meaning of "char".

> However, I
> have noticed a 0.01% error rate in Python 2.2 which I did not see in
> Python 1.5.2 (it was 100% accurate).  That is, 1 out of 10,000 hex
> strings will be converted incorrectly in the C function, usually one
> byte is returned as \x00 instead of what is should be.

1. Could be a NUL-terminated-string gotcher. Show us the C code.
2. And unusually it exhibits what other kind(s) of incorrect
behaviour?

> I also have
> noticed that in Python 2.2, chr(0xff) returns \xff instead of \377 in
> Python 1.5.2.

chr(0xff) has not changed; it returns "\xff" or "\377" which are just
different ways of representing exactly the *same* 1-character string.
The repr() function changed somewhere between 1.5.2 and 2.2 from
producing an octal representation to producing a hex representation.
What you are seeing is a difference in the representation of the
result of chr(), not a difference in the result itself.

> Could this be the source of the communication breakdown?

Hmmm ... this misunderstanding could have percolated into the
conversion routine. Makes me very curious to see what these "hex
strings" are.

> 
> I should mention that writing a similar conversion function totally in
> Python is 100% accurate in Python 2.2 as well as Python 1.5.2, although
> it is an order of magnitude slower.
> 

If as you say the Python routine performs correctly, please post it --
two reasons: (a) it will help define what your requirement for the C
routine is (b) the Python optimisation specialists may be able to eat
into that "order of magnitude slower".