char 포인터 질문

아마 구조체의 마지막에 보신게 아닌가 생각합니다.

맞나요? 그렇다는 가정하에
저런 테크닉은
구조체 내에 data를 담는 크기를 계산하지 않고
바로 그 구조체 뒤에 따라나오는 데이터를 포인트하기 위해서 만듭니다.
보통

struct  header{
 // 이런 저런 헤더 변수들
 char data[0]
};
sturct header * head= malloc (sizeof( header) + data_size);

제가 알기론 C표준이 아니라 gcc익스텐션으로 알고 있고
char data[0]; 와 같은 statement는 문법위반인지 undefined behavior인지
확실치 모르겠네요 ^^

PS. 잘못된 부분이 있어 수정 합니다. ^^

저도 초보라서 ^^ 자세한 구현내용은 모르나
다만 header의 바로 다음을 가르키기만 할듯 하니까 매우 쉬울듯 합니다. (항상 constant한 것처럼 보이자나요 header가 있을때 몇바이트 뒤니까요 ^^)
head.data = ~~ ; ==>
(char * ) head + sizeof( struct header) = ~~ 정도로 바뀌지 않을까요?

gcc의 확장 기능입니다. Arrays of Length Zero을 참고하십시오.
이와 관련된 글로서 C FAQs Q 2.6과 C FAQs Q 11.G이 있습니다.

일반적으로 쓸때 편하다고 생각이 되네요

struct mm
{
	int a;
	char data[0];
};

int main()
{
    	mm k[4];
}

재미있어 보였는데 아쉽네요;;;

마찬가지 컴파일 에러군요..

그리고 C99를 완벽하게 지원하는 컴파일러가 있긴 있나요?

그리고 flexible array member는 C++ 표준에 없습니다.

출동했습니다. --;

기본적으로 어떤 데이터형 X 의 정렬 제한을 align(X) 라고 놓겠습니다. 이
수는 1 이상의 정수가 될 수 있습니다. 물론, sizeof(X) % align(X) == 0
이어야만 합니다 - 그래야만 padding 없이 배열 요소가 모두 올바르게
정렬될 수 있습니다.

이제 malloc() 로 할당된 메모리의 정렬 제한에 대한 이야기부터
시작하겠습니다.

malloc() 가 반환하는 메모리에 가해지는 정렬 제한과 관련된 유일한
제약은, 그 *시작* 주소가 해당 구현체에서 가능한 모든 데이터형에 대해
정렬 제한을 만족해야 한다는 것입니다. 따라서,

int *p = malloc(sizeof(int)*n); // successful allocation assumed

에서 p 는 항상 올바르게 정렬되며, (p+i) 도 i <= n 인 이상 정렬 제한
문제를 겪지 않습니다. 하지만,

p = (int *)((char *)p + m);

에서는 m 이 align(int) 의 배수 (따라서 m % align(int) == 0) 가 아닌
이상 정렬 제한을 위반할 수 있다는 사실에 유의하셔야 합니다.

이제 언급한 문제로 돌아가 보겠습니다. "다른 데이터형을 모두 무시하고
예에 나온 데이터형만을 고려했을 때" malloc() 가 반환하는 메모리는
최소한 LCM(align(S), align(T), int) 에 정렬되는 메모리입니다. [*] 이제
위 코드가 정렬 제한 문제를 일으키는 경우는 sizeof(S) 가 align(T) 의
배수가 아닌 경우를 찾는 문제가 됩니다 (앞서 제가 보인 예와 비교해
보시기 바랍니다). 물론, 이와 같은 경우는 얼마든지 상상할 수 있지만,
여기서는 S 가 구조체라는데 특별히 주목할 필요가 있습니다. 구조체와
관련해서는 다음과 같은 사항이 덧붙습니다.

- 모든 구조체는 공통된 정렬 제한을 갖습니다. [**]
- 모든 (object) 데이터형이 구조체의 첫 번째 멤버로 선언될 수 있습니다.
- 구조체의 가장 앞 부분에는 padding 이 붙지 않습니다.

