sizeof struct返回意外结果 [英] sizeof struct returning unexpected results

查看:61
本文介绍了sizeof struct返回意外结果的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个用来测试协议的结构。我的想法是

只是根据协议的定义按照发送和接收的顺序声明结构的元素。但是,将这个结构写入文件会产生意想不到的结果。


这是我写的测试结构:


struct Tester {

unsigned short first;

unsigned int second;

};


检查声明为此类型的变量的sizeof,得到64

位,当真正短的大小是16位,并且大小为

int是32位。声明结构有两条短路产生

预期结果,并声明它有一条短线也会产生

预期结果。


我明白这里发生了什么。尺寸正在调整

或对齐 (我不想滥用那个术语,所以如果我使用

错误的话,请纠正我最大组成元素的大小)。但是,我希望b $ b能够防止这种情况,因为它确实会导致与此协议相关的最终结果。


我最初在D中发现了这个,我有一个结构,其中
包含short,int和long。我能够用C,

重现它,所以我认为这是一个更基本的问题,通用的回复

(希望如此)。

我可以做一个结构,如上所述,返回一个

大小为6,或者被操纵以便将自己呈现为一个48的字符串

位?


感谢大家,感谢您的时间。

I have a struct that I wrote to test a protocol. The idea I had was
to just declare the elements of the struct in the order in which they
are sent and received as defined by the protocol. However, writing
this struct to a file produces unexpected results.

Here is a test struct I wrote:

struct Tester {
unsigned short first;
unsigned int second;
};

Checking the sizeof variables declared to be of this type, I get 64
bits, when really the size of a short is 16 bits, and the size of an
int is 32 bits. Declaring the struct to have two shorts produces
expected results, and declaring it to have one short also produces
expected results.

I do understand what is going on here. The size is being adjusted
or "aligned" (I don''t want to misuse that term so correct me if I used
it wrong) to the size of the largest constituent element. However, I
would like to prevent this as it does have the end result of munging
communication as it relates to this protocol.

I originally discovered this in D, where I had a struct which
contained shorts, ints, and a long. I was able to reproduce it in C,
so I figure it''s a more basic issue with a generic response
(hopefully).

What can I do to have a struct, declared as above, either return a
size of 6, or be manipulated so as to present itself as a string of 48
bits?

Thanks everyone, for your time.

推荐答案

2004年8月20日09:40:53 -0700, se******@bluebeard.org (Sean)写道:
On 20 Aug 2004 09:40:53 -0700, se******@bluebeard.org (Sean) wrote:
我有一个用于测试协议的结构。我的想法是按照协议的定义按照发送和接收它们的顺序声明结构的元素。但是,将此结构写入文件会产生意外结果。

这是我编写的测试结构:

struct Tester {
unsigned short first ;
unsigned int second;
};

检查声明为此类型的变量的sizeof,我得到64位,当真的是一个短的大小是16位,
int的大小是32位。声明结构有两个短路会产生预期结果,并声明它有一个短路也会产生预期结果。

我明白这里发生了什么。尺寸正在调整
或对齐。 (我不想滥用那个术语,所以如果我使用了错误的话,请纠正我)最大组成元素的大小。但是,我想要防止这种情况,因为它确实有与此协议相关的重复通信的最终结果。

我最初在D中发现了这个,我在那里有一个结构,其中包含短裤,整数和一个长的。我能够在C中重现它,
所以我觉得它是一个更基本的问题,通用的响应
(希望如此)。

我该怎么做才能拥有结构,如上所述,要么返回大小为6,要么被操纵以便将自己呈现为一串48位?

谢谢大家,为你的时间。
I have a struct that I wrote to test a protocol. The idea I had was
to just declare the elements of the struct in the order in which they
are sent and received as defined by the protocol. However, writing
this struct to a file produces unexpected results.

Here is a test struct I wrote:

struct Tester {
unsigned short first;
unsigned int second;
};

Checking the sizeof variables declared to be of this type, I get 64
bits, when really the size of a short is 16 bits, and the size of an
int is 32 bits. Declaring the struct to have two shorts produces
expected results, and declaring it to have one short also produces
expected results.

I do understand what is going on here. The size is being adjusted
or "aligned" (I don''t want to misuse that term so correct me if I used
it wrong) to the size of the largest constituent element. However, I
would like to prevent this as it does have the end result of munging
communication as it relates to this protocol.

I originally discovered this in D, where I had a struct which
contained shorts, ints, and a long. I was able to reproduce it in C,
so I figure it''s a more basic issue with a generic response
(hopefully).

What can I do to have a struct, declared as above, either return a
size of 6, or be manipulated so as to present itself as a string of 48
bits?

Thanks everyone, for your time.




根据您的编译器,您应该研究一种方法,以便允许

打包结构。


使用Gcc,您可以使用__attribute __((packed))。


例如。


struct Tester {

unsigned short first;

unsigned int second;

} __attribute __((packed));


l8r



Depending upon your compiler you should investigate a method to allow
the structure to be packed.

With Gcc you may use __attribute__ ((packed)) for example.

Eg.

struct Tester {
unsigned short first;
unsigned int second;
} __attribute__ ((packed));

l8r


Sean写道:
这是我写的测试结构:

struct Tester {
unsigned先短;
unsigned int second;
};

检查声明为b的变量sizeof这种类型的e,我得到64位,当真正短的大小是16位,并且
int的大小是32位。声明结构有两个短路产生预期结果,并声明它有一个短路也会产生预期结果。
Here is a test struct I wrote:

struct Tester {
unsigned short first;
unsigned int second;
};

Checking the sizeof variables declared to be of this type, I get 64
bits, when really the size of a short is 16 bits, and the size of an
int is 32 bits. Declaring the struct to have two shorts produces
expected results, and declaring it to have one short also produces
expected results.




你的编译器是填充结构,使其'是8字节的倍数。

编译器可以自由地执行此操作,通常可以进行优化

[和加载/存储更快]。


如果你想要精确的尺寸,你将不得不使用编译器特定的属性'''

这些是关闭的主题在这里。


Tom



Your compiler is padding the structure so that''s its a multiple of 8 bytes.
The compiler is free to do this and usually it''s to make optimizations
possible [and loads/stores quicker].

If you want exact sizes you''ll have to use compiler specific ``attributes''''
which are off topic here.

Tom


Sean写道:
我有一个我写的结构测试协议。我的想法是按照协议的定义按照发送和接收它们的顺序声明结构的元素。但是,将此结构写入文件会产生意外结果。
I have a struct that I wrote to test a protocol. The idea I had was
to just declare the elements of the struct in the order in which they
are sent and received as defined by the protocol. However, writing
this struct to a file produces unexpected results.




这是comp.lang.c中的问题2.12经常

问题(FAQ)列表

http://www.eskimo.com/~scs/C-faq/top.html


....你不会去喜欢这个答案。


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



This is Question 2.12 in the comp.lang.c Frequently
Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

.... and you''re not going to like the answer.

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


这篇关于sizeof struct返回意外结果的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