Index out of bounds question

[Method Man]

Say I have the following:

int main(void) {
char* p, q;
p = (char*) malloc(sizeof(c har)*10);
q = (p + 100) - 99; /* legal? */
free(q - 1); /* legal? */
....
return 0;
}

Will this program always produce UB, always work, or is it compiler
dependent?

[E. Robert Tisdale]

Method Man wrote:

Say I have the following:
#include <stdlib.h>
int main(int argc, char* argv[]) {
char* p = (char*)malloc(s izeof(char)*10) ;
char* q = (p + 100) - 99; // illegal!
free(q - 1); // illegal!
// ....
return 0;
} Will this program always produce UB?
This is an improper question.
Undefined Behavior (UB) is undefined.
There is no specific behavior to "produce".
Always work?
It works everywhere.
Or is it compiler dependent?

There are no ANSI/ISO C99 compliant compilers
that will not accept this code
and generate the expected output.

[Ben Pfaff]

"Method Man" <a@b.c> writes:

Say I have the following:

int main(void) {
char* p, q;
This is deceptive syntax. It *looks* like it's meant to declare
two pointers, but it *actually* declares a pointer and an
integer.
p = (char*) malloc(sizeof(c har)*10);
I don't recommend casting the return value of malloc():

* The cast is not required in ANSI C.

* Casting its return value can mask a failure to #include
<stdlib.h>, which leads to undefined behavior.

* If you cast to the wrong type by accident, odd failures can
result.

Some others do disagree, such as P.J. Plauger (see article
<9s************ *****@nwrddc01. gnilink.net>).

When calling malloc(), I recommend using the sizeof operator on
the object you are allocating, not on the type. For instance,
*don't* write this:

int *x = malloc (128 * sizeof (int)); /* Don't do this! */

Instead, write it this way:

int *x = malloc (128 * sizeof *x);

There's a few reasons to do it this way:

* If you ever change the type that `x' points to, it's not
necessary to change the malloc() call as well.

This is more of a problem in a large program, but it's still
convenient in a small one.

* Taking the size of an object makes writing the statement
less error-prone. You can verify that the sizeof syntax is
correct without having to look at the declaration.

Finally, sizeof(char) is always 1.
q = (p + 100) - 99; /* legal? */
Constraint violation that requires a diagnostic. See C99
6.5.16.1 "Simple assignment". Also, the pointer arithmetic
yields undefined behavior, because you're going beyond
one-past-the-end in an array.
free(q - 1); /* legal? */
Also a constraint violation. See C99 6.5.2.2 "Function calls"
para 2.
....
return 0;
}

Will this program always produce UB, always work, or is it compiler
dependent?

It won't compile without diagnostics. It also produces undefined
behavior.
--
Ben Pfaff
email: bl*@cs.stanford .edu
web: http://benpfaff.org

[Dave Vandervies]

In article <sp************ *****@read1.cgo cable.net>, Method Man <a@b.c> wrote:

Say I have the following:

int main(void) {
char* p, q;
p = (char*) malloc(sizeof(c har)*10);
Don't Do That.
This line is broken, since you forgot to #include <stdlib.h>; the compiler
incorrectly assumes (as required by the language definition) that malloc
returns int, and your cast prevents it from complaining about attempting
an invalid conversion (from int to pointer).
Preferred form:
p = malloc(10 * sizeof *p);
Since sizeof(char) is required to be 1, in this case you can even do:
p = malloc(10);
q = (p + 100) - 99; /* legal? */
No, but unlikely to cause problems on systems with a flat memory space
and general-purpose registers used for both pointer and integer operations
(that is, pretty much any system you're ever likely to use).
free(q - 1); /* legal? */
If q is a valid pointer to 1 past the pointer you got from malloc (which,
as noted above, is the only result you're likely to see from the line
above), this is legal and will do exactly what you appear to expect.
....
Badly formed code.
return 0;
}
Will this program always produce UB, always work, or is it compiler
dependent?

Always produce UB, and almost always (but compiler and, more likely,
hardware dependent) do the "exactly what you expect" that's the worst
possible kind of UB (except perhaps the "exactly what you expect, until
somebody important is watching" kind).

A system that checks every pointer value generated (such systems are
well within the bounds of the requirements on implementations , though
I'm not sure if any actually exist) can trap after evaluating `(p+100)'
(the left operand of the '-' operator in the line of code you're asking
about), since this generates a pointer that's 90 bytes past the end
of the chunk of memory allocated by malloc. Most systems only check
pointers (if at all) when you dereference them and not when you create
them, and since you never dereference this particular invalid pointer,
this check won't catch it.
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
Since you're a hobbyist, I'm sure you'll want to write the code more
correctly than a mere professional might do.
--Richard Heathfield in comp.lang.c

[Keith Thompson]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > writes:

Method Man wrote:

Say I have the following:

#include <stdlib.h>

int main(int argc, char* argv[]) {
char* p = (char*)malloc(s izeof(char)*10) ;
char* q = (p + 100) - 99; // illegal!
free(q - 1); // illegal!
// ....
return 0;
}

Will this program always produce UB?

This is an improper question.
Undefined Behavior (UB) is undefined.
There is no specific behavior to "produce".

Always work?

It works everywhere.

Or is it compiler dependent?

There are no ANSI/ISO C99 compliant compilers
that will not accept this code
and generate the expected output.

Tisdale has lied to us yet again. The code quoted above is not what
Method Man wrote. It's obvious that Tisdale isn't going to respond to
complaints, so I'll just post this as a warning to others.

The actual code was:

] int main(void) {
] char* p, q;
] p = (char*) malloc(sizeof(c har)*10);
] q = (p + 100) - 99; /* legal? */
] free(q - 1); /* legal? */
] ....
] return 0;
] }