따라서 구조체는 사실상 malloc() 가 반환하는 메모리의 정렬 제한을
가져야 하고, 결국, (ps+1) 역시 동일한 정렬 제한을 만족하게 되므로
(T *) 데이터형으로의 변환에 아무 문제가 없게 됩니다.

여기까지가 실제 implementation 에서 일어나는 이야기입니다. 이제 표준에
관심있는 분들을 위해 엄격한 표준의 관점으로 들어가 보도록 하겠습니다.

동일한 데이터형이라고 해도 구조체 멤버일 경우와 그렇지 않은 경우 정렬
제한이 달라질 수 있습니다. 즉, 포인터를 위한 "일반화된 정렬 제한"이
존재하고 구조체 안팎에서 서로 다른 정도로 정렬 제한을 강요하는 것이
가능합니다.

예를 들어, 어떤 데이터형 Y 가 12 바이트 크기를 갖고, 데이터형 Y의
대상체가 구조체 멤버인 경우에는 align(Y) = 4, 구조체 멤버가 아닌
경우에는 align(Y) = 6 이라고 가정하겠습니다. 이 경우 12 % 4 == 0,
12 % 6 == 0 이므로 배열과 관련된 문제는 없습니다. 이때 포인터는 구조체
안팎의 대상체를 모두 가리킬 수 있어야 하므로 "일반화된" 정렬 제한은
GCD(4, 6) = 2 가 됩니다. 하지만, 데이터형 Y의 구조체 안팎의 정렬
제한을 생각하면 모든 짝수가 올바른 (Y *) 타입의 포인터 값은 아니라는
것을 알 수 있습니다. 즉, 설명을 위해 주소 공간이 linear 한 경우를
생각해보면 2나 10의 경우 분명 짝수이지만, 해당 번지에는 결코 데이터형
Y의 대상체가 올 수 없음을 쉽게 알 수 있습니다. 이제 이와 같은 경우
(즉, sizeof(S) 가 "일반화된" 정렬 제한의 배수가 아니거나 유효하지 않은
배수가 되는 경우)가 문제로 주어진 경우에도 발생할 수 있는지 생각해
보겠습니다.

구조체 멤버일 때의 정렬 제한을 Salign(), 일반화된 정렬 제한을 Galign()
이라고 부르겠습니다. 지금까지의 내용을 바탕으로 요구되는 관계를
정리하면 다음과 같습니다.

sizeof(S) % align(S) == 0 --- (1)
sizeof(T) % align(T) == 0 --- (2)
sizeof(T) % Salign(T) == 0 --- (3)
align(S) % Salign(T) == 0 --- (4)
Salign(T) % Galign(T) == 0 --- (5)
align(T) % Galign(T) == 0 --- (6)

(1), (2), (3) 은 당연한 이야기입니다. (5), (6) 은 "일반화된" 정렬
제한을 구하는 과정에 의한 것이며, (4) 는 S 가 구조체이고, 이 구조체의
정렬 제한은 "최소한" 데이터형 T의 멤버를 첫 번째 멤버로 갖는 다른
구조체와도 같아야 하기 때문에 주어진 조건입니다. 배수 관계는
transitive 하기 때문에 이 조건을 정리하면 sizeof(S) 는 항상 Galign(T),
Salign(T) 의 배수가 됨을 알 수 있습니다. 하지만, sizeof(S) 가 반드시
align(T)의 배수가 될 필요는 없다는 것도 알 수 있습니다. 단, 이미
언급했듯이 앞서 살펴본 경우와 달리 이 경우에는 sizeof(S) 의 배수가
항상 유효한 Galign(T) 의 배수임만을 확인하면, sizeof(S)와 align(T)의
관계는 중요하지 않습니다. sizeof(S) 가 항상 Salign(T) 의 배수이고,
Salign(T) (의 배수)는 항상 유효한 Galign(T) 의 배수이기 때문에 결국
sizeof(S) 가 항상 Galign(T) 의 유효한 배수임을 확인할 수 있습니다.
따라서 엄격한 표준 해석을 적용해도 문제를 일으키지 않습니다.

