struct off by 3 per member

[js5895]

hi,

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes. Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

[Keith Thompson]

js5895 <Jo*****@nycap.rr.comwrites:

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes. Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later to check to see how much a new
member would offset it by.
};

You're assuming that the size of a struct is the sum of the sizes of
its members. See questions 2.12 and 2.13 in the comp.lang.c FAQ,
<http://www.c-faq.com/>.

To determine the size of a structure, use the sizeof operator; adding
up the sizes of the members will often give you a wrong answer.

I'm fairly sure this is the answer to your question. What follows are
answers to several other questions that you didn't ask, but should
have.

const u_char *data;

I don't see a declaration of u_char. I can guess that it's a typedef
for unsigned char, but why not just call it by its real name, unsigned
char?

And you don't initialize data. I presume you do in your real code --
which is why it's a very good idea to *show us* your real code, rather
than some paraphrase of it. You lucked out this time in that there
was enough information to figure out what your problem is, but if you
don't know the problem then you don't know what parts of your actual
code are important and which aren't.

option = (struct option_entries *)data;

Where is option declared?

s = (unsigned char *)option;

And where is s declared?

//option->len = 1
option = (option_entries *)s + option->len + 2;

You haven't declared a type named "option_entries". You've declared a
type named "struct option_entries". If the above line compiles, then
either there's a typedef that you haven't bothered to show us, or
you're compiling your code with a C++ compiler. If it doesn't
compile, or if you haven't tried to compile it, then posting it here
is a waste of time (unless you're asking why it doesn't compile, but
then you'd need to show us the compiler's error message).

You're using a mixture of pointers to your structure and pointers to
unsigned char. Unless you have a specific reason to access your
structures as bytes, just use ``struct option_entries*'' throughout
and drop the casts.

Recommended reading: <http://www.catb.org/~esr/faqs/smart-questions.html>.

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

[Gordon Burditt]

>when I move to the next entrie by adding to the pointers address, I'm

>off by 6 bytes.

You need to move to the next entry by adding to a char *, not to a
struct option_entries *. If you move by 3 structs, you move by 9
bytes (assuming the version of the struct without the pad), which
is 6 extra, and corresponds to what you are seeing.

>Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

I don't see a declaration of s here but I hope it's unsigned char *.

>option = (option_entries *)(s + option->len + 2);

[Eric Sosman]

js5895 wrote:

hi,

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes. Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

In addition to Keith's and Gordon's remarks, your question might
be better suited to comp.lang.c++ than to this newsgroup. (Either
that, or you've omitted *far* too much of your actual code.)

--
Er*********@sun.com

[js5895]

On Sep 19, 3:55*pm, [e-mail] (Gordon Burditt) wrote:

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes.

You need to move to the next entry by adding to a char *, not to a
struct option_entries *. *If you move by 3 structs, you move by 9
bytes (assuming the version of the struct without the pad), which
is 6 extra, and corresponds to what you are seeing.

Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
* *unsigned char code;
* *unsigned char len;
* *unsigned char value;
* *unsigned char pad; *//added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

I don't see a declaration of s here but I hope it's unsigned char *.

option = (option_entries *)(s + option->len + 2);- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

sorry, I forgot the declaration of options. The program is large so I
tried to put the most significant info. It's actually dhcp program and
that part of the code is where look through dhcp opitions in the
packet. option is a struct option_entries pointer that is set to a
location in data(the packet data) where the options begin and I move
to the next option by adding option->len(which is 1) and 2 for a total
of 3 to the address which is 0x019f0176 so the outcome should be
option's address being 0x019f0179. here's the code with the missing
declaration.
struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later
};

const unsigned char *data;
struct option_entries *option;
unsigned char *s;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

[Gordon Burditt]

>when I move to the next entrie by adding to the pointers address, I'm

>off by 6 bytes.

You need to move to the next entry by adding to a char *, not to a
struct option_entries *. *If you move by 3 structs, you move by 9
bytes (assuming the version of the struct without the pad), which
is 6 extra, and corresponds to what you are seeing.

>Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

>struct option_entries {
* *unsigned char code;
* *unsigned char len;
* *unsigned char value;
* *unsigned char pad; *//added later to check to see how much a new
member would offset it by.
};

