[ CnUnix ] in KIDS 글 쓴 이(By): guest (게스트) <211.37.187.119> 날 짜 (Date): 2002년 3월 15일 금요일 오후 05시 13분 37초 제 목(Title): [Q] sizeof 문제... #include struct ll { uint64_t a; uint32_t b; }; 이 sizeof(struct ll)해보면 linux에서는 12가 나오는데 솔라리스에서는 16이 나오는데 왜 그런건가요? 그리고 uint64_t의 데이타를 network을 통해 받을 때 세그폴트나던데 uint64_t의 데이타를 network을 통해 전송할 때 주의할 점이 있나요? [ CnUnix ] in KIDS 글 쓴 이(By): gaia (아무개) 날 짜 (Date): 2002년 3월 15일 금요일 오후 05시 23분 19초 제 목(Title): Re: [Q] sizeof 문제... 전자의 경우는.. linux는 32bit machine 이고.. solaris는 64bit machine 이라서 그렇습니다. struct { 64bit, 32bit } 했을 때 32bit machine은 32bit 3개 로 잡히지만 64bit 로 했는때는 64bit 2개로 잡힙니다. 단위가 64bit인데 1.5개로 잡을 수는 없겠죠? 두번째 거는 원하시는 답은 아니시겠지만.. 그리고 Network Programming 할때느 64bit 잘 안쓰는데.. 꼭 쓰셔야 되면 union { char a[8]; uint64 b; } 로해서 char로 해서 받아서 64bit 쓰세요.. [ CnUnix ] in KIDS 글 쓴 이(By): unixboy (세탁소주인) 날 짜 (Date): 2002년 3월 15일 금요일 오후 05시 49분 01초 제 목(Title): Re: [Q] sizeof 문제... Solaris compile 시에 word-align 옵션이 되어 있는 것은 아닌가요? 64bit Ultra 계열 CPU가 박힌 W/S 에서요... 아니면...모... 저도 모르죠.. 모.. 헤헤. 글 쓴 이(By): swhan (kkRunner) 날 짜 (Date): 2002년 3월 15일 금요일 오후 06시 49분 24초 제 목(Title): Re: [Q] sizeof 문제... uint64_t의 data를 받을때(!) seg fault가 난다면 아마 버퍼 관리의 잘못일 것입니다. 64bit 정수형 데이터를 네트웍으로 보내는 것은 그리 흔한 일이 아닙니다. 정수던 실수던 큰 수를 보내는 가장 확실한 것은 string으로(sprintf등으로 찍어서)보내는 것이고, 이것이 비효율적이라면 network byte order로 변환해주는 매크로나 함수를 직접 작성해서 써야 할겁니다. 전 htonl을 이용해서 변환해주는 메크로를 만들어 썼었는데 그냥 함수로 만드는게 낫지.. 싶기도 합니다. 몇몇 다른 인코딩 방법이 있긴 한데 배보다 배꼽이 더 큰 경우가 생기므로 쓰지 않는게 낫겠구요. 뭐 다른 좋은 방법이 있을까요? [ CnUnix ] in KIDS 글 쓴 이(By): terzeron (microkid) 날 짜 (Date): 2002년 3월 16일 토요일 오전 01시 17분 56초 제 목(Title): Re: [Q] sizeof 문제... 1. 뭐, 억지로 한다면야 다음의 예제를 활용하시면 좋을 것 같군요. 솔라리스, FreeBSD(i386)에서 모두 작동합니다. 물론 FB는 리눅스처럼 little endian입니다. struct에 __attribute__((packed))를 준다거나 컴파일 옵션에 -fpack-struct를 주거나 #pragma pack(n)을 이용하면 구조체를 pack할 수 있습니다. 그러면 구조체의 크기 문제는 해결이 됩니다. (물론 byteorder 문제 여전히 남아 있습니다.) #include #include int main() { struct __attribute__((packed)) ll { uint32_t b; uint64_t a; } lll; printf("uint64_t=%d\n", sizeof (uint64_t)); printf("uint32_t=%d\n", sizeof (uint32_t)); printf("lll=%d\n", sizeof (lll)); return 0; } 2. 그리고 htonl이 어셈블리어로 작성되어 있으니 64 bit용 htonll을 만든다 치면 32 bit 두 개로 쪼개고 그걸 htonl한 후에 두 개 integer의 순서를 바꿔서 붙이면 되겠습니다. long long htonll(long long source) { long pass; long nl; long long target; memcpy(&pass, ((long *) &source) + 1, sizeof (long)); nl = htonl(pass); memcpy(&target, &nl, sizeof (long)); memcpy(&pass, &source, sizeof (long)); nl = htonl(pass); memcpy(((long *) &target) + 1, &nl, sizeof (long)); return target; } 성능 보장 못 합니다. 대략의 아이디어를 구현한 정도이니까요. ^^ 그리고 swhan님 말씀대로 struct안에 있는 long long을 네트웍으로 보낸다는 것 자체가 아무래도 이상합니다. byteorder 문제가 찜찜하거든요. 전에도 이런 이야기가 나왔었지만 쌈빡한 해결책도 별로 없는 것 같구요. [ CnUnix ] in KIDS 글 쓴 이(By): Tony (관객2) 날 짜 (Date): 2002년 3월 16일 토요일 오전 10시 42분 04초 제 목(Title): Re: [Q] sizeof 문제... 그냥 잡담입니다~~~~ #define ___swab64(x) \ ({ \ __u64 __x = (x); \ ((__u64)( \ ((__u64)(((__u64)(__x) & (__u64)0x00000000000000ffULL) << 56) | \ ((__u64)(((__u64)(__x) & (__u64)0x000000000000ff00ULL) << 40) | \ ((__u64)(((__u64)(__x) & (__u64)0x0000000000ff0000ULL) << 24) | \ ((__u64)(((__u64)(__x) & (__u64)0x00000000ff000000ULL) << 8) | \ (__u64)(((__u64)(__x) & (__u64)0x000000ff00000000ULL) >> 8) | \ __u64)(((__u64)(__x) & (__u64)0x0000ff0000000000ULL) >> 24) | \ __u64)(((__u64)(__x) & (__u64)0x00ff000000000000ULL) >> 40) | \ __u64)(((__u64)(__x) & (__u64)0xff00000000000000ULL) >> 56) )); \ }) 요게 리눅스에 들어있는 64bit 바이트 오더 바꾸는거구요... __u64는 long long이겠죠? 쉬프트와 비트 오퍼레이션으로 돌리면 아마 성능은 가장 좋을듯 싶네요... Structure를 여러 플렛폼에서 호환성을 가지도록 전달하는 방법은 RPC를 이용하는 방법밖에 없을꺼구요...(앞에서 잠시 언급됐죠? XDR 이라는 특별한 엔코딩 방법을 사용합니다. 느리죠.... 확실히 느리죠... 대신 호환성!) 성능과 플렛폼이 정해져있다면 그냥 따로 프로토콜 정의하시고 순서대로 보내시고 순서대로 받으세요. 스트럭쳐 만들어 보내지 마시구요... byteorder만 조금 신경쓰시고.. == 여기까지가 잡담입니다 == 64bit type을 네턱으로 보내고 받으면 에러난다고 하셨는데요. 에러메시지를 보여주시면 좋겠네요. RISC타입의 CPU들의 경우 Unaligned Access이딴식의 에러 자주 접하는데요. 상당히 골치아프죠?(특히 암적인 리스크라 불리는 ARM) 받는 데이타가 말 그대로 Align되어있지 않아서 생기는 문제구요.. [ 1 | 2 | 3 | 4 ] 32bit기계에서 이런식으로 되어있어야 할 데이타가 [ ~~~~~~~~~ | 1 ] [ 2 | 3 | 4 | ~~] 이런식으로 되어있으면(포인터 찍어보면 32bit 머신이라면 4의 배수의 주소로 나와야겠죠?) Memory Bus가 32bit단위로 Access하기때문에 생기는 문제입니다. CISC들은 Memory를 두번 Access해서 읽어와서 느리지만 처리는 가능하도록 하는데 RISC들은 구현상의 오버헤드때문인지 CPU에서 Exception 튀어나오도록 되어있습니다. 이걸로 버그가 생기면 ARM에선 Bus Error인가 하는것밖에 안튀어나오기 때문에 고생하던 기억이 나는군요. [ CnUnix ] in KIDS 글 쓴 이(By): ahsarang (.아.사.랑.) 날 짜 (Date): 2002년 3월 16일 토요일 오후 01시 53분 38초 제 목(Title): Re: [Q] sizeof 문제... 보통 걍 struct로 정의해서 주고 받으려고들 하는데 전 string으로 변환해서 정의합니다. 이케 해면 좋은점이 telnet으로 간단히 test가 가능하다는 거지요. 이케하면 잘주네 잘받네 이런 싸움(-.-) 필요 없습니다. 특히 OS가 다르고 언어가 다른 경우 더더욱~~~ 요즘 XML사용하자는 분위기던데 건 편의에 비해 over-head가 큰거같구요. [ CnUnix ] in KIDS 글 쓴 이(By): swhan (kkRunner) 날 짜 (Date): 2002년 3월 16일 토요일 오후 03시 13분 34초 제 목(Title): Re: [Q] sizeof 문제... 성능이 크리티컬하지만 않으면 순수하게 스트링으로 보내는게 깔끔해질 수 있겠네요 단.. 쓸만한 파서를 하나 만들어두고 써야 하겠네요. 메세지 형식 조금 바뀐다고 다 뜯어고치지 안하도 되는 포터블한 넘으로요. 메세지 포멧스트링 넣어주면 자동으로 처리를 해주는 넘이면 더 좋겠구요. 그렇게 되면 scanf랑 비슷해지려나? o.O 이런 용도로 쓸만한 라이브러리가 공개된게 뭔가 잇을 것 같은데.. 아시는분? (중간이 캐릭터 스트링이든 뭐든 말입니다.) [ CnUnix ] in KIDS 글 쓴 이(By): dalgong (달공아저씨) 날 짜 (Date): 2002년 3월 18일 월요일 오전 11시 02분 35초 제 목(Title): Re: [Q] sizeof 문제... align문제에서 그 structure가 array에 들어갈때를 고려해 끝에 padding이 생기는 경우가 있어서 조심해야 합니다. 그리고, endian문제나 align문제는 os의 문제가 아니라 cpu architecture의 문젭니다. glib같은데 보시면 64 bit swap하는거 정의되어 있습니다. 앞에 어떤 분이 설명하신 것처럼 bitwise &, |, >>, << 잘 조합해서 만들었네요. header의 macro부분 가져다가 쓰시면 되겠네요. 근데 x86에서는 endian을 바꾸는 assembly instruction이 있다고 하더군요. C를 쓰다보니 잘 쓰지 않게 되었다는... xdr이나 asn.1 같은거 쓰시면 별 무리가 없지 않을까요? [ CnUnix ] in KIDS 글 쓴 이(By): swhan (kkRunner) 날 짜 (Date): 2002년 3월 18일 월요일 오전 11시 33분 34초 제 목(Title): Re: [Q] sizeof 문제... pc에 깔린 linux의 htonl이랑 htons등을 봤었는데 어셈블리코드 1~3줄이더군요 이거랑 조합해서 만들어본 64bit endian변환 매크로는 한 어셈블리코드 50줄정도 (call포함, call이하단 제외) 순수 매크로로 만든 것은 한 150정도.. x86에서 얘기입니다. ASN.1은 오버헤드가 좀 크지 않나요? 범용으로 쓰기엔 사용하는게 편한거도 아니고... xdr은.. 음.. 좀 쉬운가?