Re: why the usage of gets() is dangerous.

Richard Bos wrote:
Tor Rustad <tor_rustad@xxxxxxxxxxx> wrote:

[...]

His solution requires the use of "fat pointers", which are not
Methinks, fat pointers break pointer arithmetic and thus require at least a new language dialect.

No, they don't.

Hmm... what about volatile, extern and variable-length arrays? Also, I expect GC's, to do low-level pointer magic.

Pointer arithmetic beyond the bounds of an object has
undefined behaviour anyway,

Off-by-one is allowed, see e.g. response to DR #76 and DR #221.

N1256 6.5.6p8:

"Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the
array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated."

For example:

int a[10], *p;

p = (a + 11) - 1; /* UB */
p = a + 10; /* No UB, but off-by-one */
(&*p); /* No UB in C99, but off-by-one */


and within an object it works fine with fat
pointers. Adding an integer to a pointer is now a matter of adding it to
a single field of the pointer structure, rather than to a flat index,
but something similar is needed with, e.g., segmented architectures.

Well, it appears to me that that segmented architectures capable of C99, might not be able to have 65535 bytes for an object, when using fat pointers.

Also, the buffer passed to gets() may not be malloc'ed, but can be an array, or even a sub-array.

So? A sub-array simply has it recorded, in its fat pointer data, that it
is a sub-array, and what of.

So... the compiler would generate instrumented code then, lots of run-time checks! This is getting far to theoretical.. fat pointers
make sense to me, *if* C had such a new pointer type, else everyone need to use "the same" compiler, or how do you suggest we link in libraries in practice?

--
Tor <bwzcab@xxxxxxxxx | tr i-za-h a-z>
.

Relevant Pages

  • Re: How to make (ptr + len) > lim safe?
    ... subtracting two pointers into the same array, ... difference of the subscripts, after conversion to ptrdiff_t". ... elements of the same array object, ... 79)Another way to approach pointer arithmetic is first to ...
    (comp.lang.c)
  • Re: squeeze function
    ... You can increment one past the end, but you cannot access or update ... Addition or subtraction of a pointer into, or just beyond, an array ... object and an integer type produces a result that does not point into, ... the same array object. ...
    (comp.lang.c)
  • Re: end of array
    ... C99 6.5.2.1p2, Array subscripting: ... # is a subscripted designation of an element of an array object. ... # from a pointer, the result has the type of the pointer operand. ...
    (comp.lang.c)
  • Re: Passing a two dimensional array to function
    ... One of the expressions shall have type ``pointer to ... element of an array object. ... operator, if E1 is an array object (equivalently, a pointer ... Here x is a 3+5 array of ints; more precisely, ...
    (comp.lang.c)
  • Re: one past the last element of an array object
    ... "If both the pointer operand and the result point to elements of the ... same array object, or one past the last element of the array object, ... First of all what is the meaning of "overflow" here? ... char *p1, *p2; ...
    (comp.lang.c)