[*] malloc() 가 정렬 제한을 보장하는 방법에는 모든 type 에 정렬될 수
있는 주소를 취하는 것 이외에도 malloc() 로 할당되는 메모리의 정렬
제한을 char 수준으로 완화되는 것도 가능합니다. 하지만, 이 경우는
제기된 문제를 압박하는 경우가 되지 않으므로 고려하지 않습니다.

[**] 구조체의 정렬 제한과 관련된 문제는 C99에 새로 추가된 요구입니다.
하지만, opaque type 이 작동하기 위해서는 C90 에서도 사실상
있었어야 하는 요구이므로, 모든 표준이 사실상 이를 요구하고 있다고
보아도 무방합니다.

그럼...

p.s. 절 미쳤다고 생각하진 마시고, 그냥 이런거 하면서 재미느끼는 사람도
있구나 정도로 생각해 주시기 바랍니다. --;

그러고 보니 잘못 적었군요. 의도한 바는 LCM(align(S), align(T),
align(int), align(T *)) 정도가 되겠네요. 보다 정확히 적자면,
LCM(align(S), align(T), align(int), align(T *), C 언어의 정렬 제한이
다른 가능한 모든 타입...) 가 되어야 합니다. 따라서 align(T) 냐
align(T *) 냐는 답과는 상관 없습니다.

아닙니다. 일단 ps 가 모든 type 에 대해서 정렬이 되어야 하므로, (ps+1)
역시 모든 type 에 대해서 정렬이 되어야 합니다.
sizeof(S) % align(S) = 0 이라는 점을 적용해 보시기 바랍니다.

적혀 있듯이, 구조체의 첫 번째 멤버로 T 형을 갖는 구조체와도 문제 없는
정렬 제한을 가져야 합니다. 물론, 첫 번째 멤버로 T * 형을 갖는
구조체와도 문제가 없어야 하구요. 문제를 해결할 때 중요한 것은 첫번째
멤버로 T 형을 갖는 구조체이기에 그것만 고려했을 뿐입니다. T * 형을
계산에 추가하는 것이 답에 영향을 주지는 않으며, T 형을 빼는 것은
불가능합니다.

그럼...

사실 위에서 언급했듯이 모든 구조체가 같은 정렬 제한을 가져야 한다는
요구가 없으면 (증명 과정에서 가장 중요한 근거가 사라지게 되므로)
문제의 코드는 당연히 정렬 제한 문제를 겪으며, C FAQ 2.6 역시 고칠
필요가 없습니다.

하지만, 그와 같은 (사실상 C90 에도 내재되어 있던) 요구가 C99 에
명시적으로 추가되었기 때문에 가시적인 차이가 발생하게 되었습니다.
사실상 struct hack 에 대한 해결책을 제시하기 위해 추가된 부분이 아닌데
본의 아니게 그와 같은 역할을 할 수 있게 된 것 같습니다.

매우 pedantic 한 입장에서 제가 마지막으로 의심을 갖는 부분은 "모든"
구조체가 동일한 정렬 제한을 가져야 한다는 요구 조건이 "해당 구현체에서
가능한 모든 구조체"에 적용되는 것인지, 아니면 "어떤 프로그램에
존재하는 모든 구조체"에 적용되는 것인지가 불분명합니다.

문제가 되는 부분이 일반적인 type 을 정의하고 설명하는 부분이기 때문에,
또한 그와 같은 요구가 도입된 가장 큰 배경이 opaque type 지원이기
때문에, 이론적으로나 현실적으로나 "해당 구현체에서 존재하는 모든
구조체"에 적용되는 것으로 보는 것이 타당한 것 같습니다만, 제가
유권해석을 내릴 수 있는 입장이 아니라 장담은 못합니다. 이 부분은 곧
csc 에서 한번 논의해보려 합니다 - 만약, 해당 논의에서 제 주장과 동일한
결론이 나오는 경우 Steve Summit 씨께는 해당 논의 링크를 전달하는 것
만으로도 충분할 것입니다.

