함수 포인터에 대한 질문......

지나가다가 남깁니다...

int numcmp(char *, char *);
int strcmp(const char *, const char *);
 
qsort(..., (int (*)(void*,void*))(numeric ? numcmp : strcmp));

이 코드는 잘못된 코드입니다.

모든 함수 포인터는 동일한 표현과 동일한 정렬 제한을 갖는다고 보장되기
때문에 정보 손실 없이 서로 다른 함수 포인터형으로 변환될 수 있습니다.
하지만, 그렇게 변환된 함수 포인터를 통해 호환되지 않는 type 으로
원래의 함수를 호출할 수 있는 것은 아닙니다. 즉,

int func(float f);

라는 함수를

void (*fp)(double);

로 선언된 함수 포인터에 강제 대입한 후 fp 를 통해 함수 func() 를
호출하는 것은 허용되지 않는다는 뜻입니다. 유사하게 qsort() 가 요구하는
callback 함수의 type 과 numcmp(), strcmp() 의 type 이 호환되지 않기
때문에 이를 강제로 형변환해 qsort() 에 callback 함수로 제공하는 것은
잘못된 프로그램입니다.

물론, char * 와 void * 가 같은 표현, 같은 정렬제한을 갖는다는 사실이
보장되기 때문에 적지 않은 환경에서 운 좋게도 원하는 결과를 얻을 수
있겠지만, 표준 차원의 이식성은 결코 보장될 수 없습니다. 따라서
strcmp() 를 qsort() 의 callback 함수로 제공하고자 한다면, 매개변수
type 을 조정해 줄 수 있는 wrapping 함수를 도입해야 합니다.

"표준 C(ANSI C)"를 표방하는 K&R2 이지만, 사실상 최종 표준 발표 이전에
쓰여진 책이라 정확하게 기술되지 못한 부분이 있는것이 아닐까 싶습니다.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org

논의가 서로 다른 branch 로 흩어지고 있어 하나로 모아 답변합니다. 이
점 이해 부탁드립니다.

내용이 길어 스크롤의 압박이 상당합니다. 일부러 세부 주제별로 나눠
답변을 드렸습니다.

* 곁가지 문제

> 전웅님 답변에는 항상 곁가지가 있고, 그것은 이미 당연한 것으로 전제된 것이 많아서
> 때로는 논점이 흐려지거나, 어떤 면에서는 좀 답답한 부분도 있네요.
>

제가 곁가지를 그리 크게 치지 않았음에도 이미 논의는 다양한 논제를 담고
있군요. :-) 제가 님의 관심사가 아닌 부분에 대해 답하는 것은 주제를
흐리게 하고 답답한 일이며, 어느 순간부터 님의 관심사가 되어 질문-답변
이 오고 가면 그때부터는 집중해야 하는 주제가 되는 것인지요?

제가 누군가로부터 지원을 받으며 글을 쓰고 있는 것이 아닌 이상 제가
이곳에 글을 쓸 때에는 (게시판 원칙에 반하지 않는 이상) 제 가치관을
따라 쓸 수 있는 자유가 있습니다.

님께서는 제 답변 스타일이 곁가지가 많아 답답하다고 생각하실지 모르지만
저는 제 글에 가능한 기술적 오류를 덜 담으려 노력하는 것이고 더불어
혹시나 있을지 모르는 오해의 여지를 처음부터 막으려 하는 의도입니다.

제가 지나치게 뉴스그룹에 익숙해진 것이 원인일지 모르겠지만, 뉴스그룹
에서는 OP 의 관심사가 아닌 사항에 대해 논의가 이루어지는 일이 비일비재
하며 실제로 그로 인해 알지 못하던 부분에 대해 알게 되거나 의외의 문제
들을 발견하고 해결하는 일이 많습니다.

