- 主题:fileheader转化失败
不是这个问题,
加与不加都是一样的,编译的时候都一样,
程序只把不同的结构转化而已
【 在 F1yingFish (F.Fish|人生如梦·我心依旧) 的大作中提到: 】
: 应该要加上
: bhnew.flags = bh.flags[0];
: bhnew.title = 0;
: ...................
--
FROM 219.224.148.*
Linux下的int和unsigned int都是32bit的?比较奇怪的说
【 在 atppp@bbs.stanford.edu-SPAM.no (Big Mouse) 的大作中提到: 】
: 嘿嘿,解决问题之后跟我们说说吧:)
--
FROM 219.224.195.142
i686上应该都是32bit吧。其实struct有点BT的,像下面这个结构:
struct {
char a;
int b;
char c;
}
如果编译设置了诡异的align优化你sizeof一把这个struct没准出来是12,赫赫。
普通操作都没问题但是memcpy类似结构就会出问题。所以那个转换程序虽然用memcpy
没啥问题但是我觉得这是放弃portability的一种做法。
【 在 FlyingFish@coa.cn-bbs.org (人生如梦|抓紧剩下的时间好好工作) 的大作中提到: 】
: Linux下的int和unsigned int都是32bit的?比较奇怪的说
: 【 在 atppp@bbs.stanford.edu-SPAM.no (Big Mouse) 的大作中提到: 】
: : 嘿嘿,解决问题之后跟我们说说吧:)
--
奇怪,你的文件大小和我的居然是一样的
这么巧。。。。。。
【 在 FlyingFish@coa.cn-bbs.org (人生如梦|抓紧剩下的时间好好工作) 的大作中提到: 】
: 我看了一下这边新老版本的.PASSWDS
: 2003.5.10snap包的一个用户占188个字节
: 1.2的占220个字节
: ...................
--
FROM 219.224.148.*
文件后面一般基本上全是0了
btw:转信进smth好慢的说
【 在 BlueSand (蓝色的沙子*等待着美好) 的大作中提到: 】
: 奇怪,你的文件大小和我的居然是一样的
: 这么巧。。。。。。
※ 来源:·BBS 水木清华站 smth.org·[FROM: 219.224.195.*]
FROM 219.224.195.*
[bbs@localhost testmisc]$ cat c.c
#include "stdio.h"
struct abc {
char a;
int b;
char c;
};
int main(int a, char** b) {
printf("%d\n", sizeof(struct abc));
return 0;
}
[bbs@localhost testmisc]$ cc c.c -o c
[bbs@localhost testmisc]$ ./c
12
[bbs@localhost testmisc]$ cc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
[bbs@localhost testmisc]$
【 在 atppp (Big Mouse) 的大作中提到: 】
: i686上应该都是32bit吧。其实struct有点BT的,像下面这个结构:
: struct {
: char a;
: int b;
: char c;
: }
: 如果编译设置了诡异的align优化你sizeof一把这个struct没准出来是12,赫赫。
: 普通操作都没问题但是memcpy类似结构就会出问题。所以那个转换程序虽然用memcpy
: 没啥问题但是我觉得这是放弃portability的一种做法。
: 【 在 FlyingFish@coa.cn-bbs.org (人生如梦|抓紧剩下的时间好好工作) 的大作中提到: 】
: ...................
--
想了一下,发现是这样的
新的passwds每220个字节记录一个用户信息,其中前192个字节为有效字节,把userdefin
e从4字节扩大到8字节,其余相同,所以在192个字节后面加上28个0就可以了。
【 在 atppp@bbs.stanford.edu-SPAM.no (Big Mouse) 的大作中提到: 】
: i686上应该都是32bit吧。其实struct有点BT的,像下面这个结构:
: struct {
: char a;
: int b;
: char c;
: }
: 如果编译设置了诡异的align优化你sizeof一把这个struct没准出来是12,赫赫。
: 普通操作都没问题但是memcpy类似结构就会出问题。所以那个转换程序虽然用memcpy
: 没啥问题但是我觉得这是放弃portability的一种做法。
--
FROM 219.224.195.142
没法正确.passwds转化,我觉得应该是memcpy出的问题
只分配了192个字节给每个用户
【 在 atppp@bbs.stanford.edu-SPAM.no (Big Mouse) 的大作中提到: 】
: i686上应该都是32bit吧。其实struct有点BT的,像下面这个结构:
: struct {
: char a;
: int b;
: char c;
: }
: 如果编译设置了诡异的align优化你sizeof一把这个struct没准出来是12,赫赫。
: 普通操作都没问题但是memcpy类似结构就会出问题。所以那个转换程序虽然用memcpy
: 没啥问题但是我觉得这是放弃portability的一种做法。
--
修改:FlyingFish FROM 219.224.195.142
FROM 219.224.195.142
我在转化程序里userec2加上
int freespace[7];
试试
看看能不能多分配28个字节出来
【 在 FlyingFish (人生如梦|抓紧剩下的时间好好工作) 的大作中提到: 】
: 没法正确.passwds转化,我觉得应该是memcpy出的问题
: 只分配了192个字节给每个用户
--
FROM 219.224.195.142
成功了的话在这里bg一下吧:)
现在转信进smth很慢,我们这样跨站侃大山还是蛮好玩的 ^-^
【 在 FlyingFish@coa.cn-bbs.org (人生如梦|抓紧剩下的时间好好工作) 的大作中提到: 】
: 想了一下,发现是这样的
: 新的passwds每220个字节记录一个用户信息,其中前192个字节为有效字节,把userdefin
: e从4字节扩大到8字节,其余相同,所以在192个字节后面加上28个0就可以了。
: 【 在 atppp@bbs.stanford.edu-SPAM.no (Big Mouse) 的大作中提到: 】
: : i686上应该都是32bit吧。其实struct有点BT的,像下面这个结构:
: : struct {
: : char a;
: : int b;
: : char c;
: : }
: ...................
--