하지만, C FAQs 의 성격을 보았을 때 수정이 이루어지지 않을 가능성이
크다고 봅니다. 질문 2.6 이외에도 이미 다른 몇몇 부분에서 설명을 쉽게
하기 위해 잘못된 설명을 한 부분이 있지만, 실용적인 프로그래밍에서는
크게 영향을 미치지 않는 부분들입니다. 이 부분 역시 이미 C99 에서 FAM
를 지원하는 상황에서 그와 같은 설명을 굳이 수정, 추가할 이유는 그리
커보이지 않습니다.

그럼...

흠... 이 문제로 처음 생각했던 것보다 한참을 고민하게 되었습니다.
덕분에 제가 잘못 알고 있던 부분도 확실히 고쳐 알 수 있는 계기가
되었습니다.

저 위에 틀린 내용들이 많이 있지만, 겉으로는 번지르해 보이는 논리가
틀릴 수도 있다는 사실을 알리고자(--;) 굳이 편집하거나 지우지 않고
아래에 새로 답을 달도록 하겠습니다.

우선, 중요한 내용 하나를 정정하자면,

C90에 이미 암시되어 있고, C99에 명시적으로 추가된 구조체와 관련된 정렬
제한 내용은, 구조체 자체가 아닌 구조체 포인터에 대한 정렬 제한 이야기
입니다. 오랜만에 표준 인쇄본을 펼치니 해당 페이지에 "구조체가 아닌
포인터에 대한 이야기임!"이라고 메모가 되어 있는데도 정성을 덜 들인
탓인지 금새 잊어버리고 말았네요. 따라서 모든 구조체가 반드시 같은 정렬
제한을 가질 필요는 없습니다. 이런 사실을 바탕으로 앞서 말씀드렸던
잘못된 답변을 올바르게 고쳐 정리하겠습니다.

기본적으로 어떤 데이터형 X 의 정렬 제한을 align(X) 라고 놓겠습니다. 이
수는 1 이상의 정수가 될 수 있습니다. 물론, sizeof(X) % align(X) == 0
이어야만 합니다 - 그래야만 padding 없이 배열 요소가 모두 올바르게
정렬될 수 있습니다.

이제 malloc() 로 할당된 메모리의 정렬 제한에 대한 이야기부터
시작하겠습니다.

malloc() 가 반환하는 메모리에 가해지는 정렬 제한과 관련된 유일한
제약은, 그 *시작* 주소가 해당 구현체에서 가능한 모든 데이터형에 대해
정렬 제한을 만족해야 한다는 것입니다. 따라서,

int *p = malloc(sizeof(int)*n); // successful allocation assumed

에서 p 는 항상 올바르게 정렬되며, (p+i) 도 i <= n 인 이상 정렬 제한
문제를 겪지 않습니다. 하지만,

p = (int *)((char *)p + m);

에서는 m 이 align(int) 의 배수 (따라서 m % align(int) == 0) 가 아닌
이상 정렬 제한을 위반할 수 있다는 사실에 유의하셔야 합니다.

이제 언급한 문제로 돌아가 보겠습니다. "다른 데이터형을 모두 무시하고
예에 나온 데이터형만을 고려했을 때" malloc() 가 반환하는 메모리는
최소한 LCM(align(S), align(T), align(int), align(T *), ...) 에
정렬되는 메모리입니다. [*] 이제 위 코드가 정렬 제한 문제를 일으키는
경우는 sizeof(S) 가 align(T) 의 배수가 아닌 경우를 찾는 문제가 됩니다
(앞서 제가 보인 예와 비교해 보시기 바랍니다). 이와 같은 경우는 충분히
상상해 볼 수 있기 때문에 해당 코드가 정렬 제한 문제를 일으킬 수 있다는
사실은 쉽게(비록 전 쉽게 알지 못했습니다만) 알 수 있습니다.