그와 같은 방식이 님에게는 답답할지 모르겠지만, 최소한 저에게는 공부를
하는데 있어 상당히 유용하다고 생각하고 있으며, 서로 다른 배경 지식을
갖는 분들이 이 논의를 따라오며 이해할 때 조금이라도 도움이 된다고
생각합니다.

"논의"가 아닌 사실상 "답변"을 하고 있는 상황에서 제 글 쓰는 스타일까지
(어떤한 방식으로든) 지적을 받아야 하는 일은 상당히 불쾌할 수 밖에
없습니다. 제가 최소한 외계어를 쓴 것은 아니지 않습니까? :-)

* 호환의 개념

> 이미 전웅님께서 모든 구조체의 포인터는 정렬 제한이 같다고 언급하셨고,
> 저는 이것을 '호환되는 타입' 이라는 의미로 받아들였습니다.
> 표준상에서는 분명히, 'same' 이라 하지 않고 'compatible' 이라 되어있습니다.
>
> 이 부분을 명확히 하실 필요가 있습니다. 받아들이기는 어렵습니다만,
> 전웅님 말씀에 의하면, 구조체 포인터들은 정렬 제한이 같으나 호환되는 타입은 아닌 것입니까?
>

같은 정렬제한, 같은 표현과 호환의 관계에 대해 물으셨는데, 님의 글에
대한 직접적 답변은 아니지만, 이미 다른 분의 질문에 답하면서 호환과
정렬제한/표현에 대한 관계를 분명히 밝힌 바 있습니다.

같은 정렬제한/표현은 호환형의 필수 조건이지만, 충분 조건이 아닙니다.
따라서 어떤 두 type 이 같은 정렬제한, 표현을 가지고 있다고 해도 둘은
호환형이 아닐 수 있습니다. 즉, 호환형은 type algebra 의 관점에서
보아야 합니다. 이미 char *, signed char *, unsigned char * 이야기를
통해서 예까지 든 것으로 기억하고 있습니다. 따라서 그 부분에 대해서
만큼은 더 이상 오해가 없었으면 합니다.

* 구조체형의 호환 문제

> 하지만, C89 표준상으로는 다음에 토론에 언급되는 것처럼,
>
> http://www.velocityreviews.com/forums/t318198-declaration-of-structs-ins...
>
> Two types have compatible type if their types are the same.
> Additional rules for determining whether two types are compatible are
> described in $3.5.2 for type specifiers, in $3.5.3 for type
> qualifiers, and in $3.5.4 for declarators. Moreover, two
> structure, union, or enumeration types declared in separate
> translation units are compatible if they have the same number of
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> members, the same member names, and compatible member types; for two
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
> structures, the members shall be in the same order; for two
> ^^^^^^^^^^
> enumerations, the members shall have the same values.
>
> 이렇습니다. 물론 C99 가 최신 표준이며, 이 부분에서 C89 와 C99 가 호환되지 않는 측면이겠지요. 이 토론에도 C99 에 왜 그런 내용이 추가되었는지 이해되지 않는다는 말이 있습니다.
>

기본적으로 두 구조체형은 멤버가 같은 type, 같은 이름, 같은 순서로 선언
되어 있더라도 서로 다른 type 입니다. 심지어는 동일한 translation unit
안에서 위의 조건을 만족하고 동일한 tag 으로 선언되는 구조체도 서로
다른 type 이 될 수 있습니다 - 알고 계시리라 생각하고 예는 들지
않겠습니다.

이와 같은 구조체 호환 규칙이 분리된 translation unit 으로 논의를
옮기면 다소 완화됩니다. C99 이전에는 서로 다른 t.u. 에 놓인 구조체의
경우 tag name 이 동일하지 않더라도 동일한 layout 만으로 호환형이라고
정의하고 있습니다. 그리고 C99 에 들어와 tag identitiy 를 요구하기
시작했습니다.

