Problem with use of pointer

[braton]

Hello

Have a look at this little piece of code:

signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

My question is: does the code invoke undefined behaviour, because it
tries to convert the pointer which points outside the array, or maybe
there's everything fine taking into account that just before
dereferencing, the value of pointer is set appropriately inside of
array?

Thanks for your help.
braton

[Richard Heathfield]

br****@gmail.com said:

Hello

Have a look at this little piece of code:

signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

My question is: does the code invoke undefined behaviour, because it
tries to convert the pointer which points outside the array, or maybe
there's everything fine taking into account that just before
dereferencing, the value of pointer is set appropriately inside of
array?

Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

sca + 1 is ZOG:0003, which is fine.

sc = *(sca + 1); is fine, too, and loads -1 into sc.

(sca + sc) is ZOG:0001, which points outside the object, and that
immediately means undefined behaviour. So does the cast to short *,
because there is no guarantee that ZOG:0001 is a correctly-aligned
address for a short int. Adding 4 to it /also/ invokes undefined
behaviour if sizeof(short) is big enough, and dereffing the resulting
pointer is just heaping undefined behaviour up into a big wobbly pile.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[braton]

Hello

>

Have a look at this little piece of code:

signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

My question is: does the code invoke undefined behaviour, because it
tries to convert the pointer which points outside the array, or maybe
there's everything fine taking into account that just before
dereferencing, the value of pointer is set appropriately inside of
array?

Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

sca + 1 is ZOG:0003, which is fine.

sc = *(sca + 1); is fine, too, and loads -1 into sc.

(sca + sc) is ZOG:0001, which points outside the object, and that
immediately means undefined behaviour. So does the cast to short *,
because there is no guarantee that ZOG:0001 is a correctly-aligned
address for a short int. Adding 4 to it /also/ invokes undefined
behaviour if sizeof(short) is big enough, and dereffing the resulting
pointer is just heaping undefined behaviour up into a big wobbly pile.

I forgot mention that sizeof(short)==2 so if addition of 4 would be
possible then pointer would points to 1 in array, but I see it won't
reach that far.
Thank you for clarification!
braton

[Thad Smith]

br****@gmail.com wrote:

>>>signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

>>>My question is: does the code invoke undefined behaviour,

(sca + sc) is ZOG:0001, which points outside the object, and that
immediately means undefined behaviour. So does the cast to short *,
because there is no guarantee that ZOG:0001 is a correctly-aligned
address for a short int. Adding 4 to it /also/ invokes undefined
behaviour if sizeof(short) is big enough, and dereffing the resulting
pointer is just heaping undefined behaviour up into a big wobbly pile.

I forgot mention that sizeof(short)==2 so if addition of 4 would be
possible then pointer would points to 1 in array, but I see it won't
reach that far.

Keep in mind that if you ask if behavior is defined in this newsgroup,
the assumed context is definition by the C Standard, which doesn't
specify sizeof(short). If you want to know if the behavior of your code
is defined for a particular implementation, then you need to ask
somewhere that addresses that implementation.

--
Thad

[p_cricket_guy]

Richard Heathfield wrote:

br****@gmail.com said:

Hello

Have a look at this little piece of code:

signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

My question is: does the code invoke undefined behaviour, because it
tries to convert the pointer which points outside the array, or maybe
there's everything fine taking into account that just before
dereferencing, the value of pointer is set appropriately inside of
array?

Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

[Richard Heathfield]

p_***********@yahoo.co.in said:

>
Richard Heathfield wrote:

>>
Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

My claim was they are not "wholly numeric" - although wholly non-numeric
values are not forbidden by the Standard, they don't sound terribly
useful, do they?

And yes, there are examples of implementations where addresses are not
wholly numeric. The following code fragment:

sprintf(s, "%p", (void *)ptr); /* get text rep of ptr */
printf("%.2s\n", s); /* print first two characters only */

when put into suitable clothes and executed under MS-DOS, might well
give you an output such as "SS", "DS", or something similar.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Eric Sosman]

