[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

pointer = &membuff[-2];

Bo S.

6/9/2011 9:07:00 PM

Is it possible to post a basic C question in this newsgroup without
starting a flame war about "elegant" code or see answers like
"silly, nonportable hack"? I've almost stopped reading this ng since
there are usually more than 500 posts every day and most of it is
opinons and comments on other's opinion.

Anyway, I take a chance: I have stripped out a piece of code that
we have in a large application that in some circumstances will do
what this example program show. The interesting part is the

pointer = &buffer[-2]; /* is it really -2, or 4294967294 */
x = pointer->data; /* Reading something >2 unsigned's down */

It (seems to) work, I'm just wondering if we're lucky or not.
I would appreciate if anyone can explain why, or why not, without
arguing about good or bad programming style (this code has already
been redesigned but exists alive and well in older versions of
our product).

I guess buffer[-2] can be written *(buffer-2) and &buffer[-2]
will simply be (buffer-2) and pointer->data will access memory
at, say, (buffer-2)+2. But isn't n1-n2 = 4294967294 in the
example below? Ok, 4294967294+2 is 0...or?

Here's an example program:

#define _POSIX_SOURCE 1
#include <stdlib.h>
#include <stdio.h>

signed int
main(signed int argc, char ** argv)
{
unsigned int n1 = 0;
unsigned int n2 = 2;
unsigned int n3;
unsigned int *membuff;
struct dummy {
unsigned int d1;
unsigned int d2;
unsigned int d3;
} *sp;

membuff = malloc(10*sizeof(unsigned int));
membuff[0] = 54;

sp = (struct dummy *) &membuff[n1 - n2];
n3 = sp->d3;

printf("Result = %u", n3);

exit(0);

}

Bo
16 Answers

Joe Pfeiffer

6/9/2011 10:48:00 PM

0

"Bo S." <bo@boo.invalid> writes:

> pointer = &buffer[-2]; /* is it really -2, or 4294967294 */

If it's a 32 bit system, does it matter? If you take an address and add
4294967294 to it, and then truncate to 32 bits, do you get something
different from subtracting 2?

When I taught 2's complement arithmetic in sophomore assembly language
classes, the example I liked to use was an unscrupulous car seller
"rolling back" a car's odometer. Take 20,000 miles off the car's
mileage and it's worth more.

So... in addition to being illegal, car odometers are now made so they
won't wind backwards. No problem -- on a 100,000 mile odometer, just
roll it 80,000 miles forward instead. No way to tell the difference.

In effect, that's the same thing you're seeing here.

(of course, more modern yet odometers also put up a flag when they wrap
around so you can tell....)

Keith Thompson

6/10/2011 12:54:00 AM

0

"Bo S." <bo@boo.invalid> writes:
> Is it possible to post a basic C question in this newsgroup without
> starting a flame war about "elegant" code or see answers like
> "silly, nonportable hack"? I've almost stopped reading this ng since
> there are usually more than 500 posts every day and most of it is
> opinons and comments on other's opinion.
>
> Anyway, I take a chance: I have stripped out a piece of code that
> we have in a large application that in some circumstances will do
> what this example program show. The interesting part is the
>
> pointer = &buffer[-2]; /* is it really -2, or 4294967294 */
> x = pointer->data; /* Reading something >2 unsigned's down */
>
> It (seems to) work, I'm just wondering if we're lucky or not.
> I would appreciate if anyone can explain why, or why not, without
> arguing about good or bad programming style (this code has already
> been redesigned but exists alive and well in older versions of
> our product).
>
> I guess buffer[-2] can be written *(buffer-2) and &buffer[-2]
> will simply be (buffer-2) and pointer->data will access memory
> at, say, (buffer-2)+2. But isn't n1-n2 = 4294967294 in the
> example below? Ok, 4294967294+2 is 0...or?
>
> Here's an example program:
>
> #define _POSIX_SOURCE 1
> #include <stdlib.h>
> #include <stdio.h>
>
> signed int
> main(signed int argc, char ** argv)
> {
> unsigned int n1 = 0;
> unsigned int n2 = 2;
> unsigned int n3;
> unsigned int *membuff;
> struct dummy {
> unsigned int d1;
> unsigned int d2;
> unsigned int d3;
> } *sp;
>
> membuff = malloc(10*sizeof(unsigned int));
> membuff[0] = 54;
>
> sp = (struct dummy *) &membuff[n1 - n2];
> n3 = sp->d3;
>
> printf("Result = %u", n3);
>
> exit(0);
>
> }

The indexing operator is not defined in terms of any particular integer
type. If you write p[-2], then the value -2 is added to the pointer
value p, and the result is dereferenced. There is no implicit
conversion of the index value (to size_t, ptrdiff_t, or anything else);
the computation just uses the value of the index.

However, in your case the index expression is ``n1 - n2''. Both n1 and
n2 are of type unsigned int, with values 0 and 2, respectively -- which
means that the result of the subtractin is *not* -2, but UINT_MAX-2
(on your system, 4294967294U).

So your statement
sp = (struct dummy *) &membuff[n1 - n2];
is equivalent to
sp = (struct dummy *) &membuff[4294967294U];
and the behavior is undefined.

It's likely that &membuff[4294967294U] behaves the same way as
&membuff[-2], but the language doesn't guarantee it. Probably the
generated code adds the value 4294967294U to the base address,
and it quietly wraps around, ignoring any overflow. If you're
curious, take a look at the generated code (many compilers use "-S"
to generate an assembly listing).

Converting the offset value from unsigned int to int is probably
cleaner:

int offset = n1 - n2;
sp = (struct dummy *) &membuff[offset];

Here, &membuff[offset] is equivalent to &membuff[-2].

You seem to be retrieving 3 unsigned int values starting *before*
the beginning of the allocated block of memory. The language
doesn't define the behavior of attempting to do that. I'll take
your word for it that that's what you want to do and that it works.

BTW, 500 posts every day? We *might* have that many in a month
(not including spam, but my NNTP server does a good job of filtering
that out).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Eric Sosman

6/10/2011 1:02:00 AM

0

On 6/9/2011 5:07 PM, Bo S. wrote:
> Is it possible to post a basic C question in this newsgroup without
> starting a flame war about "elegant" code or see answers like
> "silly, nonportable hack"?

Yes, but choosing to antagonize from the outset is not guaranteed
to suppress flames.

Oh, sorry: s/./, you imbecile./

> pointer =&buffer[-2]; /* is it really -2, or 4294967294 */

It's really minus two.

> x = pointer->data; /* Reading something>2 unsigned's down */
>
> It (seems to) work, I'm just wondering if we're lucky or not.

That's too deep a question for me. Getting away with murder
can be good (if you think of the murder as a one-time event) or
bad (if getting away with one influences you to attempt others
until eventually you don't get away.)

Anyhow, you're just repeating Question 6.17 of the FAQ. (Since
you imply you've been a reader of this forum for some span of time,
you're surely aware of how to find the FAQ, right?)

Oh, sorry: s/?/, you pfule?/

--
Eric Sosman
esosman@ieee-dot-org.invalid

James Kuyper

6/10/2011 2:26:00 AM

0

On 06/09/2011 05:07 PM, Bo S. wrote:
> Is it possible to post a basic C question in this newsgroup without
> starting a flame war about "elegant" code or see answers like
> "silly, nonportable hack"? ...

I haven't noticed any flame wars recently about the elegance of code.

One good way to reduce (but unfortunately, not eliminate) complaints
about "silly, nonportable hack" is to avoid posting messages for which
the complaint is justified.

.... I've almost stopped reading this ng since
> there are usually more than 500 posts every day and most of it is
> opinons and comments on other's opinion.

Your estimate of the volume of this newsgroup seems to be high by about
an order of magnitude.
If you'd prefer a quieter, more polite environment, try
comp.lang.c.moderated - but it's excessively quiet.
--
James Kuyper

cr88192

6/10/2011 6:00:00 AM

0

On 6/9/2011 3:47 PM, Joe Pfeiffer wrote:
> "Bo S."<bo@boo.invalid> writes:
>
>> pointer =&buffer[-2]; /* is it really -2, or 4294967294 */
>
> If it's a 32 bit system, does it matter? If you take an address and add
> 4294967294 to it, and then truncate to 32 bits, do you get something
> different from subtracting 2?
>
> When I taught 2's complement arithmetic in sophomore assembly language
> classes, the example I liked to use was an unscrupulous car seller
> "rolling back" a car's odometer. Take 20,000 miles off the car's
> mileage and it's worth more.
>
> So... in addition to being illegal, car odometers are now made so they
> won't wind backwards. No problem -- on a 100,000 mile odometer, just
> roll it 80,000 miles forward instead. No way to tell the difference.
>
> In effect, that's the same thing you're seeing here.
>
> (of course, more modern yet odometers also put up a flag when they wrap
> around so you can tell....)


so, you are saying that at that point it is not really that the car has
just become brand-new again?...

Shao Miller

6/10/2011 6:11:00 AM

0

On 6/9/2011 4:07 PM, Bo S. wrote:
> Is it possible to post a basic C question in this newsgroup without
> starting a flame war about "elegant" code or see answers like
> "silly, nonportable hack"? I've almost stopped reading this ng since
> there are usually more than 500 posts every day and most of it is
> opinons and comments on other's opinion.
>

I hope that doesn't happen.

> Anyway, I take a chance: I have stripped out a piece of code that
> we have in a large application that in some circumstances will do
> what this example program show. The interesting part is the
>
> pointer =&buffer[-2]; /* is it really -2, or 4294967294 */
> x = pointer->data; /* Reading something>2 unsigned's down */
>
> It (seems to) work, I'm just wondering if we're lucky or not.
> I would appreciate if anyone can explain why, or why not, without
> arguing about good or bad programming style (this code has already
> been redesigned but exists alive and well in older versions of
> our product).
>
> I guess buffer[-2] can be written *(buffer-2) and&buffer[-2]
> will simply be (buffer-2) and pointer->data will access memory
> at, say, (buffer-2)+2. But isn't n1-n2 = 4294967294 in the
> example below? Ok, 4294967294+2 is 0...or?
>
> Here's an example program:

Just out of curiosity: Are you trying to gain access to an
implementation's 'malloc'-internal details? I notice that you are
attempting to access outside of the explicitly allocated memory.

Here's some feed-back, for whatever it's worth:

#define _POSIX_SOURCE 1
#include <stdlib.h>
#include <stdio.h>

signed int main(signed int argc, char ** argv) {
/* It can be nice to put constant values here */
enum cv {
buff_elem_count = 10,
test_num = 54,
zero = 0
};
unsigned int n1 = 0;
unsigned int n2 = 2;
unsigned int n3;
unsigned int * membuff;
/*
* 'struct dummy' can have an unpredictable
* alignment requirement which might
* not be the same as 'unsigned int',
* even though it must be divisible by
* the alignment requirement of
* 'unsigned int' due to the first member
*/
struct dummy {
unsigned int d1;
unsigned int d2;
unsigned int d3;
} * sp;

/* Modified size computation */
membuff = malloc(buff_elem_count * sizeof *membuff);
/* Check for null pointer value */
if (!membuff) {
puts("Out of memory.");
return EXIT_FAILURE;
}

/* Modified to use testing value */
membuff[0] = test_num;

/*
* If the pointer arithmetic result below does
* not point to an 'unsigned int', the behaviour
* is undefined.
* If the alignment requirement of
* 'struct dummy' is not satisfied by the pointer
* arithmetic result below, the behaviour is
* undefined.
*/
sp = (struct dummy *) (membuff + (signed int)n1 - n2);
/*
* If 'sp' does not point to a contiguous range of
* accessible memory with size 'sizeof (struct dummy)'
* (if there's a hole), then the behaviour below is
* undefined.
* If there is padding between members of
* 'struct dummy', '&sp->d3' is not necessarily the
* same as '(unsigned int (*)[3])sp + 2'.
*/
n3 = sp->d3;

/* Newline added */
printf("Result = %u\n", n3);

return EXIT_SUCCESS;
}

Shao Miller

6/10/2011 6:14:00 AM

0

On 6/10/2011 1:10 AM, Shao Miller wrote:
> /*
> * If the pointer arithmetic result below does
> * not point to an 'unsigned int', the behaviour
> * is undefined.

Sorry, I meant (as in another comment), that if the result doesn't meet
the _alignment_ requirement for 'unsigned int', the behaviour is undefined.

Shao Miller

6/10/2011 6:20:00 AM

0

On 6/10/2011 1:13 AM, Shao Miller wrote:
> On 6/10/2011 1:10 AM, Shao Miller wrote:
>> /*
>> * If the pointer arithmetic result below does
>> * not point to an 'unsigned int', the behaviour
>> * is undefined.
>
> Sorry, I meant (as in another comment), that if the result doesn't meet
> the _alignment_ requirement for 'unsigned int', the behaviour is undefined.

Sorry; it's late. I also meant that it ought to point to within the
same array object, else the behaviour is undefined. This implies an
element type of 'unsigned int', so I was better off the first time. :)

Shao Miller

6/10/2011 8:33:00 AM

0

On 6/9/2011 4:07 PM, Bo S. wrote:
>...
> Here's an example program:
> ...

Here's another example program :) :

#define _POSIX_SOURCE 1
#include <stdlib.h>
#include <stdio.h>

enum node_cv {
node_n1,
node_n2,
node_n3,
node_cv_fields,
node_cv_zero = 0
};
typedef unsigned int a_node[node_cv_fields];

signed int main(signed int argc, char ** argv) {
enum cv {
test_count = 54,
zero = 0
};
a_node test_nodes[] = {
{10, 4, 0},
{ 6, 0, 1},
{ 0, 3, 2},
{ 0, 9, 3},
};
a_node * cur_node;
signed int tests, distance;

/* Set initial node */
cur_node = test_nodes;

/* Walk the nodes */
for (tests = 0; tests < test_count; ++tests) {
distance =
(signed int) node_n1[*cur_node] -
node_n2[*cur_node];
printf(
"Node @ %p (n3: %u): n1: [%u] n2: [%u] Distance: %d\n",
(void *) cur_node,
node_n3[*cur_node],
node_n1[*cur_node],
node_n2[*cur_node],
distance
);
cur_node = (a_node *) (*cur_node + distance);
}
return EXIT_SUCCESS;
}

pete

6/10/2011 10:28:00 AM

0

Joe Pfeiffer wrote:
>
> "Bo S." <bo@boo.invalid> writes:
>
> > pointer = &buffer[-2]; /* is it really -2, or 4294967294 */
>
> If it's a 32 bit system, does it matter?

It really is -2.

--
pete