우선 드릴 말씀은 C89 에서 인용하신 부분은 두 개의 "분리된" t.u. 에만
해당되는 부분이기 때문에 하나의 t.u. 안에서 선언되었고 동일한 layout
과 서로 다른 tag 을 갖는 두 구조체에는 적용되지 않습니다. 따라서
분리된 t.u. 임을 언급하지 않고 보여주신 예는 "여전히" 잘못된 예입니다.

그렇다면 보여주신 예에서 (C89 환경을 가정하고) 두 구조체 중 하나를
다른 t.u. 로 옮기면 어떻게 될까요?

/* C89 가정 */
 
- a.c -
struct t1 { ... };
extern int func1(struct t1 *);
 
- b.c -
struct t2 { ... } foo;
extern int func1();    /* 일부러 비원형으로 */
int (*func2)(struct t2 *) = func1;
func2(&foo);    /* okay */

결과는 이렇습니다. 즉 인용하신 규칙은 이와 같은 경우에 적용될 수 있는
규칙입니다.

그렇다면 상당히 재미있는 논의로 이야기가 이어집니다. (상당히 골치 아플
수 있으므로 잠시 커피 한잔 하시고 오는 것도 좋습니다. ;-)

소스 A 안에 구조체 foo 와 bar 는 동일한 layout 을 가지고 있지만 서로
호환될 수 없는 type 입니다. 소스 B 안에서 구조체 foobar 는 구조체 foo
와 동일한 layout 을 가지고 있기 때문에 foo 와 호환되며, 동시에 bar 와
호환됩니다. 결론적으로 foo-bar 는 호환되지 않는데, foobar-foo,
foobar-bar 는 호환됩니다.

그렇다면 foobar-foo, foobar-bar 의 관계에 의해 foo-bar 도 호환형으로
보아야 할까요? 즉, 소스 A 안에서 struct foo * 를 struct bar * 로 변환
해 멤버에 접근하는 것이 정의되는 것일까요?

(한 t.u. 안에서 동일한 tag 을 갖는 서로 다른 구조체형을 선언할 수 있기
때문에 이 문제는 C99 에도 그대로 적용됩니다.)

이러한 논리하면 하나의 t.u. 안에서 서로 동일한 layout 을 갖는 두
구조체는 다른 t.u. 의 동일한 layout 의 구조체와 호환될 수도 있는
가능성 때문에 사실상 호환되는 구조체로 보아야 하지 않을까요?

이것이 바로 님이 진정 묻고자 하는 바라고 생각합니다.

대답은 "No" 입니다. 정말 비논리적이라고 생각하시겠지만, type
compatibility 는 transitive 하지 않습니다. 즉, A 와 B 가 호환되고,
B 와 C 가 호환되어도 A 와 C 가 호환된다는 법은 없습니다. 이쯤 오면
(과거의 제가 그랬듯이) 대부분의 분들이 현실적인 구현체를 생각하면서
"표준이 잘못되었다", "현실적으로 말이 되지 않는다", "논리적이지
못하다"는 등의 반응이 나옵니다. 하지만, 이것이 규칙입니다. 즉, foo 를
foobar 로 보내고 bar 를 foobar 로 보내는 것은 가능하지만, foo 를 bar
로 직접 보내는 것은 불가능하다는 뜻입니다. 그렇다면 어느 경우에
현실적인 문제가 일어날 수 있을까요?

세 구조체가 모두 동일한 표현 (즉, 내부적인 layout) 을 갖는다고 해도
최적화의 가능성 때문에 정의되지 않은 행동이 발현될 수 있습니다. 즉,
서로 호환되지 않는 type 의 대상체에 접근해 값을 읽거나 변경하는 등의
행위가 UB 이기 때문에 그 부분에 구현체는 최적화를 가할 수 있게 됩니다.
C 처럼 aliasing 이 빈번히 일어나는 언어에서 비호환형에 대한 접근을
금지하는 것은 상당히 유용한 최적화를 허락하는 길입니다. 즉, 위에서
struct foo 형으로 struct bar 형의 대상체를 접근하는 행위가 최적화의
영향을 받아 엉뚱한 결과로 나올 수 있다는 것입니다.