이제 조금 더 복잡한 경우로 구조체 S 가 다음과 같은 선언된 경우를
생각해 보겠습니다. (솔직히 저 위에서 멈추기에는 민망해서 예 하나 더
추가합니다 ;-)

typedef struct S__ { 
    T dummy;
    int i; 
    T *buf; 
} S;

S object, *foo = &object;

첫 번째 멤버로 T dummy; 를 넣은 이유는 구조체 S 의 padding 을 결정할
때 이 구조체 타입의 배열이 고려되어야 하기 때문에 foo 는 물론, foo+1
역시 T 형에 올바르게 정렬된다는 사실을 얻기 위해서 입니다.

물론, 이와 같은 생각 아래에는 다음과 같은 가정이 깔려 있습니다.

- p 가 데이터형 T 에 대해 올바르게 정렬되어 있고 p 가 가리키는 곳에
데이터형 T 의 대상체가 존재하는 경우, p+1 역시 항상 데이터형 T 에
대해 올바르게 정렬된다.

실재하는 구현체를 고려했을 때 이 가정이 맞지 않는 구현체는 없다고 확신
합니다. 따라서 처음 주어진 코드에 T dummy; 를 첫번째 멤버로 추가해
주는 경우 실제 구현체에서는 정렬 제한 문제를 겪지 않습니다.

하지만, 제가 적은 가정이 표준에 의해서 명백하게 보장되지는 않습니다.
표준에 의하면 정렬(alignment)은 대상체(object)에 대해 정의되어
있습니다. 즉, 대상체가 존재하지 않으면 정렬 역시 존재하지 않습니다.

따라서,

int i, *pi = &i;
short *ps = (short *)pi;

이와 같은 코드는 정렬 제한 문제를 겪지만,

int *pi = NULL;
short *ps = (short *)pi;

이와 같은 코드는 정렬 제한 문제를 겪지 않습니다. 널 포인터 자체가
"아무 것도" 가리키지 않는 포인터이기 때문에 대상체가 관여할 수 없고
결국 정렬 제한이 적용될 수 없기 때문입니다.

하지만,

typedef struct S__ { 
    T dummy;
    int i; 
    T *buf; 
} S;

S object, *foo = &object;

이 코드에서 foo+1 의 의미에는 다소 문제가 있습니다. 분명, foo+1 이
어떤 대상체를 가리키는 것은 결코 아니지만, 그렇다고 널 포인터마냥 아무
것도 가리키지 않는다고 할 수도 없는 상황이기 때문입니다. 이 부분에
대해서 표준이 침묵하고 있기 때문에 foo+1 의 정렬에 대한 가정이
만족된다고 확신할 수는 없습니다만, foo+1 의 정렬 제한이 만족됨을
보장해주지 않을 경우 매우 무의미하며 이상한 결론으로 귀결되기 때문에
필히 그 의도는 foo+1 의 정렬을 보장해주는 것이라 믿고 있습니다.

물론, 이와 같은 흐름의 해석에서는 첫번째 멤버로 데이터형 T 의 대상체가
나왔기 때문에 더 이상 구조체 안팎에서 다른 정렬 제한을 갖는 이론적
이야기는 다룰 필요가 없습니다 - 하지만, 몇몇 분들에게는 흥미로울 수
있는 이야기라 생각하기에 삭제하지 않았습니다.

[*] malloc() 가 정렬 제한을 보장하는 방법에는 모든 type 에 정렬될 수
있는 주소를 취하는 것 이외에도 malloc() 로 할당되는 메모리의 정렬
제한을 char 수준으로 완화되는 것도 가능합니다. 하지만, 이 경우는
제기된 문제를 압박하는 경우가 되지 않으므로 고려하지 않습니다.

역시 까다로운 문제를 건드리기 시작하면 어김없이 표준의 "어두운"
부분으로 들어가게 되어있나 봅니다. 처음엔 자신만만하게 답변을 드리려는
의도였는데, 결과적으로 저 역시 많은 것들을 배워 갑니다. 감사합니다.

그럼...

