[Python-checkins] r46002 - in python/branches/release24-maint: Misc/ACKS Misc/NEWS Objects/unicodeobject.c

["Martin v. Löwis"]

M.-A. Lemburg wrote:
> I don't understand - what's undefined in:
> 
> const char *s;
> Py_UNICODE *p;
> ...
> *p = *(Py_UNICODE *)s;

ISO/IEC 9899:1999, section 6.3.2.3, paragraph 7:

# A  pointer  to  an  object  or  incomplete type may be
# converted to a pointer to a different object  or  incomplete
# type.   If the resulting pointer is not correctly aligned 57)
# for  the  pointed-to  type,  the  behavior   is   undefined.
# ...

Footnote 57 says

# In   general,   the   concept  ``correctly  aligned''  is
# transitive: if a pointer to type A is  correctly  aligned
# for  a  pointer  to  type  B,  which in turn is correctly
# aligned for a pointer to type C, then a pointer to type A
# is correctly aligned for a pointer to type C.

So if "s" is not correctly aligned for Py_UNICODE, the
behaviour is undefined.

>> If you want to drop usage of memcpy on systems where you
>> think it isn't needed, you should make a positive list of
>> such systems, e.g. through an autoconf test (although such
>> a test is difficult to formulate).
> 
> I don't want to drop memcpy() - just keep the existing
> working code on platforms where the memcpy() is not
> needed.

I can understand that wish. However, by conditionalizing
it for SPARC, you still break the code for all the other
platforms where the memcpy *is* needed.

> Last time I checked this (some years ago), the above
> direct copy was always faster. Some compilers didn't even
> inline the memcpy() as you would expect.

It might have been always faster in all the cases that
you checked - however, I very much doubt that it was
always faster on all platforms on which you could have
checked it at the time. If you had checked it on all
possible platforms, you would have noticed that this
involves unaligned accesses.

> What's wrong with the direct copy ?

It creates unaligned accesses.

> A modern compiler should know the alignment requirements
> of Py_UNICODE* on the platform and generate appropriate
> code.

No. The C standard doesn't require it to, and the compilers
don't generate less efficient code just to support buggy
C code.

> AFAICTL, only 64-bit platforms are subject to any
> such problems due to their requirement to have pointers
> aligned on 8-byte boundaries.

Your impression is incorrect: The problem occurs on all
systems that require aligned acesses (i.e. SPARC, PowerPC,
Itanium, ...); whether these systems use 32-bit or 64-bit
processors is irrelevant.

On these processors, it also depends on the operating system.
For example, Linux will, by default, "correct" unaligned
accesses, and only create a syslog entry. This is very
expensive (it causes a bus error, and an opcode emulation
in the kernel), and can be disabled at the user's option.

Regards,
Martin