벌써 3번째 언급되고 있습니다만, common initial sequence 에 대한 특별한
규칙 중 하나가 바로 공용체에 포함된 서로 다른 구조체를 통해서 c.i.s 에
접근할 때는 반드시 해당 공용체 선언이 보여야 한다는 것입니다. 이는
구현체에게 layout 은 물론 최적화도 신중히 할 수 있는 충분한 정보를
제공하기 위함입니다.

이 정도면 처음 질문하셨던 코드에서 struct s1, s2 가 호환되지 않는 type
이라는 점은 분명히 밝혔다고 생각합니다. type 호환성에 대해 구구절절
적은 부분에 대해서는 의심하지 않으셔도 좋습니다. 잘 찾아보시면 유사한
문제를 놓고 3-4년 전에 csc 같은 뉴스그룹에서 제가 논의한 글도 찾아보실
수 있을 것입니다.

>
> 물론 C99 가 최신 표준이며, 이 부분에서 C89 와 C99 가 호환되지 않는 측면이겠지요. 이 토론에도 C99 에 왜 그런 내용이 추가되었는지 이해되지 않는다는 말이 있습니다.
>
...
>
> 주장하는 바는 C99 가 최신 표준이어도, 이 논의에 대한 실질적 표준(de facto)은 C89 가 맞다는 것입니다. C99 에서 가한 제약이 타당한 근거를 가질 수 없다면, 표준이 틀렸다고 볼 수 있다는 것입니다.
>
> 즉, C99 상으로는 호환 없는 타입일지모르나, C89 상으로는 호환 되는 타입이며, 이 둘 중 무엇이 옳으냐는 단지 C99 가 최신 표준이라는 이유로 결정될 수 없다는 것이구요.
>

이제 또 다른 세부 질문으로, 왜 그와 같은 tag identity 규정이 분리된
t.u. 사이의 구조체 호환에 C99 가 되어서야 요구되었으냐에 대한 대답은
이렇습니다.

원래는 C89 부터 요구했어야 합니다. 사실 분리된 t.u. 사이에서 호환되는
구조체를 선언하는 바람직한 방법은 tag 을 동일하게 선언하는 것이었고
C FAQs 는 물론, 기타 거의 모든 style 관련 자료, C 언어 입문서에서 이를
다루고 있었기 때문에, 오히려 논의 중에 "C89 에 따르면 tag 가 달라도
된다"는 사실을 언급했을 때 놀라는 사람이 더 많았습니다. 즉, 지극히
당연하고 또 바람직하다고 생각했던 사실이었기에 C99 에서 문제 없이 그와
같은 요구가 명문화될 수 있었습니다.

C89 는 경험이 부족한 상태로 탄생한 첫 표준이기 때문에 모든 세세한 요구
를 다 담지 못한 경우가 많습니다. 즉, "암시적 요구"를 제대로 수용하지
못한 셈입니다.

참고로 구조체 포인터가 같은 정렬제한, 같은 표현을 갖는다는 보장은 C89
에는 없습니다. 즉, 님의 해석대로 C89 표준을 "의도"가 아닌 있는 그대로
받아들여야 한다면 C89 에서는 아예 서로 다른 구조체 포인터 사이의 변환
시점부터 UB 가 됩니다. 구조체 포인터의 동일 표현/정렬제한 역시 C89
에는 명문화되어 있지 않지만 표준의 다른 요구들을 기반으로 논리적으로
유추할 수 있는 요구이기 때문에 C99 에 추가된 것이고, C89 에도 그대로
적용되는 것으로 보는 것입니다 - 이 논리적 유추 과정 역시 1-2년전 csc
에 포스팅한 제 글에 적었던 것으로 기억합니다.

