[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #39334] obstack code is non portable
From: |
David Monniaux |
Subject: |
[bug #39334] obstack code is non portable |
Date: |
Mon, 24 Jun 2013 19:42:53 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22 |
URL:
<http://savannah.gnu.org/bugs/?39334>
Summary: obstack code is non portable
Project: grep
Submitted by: monniaux
Submitted on: Mon 24 Jun 2013 07:42:52 PM GMT
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
When compiling on a non-GNU system (without glibc), grep uses its own copies
of obstack.c and obstack.h.
obstack.h contains the following code:
#define __BPTR_ALIGN(B, P, A) ((B) + (((P) - (B) + (A)) & ~(A)))
#define __PTR_ALIGN(B, P, A) \
__BPTR_ALIGN (sizeof (PTR_INT_TYPE) < sizeof (void *) ? (B) : (char *) 0, \
P, A)
On machines where sizeof(PTR_INT_TYPE) >= sizeof (void *), that is, any
machine where a pointer fits into a ptrdiff_t (a large integer type meant to
express differences between pointers), thus almost all current architectures,
the code works as follows:
It computes P-NULL, thus converts P into an integer "equal" to P, then aligns
the result to the next (A+1)-byte boundary and then back to a char* pointer;
thus overall it aligns P to the next (A+1)-byte boundary.
This, however, relies on behavior considered undefined according to the C
standard: computing the difference of two pointers in two different memory
blocks, or to NULL, yields an undefined result.
I understand that this is ok in glibc because libc functions such as malloc
anyway have to do nonstandard manipulations of memory, but I'm less
comfortable with it in general applications such as grep.
This could for instance break on a system where the compiler instruments
pointer operations to detect undefined behaviors (perhaps for security
reasons), or on a system with segmented memory but where ptrdiff_t would have
the same size as a pointer.
Also, a compiler could simply decide that, since this behavior is undefined,
it could suppress this code sequence (such things have happened: programs
reading from uninitialized variables to get "random" numbers had this read and
subsequent uses suppressed from the code by certain optimizing compilers).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?39334>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #39334] obstack code is non portable,
David Monniaux <=