flexible array member 는 C 에 항상 있습니다. 단지 [0] 이나 []
처럼 선언하는 것을 지원하지 않을 뿐, 배열 크기로 1 이상의
값 (대개는 1)을 주고 malloc 할 때 잘 조절해주면 되니까요.

그리고 C++ 표준에는 flexible array member 가 결코 들어갈 수
없습니다. new 를 오버로딩하지 않는한 절대 불가능하니까요.

물론입니다. 하지만, 위에서 OP 께서 보여주신 코드를 다룰 때 "설명이
용이하면서도 가장 압박할 수 있는" 환경은 바로 malloc() 가 반환한
메모리의 정렬 제한이 모든 type 의 정렬 제한의 최소 공배수가 되는 경우
입니다. "[*]" 부분에서 말씀드렸듯이 가장 완화되는 경우는 malloc() 가
반환하는 메모리 영역에 아예 정렬 제한이 요구되지 않는 경우입니다.
체스맨님께서 아래 언급해주신 상황은 그 두 극단 사이에 있는 상황입니다.

두 극단이든 그 중간의 한 상황이든, 어떠한 경우에도 malloc() 가
반환하는 메모리는 모든 type 에 대해 정렬 제한 문제를 겪지 않아야
합니다. 또한, malloc() 가 반환한 메모리가 특정 type 의 배열로 사용될
경우를 고려해 (type *)"malloc'ed storage" + n 역시 정렬 제한 문제를
겪지 않아야 합니다. 이와 같은 요구를 반영해 정렬 제한 문제를
설명하고자 할 때 alignment modulus 를 사용한다면 LCM(...) 가 가장
적절합니다 (그렇게 하지 않으면 일반화된 해석을 얻기 어렵습니다).

C 언어의 입장에서는 double 과 long double 이 type algebra 를 제외하면
동일하게 다루어지는 type 일 수 있기 때문에 여기서는 "long double" 로
IEEE 754 의 extended (double) precision 을 의미하시는 것으로
이해하겠습니다.

"대개의 하드웨어"에 x86 계열이 포함되지 않는다면 "대개의 하드웨어"가
long double 계산을 지원하지 않습니다. x86 및 그 클론은 extended-based
system 의 대표적인 예입니다. 즉, IEEE 754 의 single precision/double
precision 을 full support 하지 않으며, double-extended precision 을
full support 하고 있습니다.

여기서 "최적이 아니다"란 말씀은 "불필요하게 엄격한 부분이 있다" 는
의미로 이해하겠습니다. 언급했듯이 malloc() 가 반환하는 메모리에
가해지는 요구가 alignment modulus 로 기술되어 있지는 않습니다. 따라서
각 구현체마다 다양한 방법으로 표준 요구를 만족할 수 있습니다. 예를 들어,
다음과 같은 경우도 가능합니다.

char 를 제외한 모든 type 의 "일반화된" 정렬 제한은 2 입니다. 단,
sizeof(type) >= 4 인 모든 type 은 지역 선언에 의해 선언된 type 일 경우
에는 성능상의 이유로 sizeof(type) 을 정렬 제한으로 갖습니다. 따라서
align(double) == 8 이며, align(long double) == 10, align(int) == 4
등이 됩니다. 하지만, 말씀하신 "최적"에 가깝게 가기 위해 malloc() 를
통해 할당된 메모리 영역의 정렬 제한이 2 가 될 수 있습니다. 이 경우
align(malloc'ed storage) % 4 != 0 && align(malloc'ed storage) % 8 != 0
이어도 "일반화된" 정렬 제한이 2 이기에 실제적인 정렬 제한 문제를 겪지
않습니다.

혹은 좀 더 그럴싸한 예로, sizeof(type) >= 4 인 모든 type 의 정렬
제한은 4 입니다. 따라서 sizeof(type) % 4 == 0 인 type 은 큰 문제를
겪지 않지만, sizeof(type) % 4 != 0 인 type 은 문제가 될 수 있습니다.
따라서 long double 에 맵핑되는 extended precision 은 IEEE 754 를 따라
실제 10 바이트이지만, 이와 같은 정렬 제한 문제 때문에 long double 에
2 바이트의 패딩을 담습니다 - 특정 환경이 번뜩 떠오르는 분들도 계실
겁니다.