> 구조체의 포인터를 호환성 있는 타입으로 간주하는 무수히 많은 코드들이 현존합니다.
>

표준 위원회에서 어떤 결정을 내릴 때에는 각 업체의 전문가들이 모여 기존
코드에 대한 영향을 최소화하는 범위 내에서 결론을 내리게 되어 있습니다.
그 과정에서 이 세상 모든 C 코드가 감안될 수 있는 것은 아니지만,
"보존될 가치가 있는 중요한" 코드는 모두 고려 대상이 됩니다. 표준
이전부터 존재하던 관례적인 약속을 모르고 혹은 "일부러 무시하고" 작성한
코드까지 표준이 아끼고 사랑해야 하는 것은 아닙니다. 이러한 코드는 많은
경우 어차피 자신의 목적한 바를 C 표준 안에서는 얻을 수 없기 때문에
(C 표준 관점에서의) 이식성이 포기하면서 의도적으로 표준을 어기는
경우가 적지 않습니다. 표준이 그렇게 잘못 설계된 코드까지 배려해 얻을
수 있는 다른 이익(최적화로 인한 성능, 다양한 구현체 수용, type safety
향상)을 포기할지의 문제는 위원회에서 결정하게 됩니다. 그리고 적지 않은
경우 그 결정은 옳습니다.

> 게다가 C89 에서 그것은 표준이었구요. '표준'이 '옳다'를 의미할 수는 없습니다. 수정되어야 하는 부분도 반드시 있는 것이구요.
>

표준이 수정될 수 있는 경우는, 실제 의도를 제대로 전달하지 못했거나
(즉, 오해의 여지가 크거나), 명백한 논리적 모순이 담겨 있거나, 개선이
이루어지는 경우 뿐입니다. C89 시절의 규칙으로 돌아가는 것이 이 3가지
중 하나에 해당될까요? type safety 보강을 위해 implicit declaration 과
implicit int 도 과감히 제거한 C99 입니다.

이 정도면 충분히 구조체 형호환 문제는 다루었다고 생각합니다 - 더 이상
이 부분을 이야기하다가는 책이 나올 지경입니다.

* 함수 포인터 형변환의 가치

> C 언어에서는 분명히 함수 포인터 캐스팅을 지원합니다. 하지만, 전웅님 말씀대로라면,
> 이 함수 포인터 캐스팅은 어디에도 쓸 곳이 없습니다. 결국 표준을 위배하도록 만드는
> 함수 포인터 캐스팅 문법은 왜 C 표준인지요?
>
...
> C99 표준에 따르면, 함수 포인터 캐스팅 문법을 사용하는 것은
> 항상 표준을 위배하게 될 것으로 예상되지만, 여전히 함수
> 포인터 캐스팅 문법 자체는 표준인 것에 대해 어떻게 생각하시는지요?
>

정수-포인터간 변환의 결과는 표준 관점에서 100% 정의되지 않은
행동입니다. 서로 다른 type 의 포인터 변환의 결과는 표준 관점에서 90%
(^^) 정의되지 않은 행동입니다. void * 형은 dereferencing 도 불가능
하면서 void * 와의 포인터 변환이 정의되어 있습니다. volatile 를
"유의미"하게 사용하는 프로그램은 표준 관점에서 95% (^^) 이식성을 갖지
못합니다.

그럼에도 불구하고 표준은 표준의 위반 가능성을 높이는 구조를 포함하고
있을까요?

표준은 세상 모든 프로그램이 표준의 테두리 안으로만 들어와야 한다고
생각하지 않기 때문입니다. 즉, 구체적 메카니즘은 이식성을 갖지 않지만
최소한 그런 메카니즘에 접근할 수 있는 공통된 표준적인 방법은 제공할
가치가 있다는 것입니다.