>const u_char *data;

>option = (struct option_entries *)data;
s = (unsigned char *)option;

>//option->len = 1
option = (option_entries *)s + option->len + 2;

I don't see a declaration of s here but I hope it's unsigned char *.

>option = (option_entries *)(s + option->len + 2);

- Hide quoted text -

I gave you a fix here, but you seem to have ignored it.

>- Show quoted text -- Hide quoted text -

- Show quoted text -

sorry, I forgot the declaration of options. The program is large so I
tried to put the most significant info. It's actually dhcp program and
that part of the code is where look through dhcp opitions in the
packet. option is a struct option_entries pointer that is set to a
location in data(the packet data) where the options begin and I move
to the next option by adding option->len(which is 1) and 2 for a total
of 3 to the address which is 0x019f0176 so the outcome should be
option's address being 0x019f0179. here's the code with the missing
declaration.
struct option_entries {
unsigned char code;
unsigned char len;
unsigned char value;
unsigned char pad; //added later
};

const unsigned char *data;
struct option_entries *option;
unsigned char *s;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

[js5895]

On Sep 19, 6:09*pm, [e-mail] (Gordon Burditt) wrote:

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes.

You need to move to the next entry by adding to a char *, not to a
struct option_entries *. *If you move by 3 structs, you move by 9
bytes (assuming the version of the struct without the pad), which
is 6 extra, and corresponds to what you are seeing.

Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
* *unsigned char code;
* *unsigned char len;
* *unsigned char value;
* *unsigned char pad; *//added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

I don't see a declaration of s here but I hope it's unsigned char *.

option = (option_entries *)(s + option->len + 2);
- Hide quoted text -

I gave you a fix here, but you seem to have ignored it.

- Show quoted text -- Hide quoted text -

- Show quoted text -

sorry, I forgot the declaration of options. The program is large so I
tried to put the most significant info. It's actually dhcp program and
that part of the code is where look through dhcp opitions in the
packet. option is a struct option_entries pointer that is set to a
location in data(the packet data) where the options begin and I move
to the next option by adding option->len(which is 1) and 2 for a total
of 3 to the address which is 0x019f0176 so the outcome should be
option's address being 0x019f0179. here's the code with the missing
declaration.
struct option_entries {
* *unsigned char code;
* *unsigned char len;
* *unsigned char value;
* *unsigned char pad; *//added later
};

const unsigned char *data;
struct option_entries *option;
unsigned char *s;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

My mistake, I caught up, thank you, it works.

[CBFalconer]

Gordon Burditt wrote:

>

>>>when I move to the next entrie by adding to the pointers
address, I'm off by 6 bytes.

.... snip ...

>
I gave you a fix here, but you seem to have ignored it.

.... snip ...

>>
//option->len = 1
option = (option_entries *)s + option->len + 2;

Not only have you quoted about 100 lines for this one line reply,
but you have totally deleted all attributions for quoted material.
Please don't do that.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Gordon Burditt wrote:

[snip]

Not only have you quoted about 100 lines for this one line reply,
but you have totally deleted all attributions for quoted material.
Please don't do that.

Gordon always deletes all attributions for quoted material. He does
it deliberately. Asking him to stop it doesn't work.

(As always, permission to quote this article without attribution is
denied.)

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

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>CBFalconer <cb********@yahoo.comwrites:

>Gordon Burditt wrote:

[snip]

>Not only have you quoted about 100 lines for this one line reply,
but you have totally deleted all attributions for quoted material.
Please don't do that.