정렬 제한과 관련된 많은 부분은 implementation-defined 입니다. 저는
줄곧 흔히 "alignment modulus" 라고 부르는 방법으로 이를 설명하고
있지만 위원회 멤버 중에는 이런 방식의 설명을 못마땅하게 생각하는
사람도 있습니다 - 하지만, 최소한 "alignment" 의 정의가 이를 부분적으로
지지하고 있다고 생각합니다. 하지만, 이미 "일반화된 정렬 제한"의 예에서
볼 수 있듯이 "align(type) == 단일 정수" 의 단순한 모델은 적용할 수
없음은 분명합니다.

예, 가능한 방법입니다. 하지만, C99 이전에는 가급적 struct hack 을
위해서 그야말로 "hack" 을 쓰지 않기를 추천합니다. 굳이 hack 을 써야
한다면 C90 표준의 지원 여부를 떠나 C99 의 FAM 과 유사한 형태로
사용하시길 추천합니다 - 어차피 C FAQs 에서 C90 표준이 지원하지
않는다는 두 형태가 실제 작동하지 않는 환경은 찾기 어렵습니다. 즉, 추후
C99 환경으로 이전할 때 가능한 수정이 적은 방향으로 작성하는 것이
유리합니다. 이때 다른 부분은 큰 문제를 일으키지 않지만 sizeof(구조체)
에 유의하셔야 합니다. C99 에서 FAM 이 포함된 구조체의 경우 정렬 제한
만족을 위한 padding 만 크기에 고려될 뿐, 실제 FAM 은 포함되지
않습니다.

그럼...

정렬 제한과 관련해 약간의 오해가 있는 것 같습니다. 지극히 이상적인
상황이지만 다음과 같은 경우를 생각해 보겠습니다.

1. 메모리의 addressing system 으로 linear address space 를 가정합니다.
즉, 바이트 단위로 0 부터 메모리의 끝까지 연속적인 주소 공간이
형성되고, 포인터의 값은 바로 그 주소값을 나타냅니다. 예를 들어,
포인터가 12번지에 있는 대상체를 가리킨다면 그 포인터의 값은 정수로
변환했을 때 12가 됩니다.

2. 특정 type T 에 대한 정렬 제한을 간단히 "align(T) == 단일 정수"로
표현할 수 있다고 가정합니다.

3. sizeof(short) == 2, sizeof(int) == 4 를 가정합니다.

4. align(short) == 2, align(int) == 4 를 가정합니다.

이때 align(short) == 2 란 이야기는 short 데이터형의 대상체는 모두 2의
배수 번지에 놓여야 한다는 것을 의미하며, 유사하게 align(int) == 4 란
이야기는 int 데이터형의 대상체가 모두 4의 배수 번지에 놓여야 한다는
것을 의미합니다. 따라서 short 데이터형의 포인터의 값은 항상 2의 배수가
되어야 하며, int 데이터형의 포인터는 항상 4의 배수가 되어야 합니다.
포인터 변환시 정렬 제한 문제가 만족되어야 한다는 것은, int * 는 항상
4의 배수 값을 가져야 하며, short * 는 항상 2의 배수 값을 가져야 한다는
것을 의미합니다. 물론, 일부 계열에서는 정렬 제한이 만족되지 않는 경우
성능 저하 정도로 끝나지만, 다른 환경에서는 프로그램 강제 종료까지 만날
수 있습니다.

이제 제가 처음에 든 예를 (이론상 잘못된 것은 아니지만 현실적으로
부적절한 면이 있으므로) 다음과 같이 바꾸겠습니다.

short arr;
int *pi = (int *)&arr;