하지만, 함수 포인터 사이의 변환은 다른 분께서 설명하셨듯이 표준의 범위
내에서도 유용하게 쓰이는 경우가 많습니다. void * 가 대상체를 접근하지
않도고 이식성을 갖는 방법으로 유용하게 쓰이듯이 함수 포인터도 꼭
호환되지 않는 type 으로 변환해 "호출해야지만" 유용하게 쓰이는 것은
아닙니다. (애초에 void * 로 변환하지 않으면 된다고 말씀하셨는데
저로서는 도저히 이해하기가 힘들군요. void * 가 도입되기 이전부터 많은
코드가 void * 개념의 포인터를 사용하고 있었고 이를 반영해 void * 가
도입된 것입니다. 표준이 void * 를 도입했기 때문에 사람들이 그 전까지는
없던 새로운 방법을 사용하기 시작한 것이 아닙니다)

다른 type 의 함수 포인터로 변환했다가 다시 원래 type 으로 되돌렸을 때
정보가 보존된다는 것은, 어떠한 type 의 함수 포인터도 함수 포인터의
generic 포인터로 쓸 수 있다는 것을 의미합니다 - 참고로 void * 는 함수
포인터의 generic 포인터 역할을 하지 못합니다.

제 경험을 기억해보자면 table-driven 방식을 피해 FSM 을 구현할 때 다음
state 실행을 위한 함수에 가리키는 함수 포인터를 반환하는 함수를 구현할
때 표준이 보장하는 함수 포인터 변환의 특성을 유용하게 사용했습니다 -
나중에 보니 이 문제가 C FAQs 에도 언급되어 있더군요. 물론 그 코드는
함수 포인터와 관련해서는 표준이 정의하는 행동의 범주 안에 머뭅니다.

또한 현재 하고 있는 일의 코드에서도 table-driven 방식과
function-driven 방식의 중간쯤에 해당하는 방법으로 FSM 을 구현할 때도
표준이 보장해주는 특성이 쓰이고 있습니다.

전자는 전부를 순수하게 제가 작성한 것이며, 후자는 이름만 말하면 다들
알고계실 외국 업체에서 기본 틀을 작성해 받아 확장한 것입니다. 즉, 저만
특이하게 그런 방법에 의존하고 있는 것이 아닙니다.

자신에게 쓸 곳이 없어 보인다고 "어디에도 쓸 곳이 없다"라고 단정짓는
것은 다소 성급한 일반화가 아닌가 생각합니다.

* C/C++ 이야기

> 이것 조차 표준 위배라면, 캐스팅을 아예 쓰지 않아야 된다는 말씀 같은데요.
> 그렇다면, C++ 에서 부모 클래스의 메소드를 자식 클래스 인스턴스가 호출하는 것은
> C 표준상으로 어떤 상태라고 보시는지요?
...
> 이 부분에서 호환을 논하자면, C++ 의 계승 구조에 대해서는 어떻게 생각하지는지요?
>
[C++ 코드 생략]
>
> 단지 C 와 C++ 이 다른 언어이기 때문이다라고 생각하시는지요?
>
...
> C++ 을 예로 든 것은, C++ 의 계승 구조에 대한 내부적 형태는 결국 C89 에서 정의하는 호환성있는 구조체에 대한 언급과 동일하기 때문입니다.
>