Method Man's code had serious error: "char *p, q;" declares p as a
pointer to char, and q as a char. Tisdale, for some unfathomable
reason, decided to quietly pretend the error didn't exist rather than
tell Method Man about it.

(Note to Mabden: Based on your past behavior I expect you'll jump in
and flame me for calling Tisdale on his lie. I know your opinion on
the matter and I'm really not interested in hearing about it again.)

Assuming the declaration is corrected to

char *p, *q;

the evaluation of p + 100 invokes undefined behavior, because it
yields a value outside the bounds of the memory allocated by malloc().
Once undefined behavior is invoked, all bets are off.

If you change the statement
q = (p + 100) - 99;
to
q = (p + 10) - 9;
there's no problem; p+10 points just past the last element of the
allocated memory (which is ok as long as you don't dereference it),
and q then points to p[1]. q - 1 is then equal to p, and passing that
value to free() is valid.

Will it "work"? Quite possibly. The possible consequences of
undefined behavior always include behaving just as you expect
(assuming you have any expectation). It may or may not be the case
that the code "works" in all existing implementations , but a
bounds-checking implementation with fat pointers could easily trap.
The only sensible thing to do is avoid the undefined behavior in the
first place.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Dollin]

E. Robert Tisdale wrote:

Method Man wrote:

Say I have the following:

#include <stdlib.h>

int main(int argc, char* argv[]) {
char* p = (char*)malloc(s izeof(char)*10) ;
char* q = (p + 100) - 99; // illegal!

Excuse me, Sir, but you are mis-quoting the Man.

Don't do that.

--
Chris "electric hedgehog" Dollin

[Joona I Palaste]

Chris Dollin <ke**@hpl.hp.co m> scribbled the following:

E. Robert Tisdale wrote:

Method Man wrote:

Say I have the following:
#include <stdlib.h>

int main(int argc, char* argv[]) {
char* p = (char*)malloc(s izeof(char)*10) ;
char* q = (p + 100) - 99; // illegal!

Excuse me, Sir, but you are mis-quoting the Man. Don't do that.

Telling Tisdale not to mis-quote people is like telling P.J.Plauger not
to advertise his compiler, Dan Pop not to tell people to engage their
brains, or me not to insult people. I.e. like talking to a brick wall.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American

[Dan Pop]

In <ck**********@o ravannahka.hels inki.fi> Joona I Palaste <pa*****@cc.hel sinki.fi> writes:

Telling Tisdale not to mis-quote people is like telling P.J.Plauger not
to advertise his compiler,

Huh?!?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dave Vandervies]

In article <ck**********@s unnews.cern.ch> , Dan Pop <Da*****@cern.c h> wrote:

In <ck**********@o ravannahka.hels inki.fi> Joona I Palaste
<pa*****@cc.he lsinki.fi> writes:

Telling Tisdale not to mis-quote people is like telling P.J.Plauger not
to advertise his compiler,

Huh?!?

Since, as far as I know, PJP doesn't have a compiler to advertise,
telling him not to advertise it wouldn't do much good, would it?

(Though I think Joona really meant to say Jacob Navia here.)
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
I should also have said that it's perfectly possible to do this in
multiple dimensions. Just hurts a bit to think about...
--Peter Boyle in comp.arch

[Joona I Palaste]

Dave Vandervies <dj******@csclu b.uwaterloo.ca> scribbled the following:

In article <ck**********@s unnews.cern.ch> , Dan Pop <Da*****@cern.c h> wrote:

In <ck**********@o ravannahka.hels inki.fi> Joona I Palaste
<pa*****@cc.h elsinki.fi> writes:

Telling Tisdale not to mis-quote people is like telling P.J.Plauger not
to advertise his compiler,
Huh?!?

Since, as far as I know, PJP doesn't have a compiler to advertise,
telling him not to advertise it wouldn't do much good, would it? (Though I think Joona really meant to say Jacob Navia here.)

Yes, I meant Jacob Navia. Sorry.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III