buggrep - Bugs: bug #39334, obstack code is non portable

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #39334: obstack code is non portable

Submitter:  David Monniaux <monniaux>
Submitted:  Mon 24 Jun 2013 07:42:52 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Mon 24 Jun 2013 07:42:52 PM UTC, original submission:  

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).


David Monniaux <monniaux>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by monniaux (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code