p_***********@yahoo.co.in wrote:

Richard Heathfield wrote:

>[...]
Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

This is a variant of Question 5.17 in the comp.lang.c
Frequently Asked Questions (FAQ) list at <http://c-faq.com/>.

--
Eric Sosman
es*****@acm-dot-org.invalid

[pete]

br****@gmail.com wrote:

>
Hello

Have a look at this little piece of code:

signed char sca[] = {2,-1,4,3,5,3,-8,1,9,2,3,6,-1,0,12,2};
signed char sc = *(sca+1);
short s = *((short*)(sca+sc)+4);

My question is: does the code invoke undefined behaviour,

Yes.

because it
tries to convert the pointer which points outside the array, or maybe
there's everything fine taking into account that just before
dereferencing, the value of pointer is set appropriately inside of

sc is equal to -1, which makes (sca+sc) undefined.

printf("sc is %d\n", sc);

N869
6.5.6 Additive operators
Constraints
[#8]
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.

--
pete

[Richard Tobin]

In article <46**********@mindspring.com>, pete <pf*****@mindspring.comwrote:

>short s = *((short*)(sca+sc)+4);

>sc is equal to -1, which makes (sca+sc) undefined.

An example of the non-associativity of addition in C. You don't need
pointers for it: if INT_MAX is 32767 then

(32767 + 1) + (-1)

is undefined, though

32767 + (1 + (-1))

is 32767.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

p_***********@yahoo.co.in said:

>Richard Heathfield wrote:

>>>
Let's start off by assuming that sca is at address ZOG:0002

(The ZOG part is just to remind us that pointers need not be wholly
numeric values.)

Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

My claim was they are not "wholly numeric" - although wholly non-numeric
values are not forbidden by the Standard, they don't sound terribly
useful, do they?

Well, sort of. The representation of any pointer value (like the
representation of anything other than a bit field) must be composed of
bytes, and bytes must be composed of bits. So there's always going to
be a way to represent a pointer value as a number, though perhaps not
uniquely, and the resulting number might not be meaningful. (And it
might be bigger than any numeric type supported by the
implementation.)

The more relevant question, I think, is whether pointers can always be
viewed as numbers with a straightforward linear relationship between
the numeric values and memory addresses. The answer to that is no
(though such a relationship does exist on many systems, perhaps most
of them).

And yes, there are examples of implementations where addresses are not
wholly numeric. The following code fragment:

sprintf(s, "%p", (void *)ptr); /* get text rep of ptr */
printf("%.2s\n", s); /* print first two characters only */

when put into suitable clothes and executed under MS-DOS, might well
give you an output such as "SS", "DS", or something similar.

The conversion performed by "%p" is implementation-defined; in this
case, the implementation chose to use things like "SS" and "DS" rather
than numbers because that's what makes the most sense on that system.

Pointers are numeric in the sense that *everything* is numeric,
because everything is made of bits. But in the most general case,
pointers are numeric *only* in that sense.

Richard's basic point is entirely correct, as it usually is; I'm
merely quibbling about semantics.

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

In article <11**********************@e65g2000hsc.googlegroups .com>
<p_***********@yahoo.co.inwrote:

>Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

Perhaps you mean "such a machine". They do exist -- even the x86
*can* work this way, although it "never" (?) does in practice --
but they were much more common in the past. I have seen mention
of a machine that used "floating-point pointers" (I have no idea
how this worked), and machines that used segment tables were
pretty common in the 1970s.

See also <http://web.torek.net/torek/c/numbers2.html>.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Richard Tobin wrote:

>
In article <46**********@mindspring.com>, pete <pf*****@mindspring.comwrote:

short s = *((short*)(sca+sc)+4);

sc is equal to -1, which makes (sca+sc) undefined.

An example of the non-associativity of addition in C. You don't need
pointers for it: if INT_MAX is 32767 then

(32767 + 1) + (-1)

is undefined, though

32767 + (1 + (-1))

is 32767.

On my machine where FLT_ROUNDS equals 1,
if x and y are set equal to (4 * DBL_EPSILON / 3)
and z is set equal to 2.0, then
((x + y) + z) is less than (x + (y + z))
and
((x + y) + z) equals (y + z)

/* BEGIN epsilon.c */

#include <stdio.h>
#include <float.h>

int main(void)
{
double x, y, z;

puts("/* BEGIN ouptput from epsilon.c */");
printf("\nFLT_ROUNDS is %d\n\n", FLT_ROUNDS);
x = y = 4 * DBL_EPSILON / 3;
puts("x = y = 4 * DBL_EPSILON / 3;");
z = 2.0;
puts("z = 2.0;\n");
if ( (x + y) + z == x + (y + z) ) {
puts("(x + y) + z == x + (y + z)");
}
if ( (x + y) + z x + (y + z) ) {
puts("(x + y) + z x + (y + z)");
}
if ( (x + y) + z < x + (y + z) ) {
puts("(x + y) + z < x + (y + z)");
}
if ( (x + y) + z == y + z) {
puts("(x + y) + z == y + z");
}
puts("\n/* END ouptput from epsilon.c */");
return 0;
}

/* END epsilon.c */
--
pete

[pete]

Keith Thompson wrote:

Pointers are numeric in the sense that *everything* is numeric,
because everything is made of bits. But in the most general case,
pointers are numeric *only* in that sense.

Pointers are more numeric than that.

Pointers are scalar types,
which makes pointers more numeric than nonscalar types.

There are arithmetic operators and other operators
that can be used with pointers and arithmetic types,
but not with nonscalar types such as stuctures and arrays.

--
pete

[CBFalconer]

p_***********@yahoo.co.in wrote:

>

.... snip ...

>
Are there any examples of implementations where addresses are not
numeric values? I understand you point but just curious to know if
such an address really exists.

Yes.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

>Pointers are numeric in the sense that *everything* is numeric,
because everything is made of bits. But in the most general case,
pointers are numeric *only* in that sense.

Pointers are more numeric than that.

Pointers are scalar types,
which makes pointers more numeric than nonscalar types.

There are arithmetic operators and other operators
that can be used with pointers and arithmetic types,
but not with nonscalar types such as stuctures and arrays.

Hmm. That's one way to look at it, I suppose.

The way I look at it is that numeric types are a subset of scalar
types, which in turn are a subset of object types. Pointers are
scalar, but not numeric.

<OT>In Perl, for example, strings are "scalar", but they're certainly
not numeric.</OT>

On the other hand, the standard's definition of "alignment" is vaguely
troubling (C99 3.2):

alignment

requirement that objects of a particular type be located on
storage boundaries with addresses that are particular multiples of
a byte address

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

>
pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

Pointers are numeric in the sense that *everything* is numeric,
because everything is made of bits. But in the most general case,
pointers are numeric *only* in that sense.

Pointers are more numeric than that.

Pointers are scalar types,
which makes pointers more numeric than nonscalar types.

There are arithmetic operators and other operators
that can be used with pointers and arithmetic types,
but not with nonscalar types such as stuctures and arrays.

Hmm. That's one way to look at it, I suppose.

The way I look at it is that numeric types are a subset of scalar
types, which in turn are a subset of object types. Pointers are
scalar, but not numeric.

"numeric types" isn't a technical term in C.
The standard describes scalars as being compsed of pointers
and "arithmetic types".

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

[...]

>The way I look at it is that numeric types are a subset of scalar
types, which in turn are a subset of object types. Pointers are
scalar, but not numeric.

"numeric types" isn't a technical term in C.
The standard describes scalars as being compsed of pointers
and "arithmetic types".

Agreed, but I didn't introduce the word "numeric" to the discussion.
I think of "numeric types" as being a synonym for "arithmetic types".
Pointers are not numeric because they're not numbers. They're not
more or less numeric than anything else; they're just not numbers.

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"