이때 arr 이 12번지에 할당되었다고 가정하겠습니다. 이 경우 &arr 의 값은
12가 되며, 12 는 2의 배수인 동시에 4의 배수도 될 수 있기 때문에 int *
의 값이 되는데 아무런 문제가 없습니다.

하지만, arr 이 14번지에 할당되는 경우 short * 로는 문제가 없지만 int *
가 가져서는 안 되는 값이 되기 때문에 정렬 제한 문제를 일으킬 수
있습니다.

실제 예를 확인해 보면 다음과 같습니다.

purple% cat > t.c 
#include <stdlib.h>

int main(void)
{
    short *ps = malloc(sizeof(*ps) * 4);
    int *pi = (int *)(ps+1);    /* undefined behavior */

    *pi = 0;

    return 0;
}
purple% cc t.c
purple% ./a.out
Bus Error (core dumped)

여기서 한가지 유의하실 부분은 포인터 변환시 정렬 제한을 어기게 되면
바로 변환이 이루어지는 시점부터 정의되지 않은 행동이 된다는 것입니다.
즉, 실제로는 위의 예처럼 직접 해당 메모리에 접근하려 할 때 문제가 되는
경우가 대부분이지만, 이론상으로는 (int *)(ps+1) 에서 프로그램이 오작동
하는 것도 가능합니다. 직접 본 적은 없지만 실제 정렬 제한을 만족하지
않는 변환일 경우 구현체 차원에서 포인터 값을 조정해 정렬 제한을
만족하도록 해줄 수도 있다고 합니다. 이 경우 (short *)(int *)(ps+1) 가
원래 포인터인 (ps+1) 과 다른 값이 되는 결과가 나올 수도 있습니다.

그럼...

p.s. 추운 날씨에 건강 조심하시기 바랍니다. ^^

정말인가요?

정렬제한이 메모리의 공간에 정렬하는 것 이상으로 다른 뭔가가 있나요?

좋은 자료있으면 부탁드립니다.

설명 감사합니다.

이해했습니다.

-- 덧붙이는 글 --
넘 무지해서 예제를 이해하는데 시간이 걸렸습니다.
예제 작성시 특정부분만을 설명하는 예제를 사용해 주시면 감사합니다.

저 같은 초보를 위해서

제가 이해했던 것을 도형으로 그립니다.

short s, *ps = &s;
int *pi = (int *)ps;    /* undefined behavior */ 

다음을 가정합니다.
정렬은 4의 배수로 한다는 가정하여
short의 크기는 2byte
포인터의 크기는 4byte인 경우
short s가 정렬제한에 위치했을때.

short s      |_______|
          +1 |_______|
             |_empty_|  // 정렬 문제
             |_empty_|  // 정렬 문제
short *ps    |_______|  // short s의 번지가 저정됨
             |_______|
             |_______|
          +3 |_______|
int *ps      |_______|   // short s의 번지가 저장킴
             |_______|
             |_______|
           +3|_______|


 *ps 을 접근하는 것은 정렬 제한으로 인한 문제가 발생할 수 있다.

※ 이 그림은 물리적으로 연속적인 메모리 구조를 갖을때의 그림입니다. 

자세한 설명 감사합니다.
잘못된 것을 바로잡아 준 전웅님께 감사드립니다.

이 부분의 글이 잘못 전달될 수 있기에 전웅님께 양해 말씀드립니다.

궁금한것이 있어 질문드립니다.

(int *)(a+1)    // a[1]
  >>구현체가 변환 결과가 int 형에 적절히 정렬되지 않음을 알고
      미리 그 값을 조정하지 않는 이상 

아니면

(int *)(a+1)    // a[2], 
  //구현체가 변환 결과가 int 형에 적절히 정렬되지 않음을 알고
      미리 그 값을 조정한 경우
 

아니면, 형변환으로 int 자료형 만큼 이동해야 한다고 생각해야 하나요?

또한번 잘못 이해 했습니다. 의 궁금증은 사라졌으며 바로 위 내용을
읽었다면 무시하시기 바랍니다.

많은 분들께 폐를 끼친것 같아 죄송합니다.