(I know you won't respond to this, since you never do. Don't worry, I
take that as a complement - an admission that you can't handle it)

>Gordon always deletes all attributions for quoted material. He does
it deliberately.

Are you a mind-reader? I've seen you post this a few times now - about
how bad old Gordon does it deliberately. How can you know intent?

[Keith Thompson]

ga*****@shell.xmission.com (Kenny McCormack) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

[...]

>>Gordon always deletes all attributions for quoted material. He does
it deliberately.

Are you a mind-reader? I've seen you post this a few times now - about
how bad old Gordon does it deliberately. How can you know intent?

That's actually a legitimate question, so I'll answer it. Gordon has
said so himself, in a lengthy discussion in this newsgroup some time
ago. I don't have a reference; do your own research.

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

[Richard Heathfield]

Keith Thompson said:

ga*****@shell.xmission.com (Kenny McCormack) writes:

>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

[...]

>>>Gordon always deletes all attributions for quoted material. He does
it deliberately.

Are you a mind-reader? I've seen you post this a few times now - about
how bad old Gordon does it deliberately. How can you know intent?

That's actually a legitimate question, so I'll answer it. Gordon has
said so himself, in a lengthy discussion in this newsgroup some time
ago. I don't have a reference; do your own research.

I did my own research. Here's a cite: "Some of the complaints threaten
lawsuits (most of which I don't take seriously). It is obvious just from
reading comp.lang.c or some other newsgroups that mis-attributing some of
the stupid stuff said to a professional programmer who happens to be
looking for a job from an employer who reads USENET could be the basis for
a lawsuit with *real* damages. So it's better to delete the attributions.
Non-attribution has no such potential for real damages." -- Gordon Burditt

I'm no lawyer, but my layman's view is that his argument wouldn't last two
minutes in a civil prosecution brought against him for failing to
attribute quoted text. No, that's not a threat - I wouldn't dream of
bringing such a prosecution! I prefer it when people find Usenet solutions
to Usenet problems.

The issue here is that Gordon Burditt believes that the possible harm from
providing attributions outweighs the possible harm from not providing
them, whereas most of us clearly believe differently. Well, I'm all for
freedom of expression. Everyone should be free to make a fool of
themselves.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Kenny McCormack wrote, On 20/09/08 15:00:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

<snip>

>Gordon always deletes all attributions for quoted material. He does
it deliberately.

Are you a mind-reader? I've seen you post this a few times now - about
how bad old Gordon does it deliberately. How can you know intent?

No mind reading is involved, just ordinary reading and memory. Gordon
has stated several times in the past that he does it deliberately.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Kenny McCormack]

In article <2e************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Kenny McCormack wrote, On 20/09/08 15:00:

>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

<snip>

>>Gordon always deletes all attributions for quoted material. He does
it deliberately.

Are you a mind-reader? I've seen you post this a few times now - about
how bad old Gordon does it deliberately. How can you know intent?

No mind reading is involved, just ordinary reading and memory. Gordon
has stated several times in the past that he does it deliberately.

Yes, and I find his reasons (as elucidated by Heathfield) quite sensible
and compelling. As usual, Heathfield and Thompson are on the wrong side
of the argument.

[Nick Keighley]

On Sep 19, 9:03*pm, Eric Sosman <[e-mail]:

js5895 wrote:

hi,

when I move to the next entrie by adding to the pointers address, I'm
off by 6 bytes. Then I changed my code so my struct would have an
extra member, pad, and then it was off by 9 bytes. option and s are at
memory address 0x019f0176 when I add to it should be at 0x019f0179
instead I get 0x019f017f without pad and 0x019f0182 with pad. I can't
figure out why its always off.

struct option_entries {
* *unsigned char code;
* *unsigned char len;
* *unsigned char value;
* *unsigned char pad; *//added later to check to see how much a new
member would offset it by.
};

const u_char *data;

option = (struct option_entries *)data;
s = (unsigned char *)option;

//option->len = 1
option = (option_entries *)s + option->len + 2;

* * *In addition to Keith's and Gordon's remarks, your question might
be better suited to comp.lang.c++ than to this newsgroup. *(Either
that, or you've omitted *far* too much of your actual code.)

what makes you think this is C++?
--
Nick Keighley

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 21 Sep 2008 04:44:01 -0700, Nick Keighley wrote:

On Sep 19, 9:03Â*pm, Eric Sosman <[e-mail]:

>js5895 wrote:

struct option_entries {
[snip]
option = (option_entries *)s + option->len + 2;

Â* Â* Â*In addition to Keith's and Gordon's remarks, your question might
be better suited to comp.lang.c++ than to this newsgroup. Â*(Either
that, or you've omitted *far* too much of your actual code.)

what makes you think this is C++?

The reference to a structure type without a typedef or the struct keyword
is not possible in C, but is in C++. There's also a reference to an u_char
type without a typedef, though, so it could just as well be that all
typedefs were omitted.