diff options
author | Rich Felker <dalias@aerifal.cx> | 2015-09-17 04:45:01 +0000 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2015-09-17 04:45:01 +0000 |
commit | a603a75a72bb469c6be4963ed1b55fabe675fe15 (patch) | |
tree | 74fa4590a7a59acaf8fd21bb0364dafeaaec55db /src | |
parent | ccc71e0ea881b7f6594ed95afd706442829c39fc (diff) | |
download | musl-a603a75a72bb469c6be4963ed1b55fabe675fe15.tar.gz musl-a603a75a72bb469c6be4963ed1b55fabe675fe15.tar.bz2 musl-a603a75a72bb469c6be4963ed1b55fabe675fe15.tar.xz musl-a603a75a72bb469c6be4963ed1b55fabe675fe15.zip |
remove attribute((const)) from pthread_self and errno location decls
this attribute was applied to pthread_self and the functions providing
the locations for errno and h_errno as an optimization; however, it is
subtly incorrect. as specified, it means the return value will always
be the same, which is not true; it varies per-thread.
this attribute also implies that the function does not depend on any
state, and that calls to it can safely be reordered across any other
code. however such reordering is unsafe for these functions: they
break when reordered before initialization of the thread pointer. such
breakage was actually observed when compiled by libfirm/cparser.
to some extent the reordering problem could be solved with strong
compiler barriers between the stages of early startup code, but the
specified meaning of of attribute((const)) is sufficiently strong that
a compiler would theoretically be justified inserting gratuitous calls
to attribute((const)) const functions at random locations (e.g. to
save the value in static storage for later use).
this reverts commit cbf35978a9870fb1f5c73a852c986d4fcca6c2d4.
Diffstat (limited to 'src')
0 files changed, 0 insertions, 0 deletions