# Re: How to make (ptr + len) > lim safe?

Michael B Allen wrote:
I like to use limit pointers as sentinels when working on buffers
of data. Meaning I use ptr < lim where ptr and lim are both pointers
rather than n > 0 to determine if it is safe to proceed writing to that
location. The rationale is that it is simpler and thus safer because
you're not constantly recomputing integer n.

However, I've run into a case where this fails and I'd like to know what
the experts would do.

If I want to precompute if a pointer plus a length will exceed the limit
pointer I have a condition that can easily fail. There are two possible
expressions:
....
2) Compute the available space between the limit and pointer and compare
that to the required length:

if ((lim - ptr) =< len)
return -1;

This is also not ok because if lim is (char *)-1 and ptr is relatively
small, the computed space is still negative and thus the condition is
false.

That's not guaranteed by the standard. The result of (char*)-1 "is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation" (6.3.2.3p5). The standard doesn't even attach any meaning to the concept "ptr is relatively small".

It depends entirely upon your implementation whether those facts are relevant to the question of whether or not lim-ptr is negative. The standard says nothing from which you can draw any conclusions about it.

....
Note that I always also check to make sure lim != NULL and that ptr < lim.

However, if ptr and lim both point into or one past the end of the same array, and if ptr < lim, then lim-ptr has to be positive, and that is something the standard does say. Not directly, but by inference from what it says about the binary '-' operator and the '<' operator, when acting on pointers:

6.5.6p9: "When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements."

6.5.8p5: "... pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values."

Since ptr<lim, lim points to an array element with a larger subscript value than the one ptr points at. The difference of the pointers is equal to the difference of the subscripts, and therefore has to be positive.
.

## Relevant Pages

• [RFCv2][PATCH] flexible array implementation
... I call it a flexible array. ... storage for pointers to the second level. ... all locking must be provided by the caller. ... make sure to pass in &ptr instead of ptr. ...
(Linux-Kernel)
• Re: [RFCv2][PATCH] flexible array implementation
... I call it a flexible array. ... storage for pointers to the second level. ... all locking must be provided by the caller. ... make sure to pass in &ptr instead of ptr. ...
(Linux-Kernel)
• [PATCH] flex_array: add helpers to get and put to make pointers easy to use
... Getting and putting arrays of pointers with flex arrays is a PITA. ... wacky casting to get the ptr back from the _get. ... the array. ...
(Linux-Kernel)
• Re: Dusty Deck and C memory manager, Part 1
... CMEMC.C -- C memory management routines for use with FORTRAN. ... Return an index into ARRAY representing LENGTH words of available ... void *ptr, *malloc; ... Rather than introduce Cray pointers and use C routines to allocate memory for Fortran arrays, you could use straight F90, for example: ...
(comp.lang.fortran)
• Re: How to make (ptr + len) > lim safe?
... if ptr and lim both point into or one past the end ... of the same array, and if ptr < lim, then lim-ptr has to be ... "When two pointers are subtracted, ...
(comp.lang.c)