This is the mail archive of the
libc-hacker@sources.redhat.com
mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at
the archives of this list, but subscription and posting are not open.
Are __BOUNDED_POINTERS__ supported?
- From: Steven Munroe <sjmunroe at us dot ibm dot com>
- To: libc-hacker at sources dot redhat dot com, Alan Modra <amodra at bigpond dot net dot au>
- Date: Tue, 25 Mar 2003 11:30:38 -0600
- Subject: Are __BOUNDED_POINTERS__ supported?
- Reply-to: sjmunroe at vnet dot ibm dot com
Are __BOUNDED_POINTERS__ still a supported feature of glibc?
I've been looking a optimization of the string (strlen/strcmp/strcpy)
functions for PPC64 and noticed several:
/* GKM FIXME: check high bounds. */
Which was inherited from PPC32. Also that the usage of the
__BOUNDED_POINTERS_ macros don't seem correct. For example
sysdeps/powerpc/powerpc32/strchr.S contains:
L(missed):
and. rTMP1, rTMP1, rTMP2
li rRTN, 0
STORE_RETURN_VALUE (rSTR)
which will generate:
...
li rRTN, 0
stw rSTR,0(rRTN)
which will genrate a segfault. So bounded pointers are not working for
pp32/ppc64.
Then I tried using gcc to generate some examples of bounded-pointers and
bounds-checking using -fbounds-check -fbounded-pointers options. But
there is no difference in the generated asm (with or without this options).
So are __BOUNDED_POINTERS__ still supported? And should I put effort
into fixing the PPC32/PPC64 code?