C++ 는 C 언어와 "다른" 언어입니다. 여러 부분에서도 많은 차이를
보이지만, 큰 차이를 보이는 부분 중 하나가 type system 입니다. C 에는
존재하지 않는 구조를 새로운 규칙과 함께 추가한 것은 논외로 치더라도
C++ 가 (결과야 어찌되었건) C 언어보다 더 안전한 type system 을 추구
했기 때문에 C 언어보다 캐스트 연산이 빈번하게 일어나며 (즉, 프로그래머
가 그와 같은 변환을 실제로 의도한 것임을 캐스트를 통해 확인받는 것으로
생각할 수 있습니다), 그 의미가 잘 정의되어 있는 경우가 많습니다. C++
에서 일어날 수 있는 경우라 해서 동일한 경우도 아닌 유사한 경우가 C
언어에서도 일어날 수 있다고 가정할 수는 없습니다. 두 표준을 비교해
보시면 아시겠지만, 동일한 형태의 선언도 전혀 다른 개념과 방법을 통해
정의하고 있는 부분이 많습니다. 그로 인해 C 언어가 어설프게 C++ 의 특징
을 도입했다가 수습되지 않는 기괴한 문제를 만나기도 합니다 - const 로
한정된 다차원 배열과 포인터 사이의 문제가 이에 해당됩니다.

반면, C 언어는 "표준 관점에서" 올바른 프로그램은 강제 형변환을 *거의*
하지 않아도 되도록 많은 부분에서 배려를 하고 있습니다. 따라서 표준을
따르는 프로그램을 작성하는 과정에서 강제 형변환이 나왔다면 이는 이식성
에 손상을 줄 수 있는 행동을 할 가능성이 큰 부분으로 이해하는 것이
좋습니다.

이 문제를 논함에 있어서 C++ 을 끌고 오는 것은 아무런 의미가 없습니다.
그 부분이 궁금하시다면 언어 vs. 언어의 관점이 아니라 둘을 포용하는
프로그래밍 언어론적 관점에서 접근하시는 것이 더 낫다고 생각해 봅니다.

마지막으로, C/C++ 비교는 가능한 "유사점"이 아닌 "차이점"에 중심을 두는
것이 바람직 하다는 것이 제 개인적인 생각입니다. 비록 C/C++ 위원회 모두
가 그 차이를 좁히는 것을 목표 중 하나로 하고 있다지만, 개인적인 바람
으로는 맘에 들지 않는 C 언어를 포함하려는 욕심으로 인해 더 맘에 안들어
버린 C++ 가 빨리 분리되어 나가기를 바랍니다.

이번주는 야근이 많아 주말에는 좀 느긋하게 쉬려 했는데 퇴근해서까지
컴퓨터 앞에 앉아있으려니 생각보다 지치는군요.. 휴...

점점 커지는 일교차에 감기 조심하시기 바랍니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org

아무튼 토론중 신경이 날카로워졌던 것은 피곤한 상태에서
머리를 굴리려니 힘에 부쳐 그런 것이니 이해해주시고,
이 스레드와 별도로 묻고 싶은 내용들이 있는데, 전웅님 개인
메일을 이용해도 괜찮을런지요. 답변은 편하실때 주시면 됩니다.
두세번 정도만 보내겠습니다.

표준 문제는 실무 능력과 별개로 항상 골치아프고 어렵습니다.

-----------------------------------
Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/

주제와 약간 벗어나는 감이 있지만, 전웅님 개인 메일을 이용하는 대신
질문을 하나 드릴까 합니다.

offsetof 관련 논의는 전에 있었던 것 같고, offsetof 가 일단 표준에 부합한다는 전제하에,
다음과 같은 코드는 표준에 부합한다고 보는데 어떠신지요?

struct _s1, _s2, _s3 는 서로 다른 구조체 이고,

struct _s1 {
	int a;
	struct _s2* b;
}* s1;
 
// _s1 의 b 멤버에, 옵셋과 _s2 대신 _s3 로 캐스팅하여, NULL 을 대입한다.
*(struct _s3**)( (char*)s1 + offsetof(struct _s1,b) ) = NULL;

그리고 다음,

union {
    struct _s1* s1;
    struct _s3* s3;
} var;
 
struct _s1 s1;
var.s3 = (struct _s3*)&s1;
var.s1->a = 1;

대충 뭘 고민하고 있는지 아시리라 생각합니다.
맞는 것 같아도, 소스 수정의 대란을 몇 번 겪으니 아주 조심스럽군요...

----------------------------------------
Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/