문자열 내에서 매크로 사용하기 질문

sia79의 이미지

#define AA (04)

printf(" %AAd ...", 1 );

원하는결과 0001

%04d를 표현해서 사용하고 싶은데, 어떻게 해야하나요?

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

sia79의 이미지

답변대로 하면 공백3개와 1이 찍히는데요.
* 이외에,

따로 문자열내에서 전처리어와 문자를 구분해주는 기호같은 것 없나요?

뭔가 기억에 있는 것같은데... 아우욱.

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

익명사용자의 이미지

printf(" %*d ...", AA, 1 );

전웅의 이미지

전처리 과정에서 직접 문자열을 넣는 방식으로 이루어지는 것이라는 이런
것도 있습니다.

#include <stdio.h>
 
#define str(x) #x
#define xstr(x) str(x)
#define AA 04
 
int main(void)
{
    printf("%" xstr(AA) "d\n", 1);
 
    return 0;
}

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

익명사용자의 이미지

#define xstr(x) str(x)
Is there any reason you have to use indirection like that?
(sorry for english, but can't type korean)

전웅의 이미지

#define str(x) #x
#define AA 04
 
str(AA)    /* results in "AA" rather than "04" */

전처리기 연산자인 ## 와 # 는 주어진 인자를 확장하지 않기 때문입니다.
잘 활용하면 가변인자가 허용되는 C99 에서 인자가 주어졌는지 안
주어졌는지 판단해 서로 다른 확장 결과가 나오도록 트릭을 구성할 수도
있습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

puaxx의 이미지

     #include &lt;stdio.h&gt;
 
     #define AA "04"
 
     int main(int argc,char **argv){
 
       printf("%" AA "d",1);
 
       return 0;
 
     }

전웅의 이미지

문제의 조건을 임의로 바꾸면 아무나 답변할 수 있습니다. ;-)

OP 께서 나중에 AA 를 정수 상수로 확장해 사용하고자 한다면 어떻게
un-stringize 하실 것인지요?

정확한 문제 상황이 기술되지는 않았지만, (04 의 확장 결과가 10진 정수
상수가 아니라는 점을 감안할 때) 제가 보기에 best solution 은

#define str(x) #x
#define xstr(x) str(x)
 
#define PREFIX "0"
#define WIDTH xstr(AA)
 
#define AA 4
 
...
 
printf("%" PREFIX WIDTH "d", 1);

나, PREFIX 를 직접 문자열에 넣거나, 혹은 stringization 을 위한 매크로
를 지운 후에

printf("%" PREFIX "*d", AA, 1);

로 사용하는 것 정도라 생각합니다. 질문에 zero flag 가 AA 에 포함된
것으로 보아 flag 를 매크로를 통해 수정할 필요가 있다고 가정할 때,
개인적으로는 마지막 것이 가장 깔끔해 보입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

PREFIX를 별도로 할당하는 것은 의미 없고 오히려 0이 아닌 다른 값을 넣어도 된다는 의미로
해석될 수 있으므로 오류를 유도하게 됩니다.
그러므로,

printf("%0*d", AA, 1 );

또는
printf("%#0*i", AA, 1 );

가 깔끔하군요.

전웅의 이미지

> PREFIX를 별도로 할당하는 것은 의미 없고

??? 의미 있는지 없는지는 상황에 따라 달라집니다.

> 오히려 0이 아닌 다른 값을 넣어도 된다는 의미로
> 해석될 수 있으므로 오류를 유도하게 됩니다.

??? zero flag 가 아닌 다른 flag 를 넣기 위해서 PREFIX 라는 매크로로
뽑아낸 것입니다. 즉, code 내에 유사한 출력 형식이 빈번히 사용되고 추후
프로그램 요구 사항에 변경이 있을 경우 손쉽게 변경할 수 있도록 하기
위해 문자열 연결을 이용하도록 PREFIX 를 뽑아낼 수 있다는 뜻입니다.

예를 들어, "0" flag 이외에 다른 flag 를 추가하고자 한다면, 혹은 다른
flag 로 대체하거나, 단순히 zero flag 를 제거하고자 할 때

#define PREFIX ""     /* no flag */
#define PREFIX "-0"   /* left-justified and zero filling */
#define PREFIX "+"    /* always have the sign */

등으로 수정이 용이해집니다.

> 그러므로,
>
> printf("%0*d", AA, 1 );
> 또는
>

flag 를 변경할 일이 없다면 그렇습니다. 하지만, 추후 변경해야 한다면
어떻게 하시겠습니까? "0*d" 를 손수 검색해 일일이 변경하시겠습니까? 원
질문자가 애초에 0 을 매크로 AA 에 넣었고 또 이를 (문자열로서) printf
시에 반영되도록 원했기 때문에 flag 에 대해서도 제어가 필요하다고
판단해 드린 답변입니다.

> printf("%#0*i", AA, 1 );
> 가 깔끔하군요.

conversion specifier "i" 는 "d" 와 동일합니다. i 나 d 에 # flag
(alternative form flag) 를 사용하는 것은 "정의되지 않은" 행동입니다.
따라서 잘못된 프로그램 구조입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:
> PREFIX를 별도로 할당하는 것은 의미 없고

??? 의미 있는지 없는지는 상황에 따라 달라집니다.


상황은 판단하기 나름이겠지만 질문자의 요구사항을 봤을 때 그렇다는 것입니다.

Quote:
> 오히려 0이 아닌 다른 값을 넣어도 된다는 의미로
> 해석될 수 있으므로 오류를 유도하게 됩니다.

??? zero flag 가 아닌 다른 flag 를 넣기 위해서 PREFIX 라는 매크로로
뽑아낸 것입니다. 즉, code 내에 유사한 출력 형식이 빈번히 사용되고 추후
프로그램 요구 사항에 변경이 있을 경우 손쉽게 변경할 수 있도록 하기
위해 문자열 연결을 이용하도록 PREFIX 를 뽑아낼 수 있다는 뜻입니다.

예를 들어, "0" flag 이외에 다른 flag 를 추가하고자 한다면, 혹은 다른
flag 로 대체하거나, 단순히 zero flag 를 제거하고자 할 때

#define PREFIX "" /* no flag */
#define PREFIX "-0" /* left-justified and zero filling */
#define PREFIX "+" /* always have the sign */

등으로 수정이 용이해집니다.


네 물론 플래그를 전역적으로 수정하기를 원한다면 당연히 그럴 수 있습니다.
PREFIX라는 이름 보다는 FORMAT/CONVERSION_FLAG 같은 이름이 더 적절하다고 생각하지만요.
애초에 질문자가 "+"와 같은 플래그를 추후 사용할 생각이였다면 "04"라고 했겠죠.

Quote:
> 그러므로,
>
> printf("%0*d", AA, 1 );
> 또는
>

flag 를 변경할 일이 없다면 그렇습니다. 하지만, 추후 변경해야 한다면
어떻게 하시겠습니까? "0*d" 를 손수 검색해 일일이 변경하시겠습니까? 원
질문자가 애초에 0 을 매크로 AA 에 넣었고 또 이를 (문자열로서) printf
시에 반영되도록 원했기 때문에 flag 에 대해서도 제어가 필요하다고
판단해 드린 답변입니다.

변경할 일이 있다고 해도 전 그런 식으로 하고 싶지는 않습니다.
포맷의 flag를 전역적으로 define해서 쓰는 것은 너무 제한적이기 때문입니다.
나중에 PREFIX를 보고 허용된 값이 무엇인지 생각해서 바꾸어야 하고(물론 좀
더 현명하게 주석을 달 수 있겠죠.) double형을 추가 적으로 고려한다면 또
새로운 매크로를 넣어야 합니다. 그렇게 하는니 별도 함수로 빼겠습니다.

Quote:
> printf("%#0*i", AA, 1 );
> 가 깔끔하군요.

conversion specifier "i" 는 "d" 와 동일합니다. i 나 d 에 # flag
(alternative form flag) 를 사용하는 것은 "정의되지 않은" 행동입니다.
따라서 잘못된 프로그램 구조입니다.


i는 나중에 소개됐고 동일한 것은 알고 있습니다.
'#'은 동작을 체크하면서 불필요하게 추가됐는데 7.19.6.1에 의하면 "정의되지
않은 행동"임이 분명합니다. 그런데 표준에서 정의되지 않은 행동이라고 해서
잘못된 프로그램 구조이다라고 결론을 내린 근거는 무엇인지요?
전웅의 이미지

> 상황은 판단하기 나름이겠지만 질문자의 요구사항을 봤을 때 그렇다는 것입니다.
>

님이 원 질문자가 아닌 이상 님 역시 추측, 저 역시 추측일 뿐입니다. 제가
드린 답변에 대해 제가 내린 추측의 근거를 언급했음에도 이를 제대로 보지
않으신듯 합니다 - 상대방의 논지를 올바르게 이해하는 것이 올바른 토론의
시작점입니다.

자세히 설명드리면, 원 질문자는 4 가 아닌 (진수는 달라도 결국 동일한
값인) 04 를 매크로로 정의했고, 무명님의 %*d 를 사용한 답변에 대해
"공백"이 출력됨을 언급하며 해당 매크로(04) 전체를 문자열로 만들어 삽입
할 수 있는 방법은 없는지 물었습니다.

이것이 제가 원 질문자가 zero flag 에 대해서도 매크로로 처리길 원한다는
가정을 하게 된 근거이며, 이는 이전 글에서도 밝혔습니다:

제가 씀:
] 질문에 zero flag 가 AA 에 포함된
] 것으로 보아 flag 를 매크로를 통해 수정할 필요가 있다고 가정할 때,

> 네 물론 플래그를 전역적으로 수정하기를 원한다면 당연히 그럴 수 있습니다.
> PREFIX라는 이름 보다는 FORMAT/CONVERSION_FLAG 같은 이름이 더 적절하다고 생각하지만요.

ㅋㅋ AA 라는 이름은 맘에 드시나요? str, xstr 은 어떤지요? 이름은
스타일 문제이고, 지금 질문의 요지는 "바람직한 매크로 이름"에 대한 것이
아닙니다. 주제를 흐리지 말아주시기 바랍니다.

> 애초에 질문자가 "+"와 같은 플래그를 추후 사용할 생각이였다면 "04"라고 했겠죠.

질문자의 질문 - 익명님의 답변 - 질문자의 답변을 차례로 보시기
바랍니다. 애초에 AA 를 04 로 정의하고 있었고 그 내용을 그대로 format
string 에 문자열로 반영하고자 하는 의도를 확인할 수 있습니다. 보이지
않는 걸 보시라고 요구하지는 않겠습니다. 보이는 것만은 제대로 보아
주시길 부탁드립니다.

> 변경할 일이 있다고 해도 전 그런 식으로 하고 싶지는 않습니다.
> 포맷의 flag를 전역적으로 define해서 쓰는 것은 너무 제한적이기 때문입니다.
> 나중에 PREFIX를 보고 허용된 값이 무엇인지 생각해서 바꾸어야 하고(물론 좀
> 더 현명하게 주석을 달 수 있겠죠.) double형을 추가 적으로 고려한다면 또
> 새로운 매크로를 넣어야 합니다. 그렇게 하는니 별도 함수로 빼겠습니다.

프로그램에 magic number 를 매크로로 묶어 내는 것도 맘에 들지 않으시는
지요? --; 프로그램 내의 모든 %d 에 동일한 PREFIX 를 적용하자는 의도가
아닙니다. 특정 목적의 printf 문이 반복해 사용되고 추후 그런 printf
문에 대해서만 출력 형식(flag, width)을 바꾸고자 할 때 매크로로 묶어낼
수 있다는 뜻입니다. format string 전체를 매크로로 묶어내는 것도
가능하겠지만 원 질문자는 무슨 이유에서인지 flag 와 field width 만을
묶어내 처리하길 원하고 있었고, 전 그에 대한 답을 드린 것입니다. 그런
상황에서 double 출력 문제가 언급될 이유가 없습니다.

물론, (debug 출력에 종종 사용하듯이) 동일 목적의 출력문을 별도 함수로
추려내는 것도 가능합니다. 하지만 원 질문자가 왜 flag 와 field width 만
을 매크로로 뽑아내려 했는지 문제 상황을 완전히 알지 못하는 상황에서
함수로 뽑아내는 방법을 추천할 수 있지는 못합니다.

다시 한번 말씀드리지만, 문제를 자기 입맛대로 바꿀 수 있다면 답변은
아무나 할 수 있습니다.

> i는 나중에 소개됐고 동일한 것은 알고 있습니다.
> '#'은 동작을 체크하면서 불필요하게 추가됐는데 7.19.6.1에 의하면 "정의되지
> 않은 행동"임이 분명합니다. 그런데 표준에서 정의되지 않은 행동이라고 해서
> 잘못된 프로그램 구조이다라고 결론을 내린 근거는 무엇인지요?

제가 말씀드린 이후 표준의 어느 부분에서 %#i 를 정의되지 않은 행동으로
기술하고 있는지는 찾았지만, 표준을 잘 아시지는 못해 정의되지 않은 행동
이 왜 잘못된 프로그램 구조가 될 수 있는지는 모르시겠다는 뜻이지요?
비유로 말씀드리면,

술 마시고 운전했으나 음주운전으로 기소되는 근거는 모르겠다.
물건은 훔쳤으나 절도로 기소되는 근거는 모르겠다.
칼은 휘둘렀으나 살인 미수로 기소되는 근거는 모르겠다.
정의되지 않은 행동을 일으켰으나 프로그램이 잘못되었다는 근거는 모르겠다.

모두 같은 부류의 주장입니다. 보다 명시적이고 분명한 근거를 원하시나요?
3절의 behavior 밑의 undefined behavior 의 정의를 보시기 바랍니다.

모르는 것은 잘못이 아닙니다. 하지만, 언젠가부터 자신이 모르는 바를
질문하는 상황에서도 솔직히 거부감이 들 정도로 당당한 분들이 있습니다.
모두 저 같을 순 없겠지만, 전 최소한 제가 무언가를 남에게 물어 배우는
입장이라면 이런 식으로 따지듯 글을 쓰진 못할 것 같습니다. 묻고 답하는
관계에서 답변하는 사람이 좀 더 기분 좋게 성의껏 답변을 달 수 있도록
질문자가 배려하는 것도 중요하지 않을까요? 결국 아쉬운 건 질문하는 사람
이지 답변하는 사람이 아닙니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:
> 상황은 판단하기 나름이겠지만 질문자의 요구사항을 봤을 때 그렇다는 것입니다.
>

님이 원 질문자가 아닌 이상 님 역시 추측, 저 역시 추측일 뿐입니다. 제가
드린 답변에 대해 제가 내린 추측의 근거를 언급했음에도 이를 제대로 보지
않으신듯 합니다 - 상대방의 논지를 올바르게 이해하는 것이 올바른 토론의
시작점입니다.

자세히 설명드리면, 원 질문자는 4 가 아닌 (진수는 달라도 결국 동일한
값인) 04 를 매크로로 정의했고, 무명님의 %*d 를 사용한 답변에 대해
"공백"이 출력됨을 언급하며 해당 매크로(04) 전체를 문자열로 만들어 삽입
할 수 있는 방법은 없는지 물었습니다.

이것이 제가 원 질문자가 zero flag 에 대해서도 매크로로 처리길 원한다는
가정을 하게 된 근거이며, 이는 이전 글에서도 밝혔습니다:


그런 가정으로 답변할 수 있고 제 추측이 틀렸을 수 있습니다.
Quote:

제가 씀:
] 질문에 zero flag 가 AA 에 포함된
] 것으로 보아 flag 를 매크로를 통해 수정할 필요가 있다고 가정할 때,

> 네 물론 플래그를 전역적으로 수정하기를 원한다면 당연히 그럴 수 있습니다.
> PREFIX라는 이름 보다는 FORMAT/CONVERSION_FLAG 같은 이름이 더 적절하다고 생각하지만요.

ㅋㅋ AA 라는 이름은 맘에 드시나요? str, xstr 은 어떤지요? 이름은
스타일 문제이고, 지금 질문의 요지는 "바람직한 매크로 이름"에 대한 것이
아닙니다. 주제를 흐리지 말아주시기 바랍니다.


기술적인 내용에 집중해시기 바랍니다.
개념을 간단히 설명하는 예제로서 AA는 적절하고 STR, XSTR(소문자가 아니고 대문자임을 주목하세요!)
또한 적절합니다. 이미 말씀 드렸듯이 플래그를 분리하는 답변으로 PREFIX는 적절한 이름이 아닙니다.
"바람직한 매크로 이름"에 관한 것이 아니라는데는 동의합니다. 저 역시 이것이 주제라고 한 적이 없습니다.

Quote:
> 애초에 질문자가 "+"와 같은 플래그를 추후 사용할 생각이였다면 "04"라고 했겠죠.

질문자의 질문 - 익명님의 답변 - 질문자의 답변을 차례로 보시기
바랍니다. 애초에 AA 를 04 로 정의하고 있었고 그 내용을 그대로 format
string 에 문자열로 반영하고자 하는 의도를 확인할 수 있습니다. 보이지
않는 걸 보시라고 요구하지는 않겠습니다. 보이는 것만은 제대로 보아
주시길 부탁드립니다.


애초에 AA를 (04)로 정의했습니다. 그대로 반영하고 싶었다는 의도에 동의합니다.
이 의도에 가장 충실한 것은 puaxx님이 답변이라고 생각합니다만, 추측없이 좀 엄격히 해석하면,
AA정의를 변경하지 않고 원하는 결과를 나오는 가장 깔씀한 것이 어떤 것이라는 것인지 알 것입니다.

Quote:
문제의 조건을 임의로 바꾸면 아무나 답변할 수 있습니다. ;-)

사실 제가 느낀 문제의 시작은 여기에 있습니다.
puaxx님의 답변은 그대로 반영하고 싶었다는 의도를 잘 살린 것이였습니다.
그런데 전웅님도 조건을 바꾸면서 적절한 답변을 한 사람을 "아무나"로 치부한 것입니다.
Quote:

> 변경할 일이 있다고 해도 전 그런 식으로 하고 싶지는 않습니다.
> 포맷의 flag를 전역적으로 define해서 쓰는 것은 너무 제한적이기 때문입니다.
> 나중에 PREFIX를 보고 허용된 값이 무엇인지 생각해서 바꾸어야 하고(물론 좀
> 더 현명하게 주석을 달 수 있겠죠.) double형을 추가 적으로 고려한다면 또
> 새로운 매크로를 넣어야 합니다. 그렇게 하는니 별도 함수로 빼겠습니다.

프로그램에 magic number 를 매크로로 묶어 내는 것도 맘에 들지 않으시는
지요? --; 프로그램 내의 모든 %d 에 동일한 PREFIX 를 적용하자는 의도가
아닙니다. 특정 목적의 printf 문이 반복해 사용되고 추후 그런 printf
문에 대해서만 출력 형식(flag, width)을 바꾸고자 할 때 매크로로 묶어낼
수 있다는 뜻입니다. format string 전체를 매크로로 묶어내는 것도
가능하겠지만 원 질문자는 무슨 이유에서인지 flag 와 field width 만을
묶어내 처리하길 원하고 있었고, 전 그에 대한 답을 드린 것입니다. 그런
상황에서 double 출력 문제가 언급될 이유가 없습니다.


특정 목적으로 사용할 경우도 마찬가지입니다. 포맷이 다를 경우 define하고
undefine하는 반복적인 상황이 생길 가능성이 높습니다. 물론 스타일의 문제지만
보통 매크로를 헤더에 두는 상황에서 더욱 맞지 않습니다.
Quote:

물론, (debug 출력에 종종 사용하듯이) 동일 목적의 출력문을 별도 함수로
추려내는 것도 가능합니다. 하지만 원 질문자가 왜 flag 와 field width 만
을 매크로로 뽑아내려 했는지 문제 상황을 완전히 알지 못하는 상황에서
함수로 뽑아내는 방법을 추천할 수 있지는 못합니다.

전 이 상황에도 추천했을 뿐입니다. 질문자의 의도를 알지 못하는 상황에서는
예제 코드에 정확히 부합하는 결과가 우선이겠지요.

Quote:
다시 한번 말씀드리지만, 문제를 자기 입맛대로 바꿀 수 있다면 답변은
아무나 할 수 있습니다.

동의하지 않습니다. 결과에 부합한다면 좀 더 창의적인 해결책이 나올 수 있습니다.
지금까지 바꾼 조건이 결코 문제를 자기 입맛대로 바꿨다고 말할 정도로 동떨어졌다고
생각하지 않습니다.

Quote:
> i는 나중에 소개됐고 동일한 것은 알고 있습니다.
> '#'은 동작을 체크하면서 불필요하게 추가됐는데 7.19.6.1에 의하면 "정의되지
> 않은 행동"임이 분명합니다. 그런데 표준에서 정의되지 않은 행동이라고 해서
> 잘못된 프로그램 구조이다라고 결론을 내린 근거는 무엇인지요?

제가 말씀드린 이후 표준의 어느 부분에서 %#i 를 정의되지 않은 행동으로
기술하고 있는지는 찾았지만, 표준을 잘 아시지는 못해 정의되지 않은 행동
이 왜 잘못된 프로그램 구조가 될 수 있는지는 모르시겠다는 뜻이지요?
비유로 말씀드리면,


그렇지 않습니다. 제 의도는 표준 해석과 프로그램 구조가 직결되는 전웅님의
사고의 근거가 무엇인지 기술적인 이유가 듣고 싶어서입니다.
예를 든다면, 프로그램 요구사항에 무슨 플랫폼에서 이런 포맷으로 출력될 것을
지킨 프로그램이 잘못된 프로그램 구조로 얘기할 수 있냐는 것입니다.
이건 표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조로 결론
날 수 있는 사항입니다. 요구사항에 표준과 관련 내용이 있다면 물론 다른 문제겠죠.
그리고 제가 누구에게 표준에 관해 설명한다면 레퍼런스를 다는 것이 상식이기에
그렇게 했을 뿐입니다.

Quote:
술 마시고 운전했으나 음주운전으로 기소되는 근거는 모르겠다.
물건은 훔쳤으나 절도로 기소되는 근거는 모르겠다.
칼은 휘둘렀으나 살인 미수로 기소되는 근거는 모르겠다.
정의되지 않은 행동을 일으켰으나 프로그램이 잘못되었다는 근거는 모르겠다.

아주 최악의 예입니다.
이건 어떨까요?
오늘 사과를 땄는데 어제께 낯선 벌레가 앉았다는 제보가 있어 폐기 처분했다.

Quote:

모두 같은 부류의 주장입니다. 보다 명시적이고 분명한 근거를 원하시나요?
3절의 behavior 밑의 undefined behavior 의 정의를 보시기 바랍니다.

위해서 설명했듯이 질문의 의도에 맞게 답을 하시기 바랍니다.
전 여전히 표준과 프로그램 구조와 관련된 건설적인 답변을 기대하고 있습니다.

Quote:
모르는 것은 잘못이 아닙니다. 하지만, 언젠가부터 자신이 모르는 바를
질문하는 상황에서도 솔직히 거부감이 들 정도로 당당한 분들이 있습니다.
모두 저 같을 순 없겠지만, 전 최소한 제가 무언가를 남에게 물어 배우는
입장이라면 이런 식으로 따지듯 글을 쓰진 못할 것 같습니다. 묻고 답하는
관계에서 답변하는 사람이 좀 더 기분 좋게 성의껏 답변을 달 수 있도록
질문자가 배려하는 것도 중요하지 않을까요? 결국 아쉬운 건 질문하는 사람
이지 답변하는 사람이 아닙니다.

따질려고 물어본 것이 아닙니다. 답변을 하고 싶지 않으면 하지 않으셔도 됩니다.
단지, 표준 규정에 근거해서 "정의되지 않은 행동"이다라고 했으면 그 뿐입니다.
잘못된 프로그램 구조라고 말하기엔 비약이 있다고 생각했기에 그 근거가 궁금했을
뿐입니다. 이것은 다른 주제이기 별도의 장을 열 필요가 있겠군요.
전웅의 이미지

> > ㅋㅋ AA 라는 이름은 맘에 드시나요? str, xstr 은 어떤지요? 이름은
> > 스타일 문제이고, 지금 질문의 요지는 "바람직한 매크로 이름"에 대한 것이
> > 아닙니다. 주제를 흐리지 말아주시기 바랍니다.
>
> 기술적인 내용에 집중해시기 바랍니다.
> 개념을 간단히 설명하는 예제로서 AA는 적절하고 STR, XSTR(소문자가 아니고 대문자임을 주목하세요!)
> 또한 적절합니다. 이미 말씀 드렸듯이 플래그를 분리하는 답변으로 PREFIX는 적절한 이름이 아닙니다.
> "바람직한 매크로 이름"에 관한 것이 아니라는데는 동의합니다. 저 역시 이것이 주제라고 한 적이 없습니다.
>

저 위 답변에 기술적이지 않은 내용이 있는지요? "개념을 간단히 설명하는
예제"로 AA 가 적당하다면, flag 를 묶어내는 "개념을 간단히 설명하는
예제"로 PREFIX 가 적당하지 못할 이유는 또 무엇인지 궁금하군요. #, 0, +
같은 것들이 정확히는 flag 라는 이름을 가지고 있고, printf 에 주어지는
첫번째 인자 "전체"를 format string 이라고 부름에도, 저로서는 님이 제안
하신 FORMAT 이 적당한 이유도 모르겠군요. 제가 이전 글에서 flag 를 묶어
내기 위한 매크로의 이름으로는 반드시 PREFIX 를 사용해야 한다고 주장한
부분이 있던가요? 어떤 분은 PREFIX 가 맘에 들테고, 다른 분은 FORMAT 이
맘에 들테고, 또 다른 분은 둘 다 맘에 들지 않을 테고, 결국 논의의 핵심
은 방법론을 설명하는 것이므로, 원 저작자나 글 읽는 분들이 자기 사정에
맞는 이름을 선택 혹은 창작해 사용하면 그만입니다.

또한, 참고로 str, xstr 이라는 이름은 제 창작이 아니라 # 연산자를
사용한 예에 "관례적으로" 사용되는 이름입니다. 이 글타래에서 누구나
그러하듯, 제가 전달하고자 하는 것은 세부적인 코드가 아니라 접근 방법
입니다. 남이 하면 개념을 설명하는 예제에 불과하고, 제가 하면 특정
스타일을 포함한 코드 자체를 강요하는 것인지요? 제가 main() 함수에
중괄호를 쓴 스타일, 들여쓰기에 공백을 사용한 개수는 따로 지적이 없는
걸 보니 마음에 드시나 보군요. :-(

지금까지 이런 저런 주제에서 다양한 주장을 보아왔지만 이런 식의 억지
주장은 또 새롭군요.

> 애초에 AA를 (04)로 정의했습니다. 그대로 반영하고 싶었다는 의도에 동의합니다.
> 이 의도에 가장 충실한 것은 puaxx님이 답변이라고 생각합니다만, 추측없이 좀 엄격히 해석하면,
> AA정의를 변경하지 않고 원하는 결과를 나오는 가장 깔씀한 것이 어떤 것이라는 것인지 알 것입니다.

원 질문자의 (04) 를 놓고 제가 수정한 것은 괄호를 없애 04 로 만든
것이고, puaxx 님은 이를 문자열로 고쳐 "04" 로 만들었습니다.

제 답변의 가정은 원 질문자가

- AA 매크로를 정수 상수로 둔다
- AA 매크로에 zero flag 를 포함시킨다

라는 생각을 하고, 단지 매크로는 전체 치환 리스트를 괄호로 둘러싸는 것
이 바람직하다는 일반적 스타일을 AA 에도 적용한 것이라 본 것입니다.
반면, puaxx 님의 답변은 원 질문자의 의도 중 아래 것만을 만족하고
있습니다. 이것이 제가 puaxx 님의 답변에서 원 질문자의 의도가 그대로
반영되지 않았다고 판단한 근거입니다. 답변은 질문자의 질문 속에서
이루어지는 것이지, 답변자의 임의적 판단 속에 이루어지는 것이 아닙니다.
만역, puaxx 님이 "만약 AA 매크로의 내용을 문자열로 변경해도
무방하다면" 정도의 단서를 다셨다면 그 아래 이어지는 제 답변도 없었을
것입니다.

> > 문제의 조건을 임의로 바꾸면 아무나 답변할 수 있습니다. ;-)
>
> 사실 제가 느낀 문제의 시작은 여기에 있습니다.
> puaxx님의 답변은 그대로 반영하고 싶었다는 의도를 잘 살린 것이였습니다.
> 그런데 전웅님도 조건을 바꾸면서 적절한 답변을 한 사람을 "아무나"로 치부한 것입니다.

위에서 설명했습니다.

> > [flag, field width 를 매크로로 묶어내는 이야기]
>
> 특정 목적으로 사용할 경우도 마찬가지입니다. 포맷이 다를 경우 define하고
> undefine하는 반복적인 상황이 생길 가능성이 높습니다. 물론 스타일의 문제지만
> 보통 매크로를 헤더에 두는 상황에서 더욱 맞지 않습니다.

매크로는 목적에 따라 헤더에 두기도, 특정 파일 상단부에 두기도, 심지어
는 특정 함수의 시작부에 두고 그 끝에 #undef 해주기도 합니다. magic
value 를 매크로로 뽑아내기 여부는 본인 스스로 스타일의 문제라고
단정하면서 어느 것이 더 "맞고" 더 "틀리고"를 함께 주장하는 게 뭔가
어불성설이라는 생각이 들지는 않으시는지요?

> > 다시 한번 말씀드리지만, 문제를 자기 입맛대로 바꿀 수 있다면 답변은
> > 아무나 할 수 있습니다.
>
> 동의하지 않습니다. 결과에 부합한다면 좀 더 창의적인 해결책이 나올 수 있습니다.
> 지금까지 바꾼 조건이 결코 문제를 자기 입맛대로 바꿨다고 말할 정도로 동떨어졌다고
> 생각하지 않습니다.

--;;; 그래서 지금 상황에서 더 창의적인 해결책이 나왔습니까? 글 쓴
순서로 볼 때 익명님(field width *)이나 제가 드린 답변(# 연산자와 인접
문자열 연결)에 사용되지 않은 전혀 "새로운" 기술을 사용해 보인 답변이
있습니까? (아, 하나 있군요. 표준이 잘못된 구조로 규정하고 있는 # 를
사용한 코드 :-) 억지 주장은 그만 하시고 그 창의적인 해결책 구경이나
해보고 싶습니다.

> 그렇지 않습니다. 제 의도는 표준 해석과 프로그램 구조가 직결되는 전웅님의
> 사고의 근거가 무엇인지 기술적인 이유가 듣고 싶어서입니다.
>

모르면 모른다고 차라리 솔직히 말씀을 하시고 답변을 구하십시오.
undefined behavior 를 일으키는 것 자체가 잘못된 프로그램 구조입니다.
제가 인용해드린 정의를 보시면 나와 있는 내용입니다. 아니면 인터넷 상에
undefined behavior/unspecified behavior/implementation-defined
behavior 에 대해 설명하는 기사나 C 관련 뉴스 그룹에서 "undefined
behavior" 와 "incorrect construct(ion)" 혹은 "invalid construct(ion)"
정도를 함께 검색해 보시기 바랍니다.

만약 님께서 표준을 조금이라도 공부해 보셨다면 제일 먼저 알게 되는
(혹은 알아야 하는) 사실임에도 불구하고, "자신도 다 알고는 있으나 표준
해석과 프로그램 구조가 직결되는 사고의 근거를 못 찾겠다" 고 주장하시는
모습이 안쓰럽기까지 합니다. 모르는 것은 죄가 아닙니다. 아는 척하며
잘못된 주장을 하는 것은 (최소한 도의적인 수준의) 죄가 될 수 있습니다.

> 예를 든다면, 프로그램 요구사항에 무슨 플랫폼에서 이런 포맷으로 출력될 것을
> 지킨 프로그램이 잘못된 프로그램 구조로 얘기할 수 있냐는 것입니다.
> 이건 표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조로 결론
> 날 수 있는 사항입니다. 요구사항에 표준과 관련 내용이 있다면 물론 다른 문제겠죠.

별별 개념을 다 끌고 오시는군요. 질문에 특정 환경이 명시되지 않으면
모든 환경에서 동일한 결론을 얻을 수 있는 표준을 두고 논하는 것이 일반
입니다. 기본 개념도 갖추지 못한 상태로 확장 운운 하시는데, 그럼 %#0*i
에서 대체 무엇을 의도하고 # 를 넣으셨는지요? 원 질문자의 질문에 부합
하기 위해 # 가 대체 어떤 역할을 하고 있습니까? (특정 환경이 d 나 i 에
# 를 확장으로 지원한다고 해도) 원 질문자의 환경에 대한 정보도 없이 #
를 넣고 그 역할에 대한 설명도 없는 것은 또 어떻게 해석할 수 있을까요?
차라리 실수로 넣었으니 정정하겠다고 하시는 편이 누가 보기에도 편안해
보입니다.

> > 모두 같은 부류의 주장입니다. 보다 명시적이고 분명한 근거를 원하시나요?
> > 3절의 behavior 밑의 undefined behavior 의 정의를 보시기 바랍니다.
>
> 위해서 설명했듯이 질문의 의도에 맞게 답을 하시기 바랍니다.
> 전 여전히 표준과 프로그램 구조와 관련된 건설적인 답변을 기대하고 있습니다.

답변을 기대한다고 해놓고선 밑에선 답변하기 싫으면 하지 말라
하시는군요. :-) 하지 않겠습니다. 스스로 깨닫든, 다른 분께 답을 얻든
알아서 하십시오. 더 이상 잘못된 주장으로 이유 없이 당당한 분들께 지식
전달하느라 제 아까운 시간 낭비하기 싫습니다.

> 따질려고 물어본 것이 아닙니다. 답변을 하고 싶지 않으면 하지 않으셔도 됩니다.
> 단지, 표준 규정에 근거해서 "정의되지 않은 행동"이다라고 했으면 그 뿐입니다.
> 잘못된 프로그램 구조라고 말하기엔 비약이 있다고 생각했기에 그 근거가 궁금했을
> 뿐입니다. 이것은 다른 주제이기 별도의 장을 열 필요가 있겠군요.

별도의 장을 열 필요도 없는 주제입니다. "표준과 확장", "undefined
behavior", "incorrect/invalid construct" 에 대한 개념을 제대로
파악하고 계시지 못한다면 혼자 공부하시거나 질문을 하실 문제이지, 님의
잘못된 개념 파악으로 다른 분들 시간까지 낭비하게 만들 주제를 위해 새로
토론을 시작할 문제가 아닙니다.

예전 w**h 님과의 소비적인 논의에서 얻은 바가 있어 이 글타래에는 더
이상 답을 달지 않겠습니다 - 단, 누구든 추가 "질문"에 대해서만 답변
드릴 용의가 있습니다.

요즘 들어 여러 이유로 KLDP 가 예전같지 않은 것 같습니다. 죄송스런
말씀이지만 안타깝게도 hclc 마냥 이제 이곳도 발길을 끊을 때가 된 것
같습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

bootmeta의 이미지

"문제의 조건을 임의로 바꾸면 아무나 답변할 수 있습니다. ;-)"라는 문구나 "ㅋㅋ"라는 문구를 쓰기 시작하면서 글타래는 이미 토의의 단계를 지났습니다.
제가 보기에 전웅님이 엄격하게 해석한 것과 달리 다른 분이 조건을 엄격하지 않게 적용했다고 해서 틀린 것이 아닙니다.
도리어 저 같이 C를 잘 알지 못하는 입장에서 당장 필요한 내용만 적용한 다른 분의 의견이 더 와닿습니다.
설사 님의 주장이 100% 정답이고 해답본이라고 할지라도 빈정되는 것을 정당화 시킬 수 없습니다.
인격과 지식은 별개라는 사실이 다시 한번 와 닿는군요.
참고로 위에 글 쓴 익명 분들과 저는 관계 없습니다.

익명 사용자의 이미지

애써 길게 설명해주니 나오는 반응이 매번 이런거라니 참...
전웅님 앞으로는 KLDP에서 활동하지 마시기를 바랍니다.
이런 놈들에겐 님의 글이 아깝습니다.
차라리 그시간에 책을 쓰셨으면
양질의 저서가 3권은 더 나왔을 텐데요.

가끔 손이 근질거리시더라도
절대 손수 글을 쓰지 마시고
그냥 csc 또는 clc에 있는 글에 링크 걸어버리시길.

이런 잡놈들에겐 시간과 노력이 아깝습니다.

경의 이미지

Quote:
> > ㅋㅋ AA 라는 이름은 맘에 드시나요? str, xstr 은 어떤지요? 이름은경
> > 스타일 문제이고, 지금 질문의 요지는 "바람직한 매크로 이름"에 대한 것이
> > 아닙니다. 주제를 흐리지 말아주시기 바랍니다.
>
> 기술적인 내용에 집중해시기 바랍니다.
> 개념을 간단히 설명하는 예제로서 AA는 적절하고 STR, XSTR(소문자가 아니고 대문자임을 주목하세요!)
> 또한 적절합니다. 이미 말씀 드렸듯이 플래그를 분리하는 답변으로 PREFIX는 적절한 이름이 아닙니다.
> "바람직한 매크로 이름"에 관한 것이 아니라는데는 동의합니다. 저 역시 이것이 주제라고 한 적이 없습니다.
>

저 위 답변에 기술적이지 않은 내용이 있는지요?


"주제를 흐리지 말아주시기 바랍니다"라는 말로 마치 전혀 주제와 관련 없는 듯 호도하고 있습니다.
"더 적절하다고 생각하지만요"라고 말한 것이 주제로 뽑힐 문맥도 아니지만 예로 든 코드가 제한된 확장이며
오류를 유도할 수 있다는 의미의 제 얘기가 왜 주제에 벗어났다고 하는 것인지요.

Quote:

"개념을 간단히 설명하는
예제"로 AA 가 적당하다면, flag 를 묶어내는 "개념을 간단히 설명하는
예제"로 PREFIX 가 적당하지 못할 이유는 또 무엇인지 궁금하군요.

AA는 단순히 치환의 의미로 들어갔지만 PREFIX는 선택적인 flag를 나타내는 제한된
의미로 사용됐습니다. 일반적으로 PREFIX라고 이름을 볼 때 그런 것을 예상하지
않기 때문에 지적한 것입니다.

Quote:

#, 0, +
같은 것들이 정확히는 flag 라는 이름을 가지고 있고, printf 에 주어지는
첫번째 인자 "전체"를 format string 이라고 부름에도, 저로서는 님이 제안
하신 FORMAT 이 적당한 이유도 모르겠군요. 제가 이전 글에서 flag 를 묶어
내기 위한 매크로의 이름으로는 반드시 PREFIX 를 사용해야 한다고 주장한
부분이 있던가요? 어떤 분은 PREFIX 가 맘에 들테고, 다른 분은 FORMAT 이
맘에 들테고, 또 다른 분은 둘 다 맘에 들지 않을 테고, 결국 논의의 핵심
은 방법론을 설명하는 것이므로, 원 저작자나 글 읽는 분들이 자기 사정에
맞는 이름을 선택 혹은 창작해 사용하면 그만입니다.

FORMAT_FLAG 또는 CONVERSION_FLAG라는 의미였습니다. 플래그를 분리하는
방법이 제한적이다라는 것이 핵심입니다. 자기 사정에 맞게 쓰도록 두면 되지라는
생각을 다른 답변자의 입장에서도 했으면 합니다.

Quote:

또한, 참고로 str, xstr 이라는 이름은 제 창작이 아니라 # 연산자를
사용한 예에 "관례적으로" 사용되는 이름입니다. 이 글타래에서 누구나
그러하듯, 제가 전달하고자 하는 것은 세부적인 코드가 아니라 접근 방법
입니다. 남이 하면 개념을 설명하는 예제에 불과하고, 제가 하면 특정
스타일을 포함한 코드 자체를 강요하는 것인지요? 제가 main() 함수에
중괄호를 쓴 스타일, 들여쓰기에 공백을 사용한 개수는 따로 지적이 없는
걸 보니 마음에 드시나 보군요. :-(

창작이 아니란 것과 관례적으로 쓰인다는 것을 잘 알고 있습니다. 이것이 좋은 방법이
아니지만 의미가 분명한 이름도 있다고 한 것입니다. 개념을 설명한 예제로서 인정하지
않하고 할 필요가 없습니다. 누가 강요한다고 했습니까? 더 나은 접근이 아닐까 제안한
것입니다. 마치 내 것만 인정 받아야겠다는 소리로밖에 안 들립니다.

Quote:

지금까지 이런 저런 주제에서 다양한 주장을 보아왔지만 이런 식의 억지
주장은 또 새롭군요.

억지 주장이라면 논리를 전개하기 더욱 쉽겠군요. 공백의 갯수나 언급하고 또 다른 관련없는
경우로 주제를 흐리지 마시기 바랍니다.

Quote:

> 애초에 AA를 (04)로 정의했습니다. 그대로 반영하고 싶었다는 의도에 동의합니다.
> 이 의도에 가장 충실한 것은 puaxx님이 답변이라고 생각합니다만, 추측없이 좀 엄격히 해석하면,
> AA정의를 변경하지 않고 원하는 결과를 나오는 가장 깔씀한 것이 어떤 것이라는 것인지 알 것입니다.

원 질문자의 (04) 를 놓고 제가 수정한 것은 괄호를 없애 04 로 만든
것이고, puaxx 님은 이를 문자열로 고쳐 "04" 로 만들었습니다.

제 답변의 가정은 원 질문자가

- AA 매크로를 정수 상수로 둔다
- AA 매크로에 zero flag 를 포함시킨다

라는 생각을 하고, 단지 매크로는 전체 치환 리스트를 괄호로 둘러싸는 것
이 바람직하다는 일반적 스타일을 AA 에도 적용한 것이라 본 것입니다.
반면, puaxx 님의 답변은 원 질문자의 의도 중 아래 것만을 만족하고
있습니다. 이것이 제가 puaxx 님의 답변에서 원 질문자의 의도가 그대로
반영되지 않았다고 판단한 근거입니다. 답변은 질문자의 질문 속에서
이루어지는 것이지, 답변자의 임의적 판단 속에 이루어지는 것이 아닙니다.
만역, puaxx 님이 "만약 AA 매크로의 내용을 문자열로 변경해도
무방하다면" 정도의 단서를 다셨다면 그 아래 이어지는 제 답변도 없었을
것입니다.


그렇게 생각할 수 있습니다. 그러나 문제의 조건을 바꾸었다고 말하는 것은
역시 무리입니다. 코드 속 "04" 의미 자체에 이미 "만약 AA 매크로의 내용을
문자열로 변경해도 무방하다면"이란 의미가 들어가 있습니다.
결국 스스로의 가정을 원 질문자의 의도인양 다른 답변자에게 무리하게 적용한
모양일 뿐입니다.

Quote:

> > [flag, field width 를 매크로로 묶어내는 이야기]
>
> 특정 목적으로 사용할 경우도 마찬가지입니다. 포맷이 다를 경우 define하고
> undefine하는 반복적인 상황이 생길 가능성이 높습니다. 물론 스타일의 문제지만
> 보통 매크로를 헤더에 두는 상황에서 더욱 맞지 않습니다.

매크로는 목적에 따라 헤더에 두기도, 특정 파일 상단부에 두기도, 심지어
는 특정 함수의 시작부에 두고 그 끝에 #undef 해주기도 합니다.


어디에 두냐 문제에서 지금 주장하는 목적으로 쓰이는 경우는 희귀하다고 생각
합니다. 정의에 따라 별도 출력 버젼을 사용하는 것도 아니고 printf의 한
플래그를 undef 하고 define하는 상황을 파일별로 컨트롤 해야 하는 것입니다.
Quote:

magic value 를 매크로로 뽑아내기 여부는 본인 스스로 스타일의 문제라고
단정하면서 어느 것이 더 "맞고" 더 "틀리고"를 함께 주장하는 게 뭔가
어불성설이라는 생각이 들지는 않으시는지요?

무엇이 단정이란 말이죠?
수 많은 주장과 토론을 보며 논지와 전혀 상관없는 이상한 단어를 쓰면 참 도움이
된다고 배우셨습니까?

Quote:

> > 다시 한번 말씀드리지만, 문제를 자기 입맛대로 바꿀 수 있다면 답변은
> > 아무나 할 수 있습니다.
>
> 동의하지 않습니다. 결과에 부합한다면 좀 더 창의적인 해결책이 나올 수 있습니다.
> 지금까지 바꾼 조건이 결코 문제를 자기 입맛대로 바꿨다고 말할 정도로 동떨어졌다고
> 생각하지 않습니다.

--;;; 그래서 지금 상황에서 더 창의적인 해결책이 나왔습니까? 글 쓴
순서로 볼 때 익명님(field width *)이나 제가 드린 답변(# 연산자와 인접
문자열 연결)에 사용되지 않은 전혀 "새로운" 기술을 사용해 보인 답변이
있습니까? (아, 하나 있군요. 표준이 잘못된 구조로 규정하고 있는 # 를
사용한 코드 :-) 억지 주장은 그만 하시고 그 창의적인 해결책 구경이나
해보고 싶습니다.


앞에 언급한 것이 마치 새로운 기술인양 얘기하시는군요. 이 토론에서 꼭 나와야 한다는
뜻이 아닙니다면 이미 undef, define하는 수고를 하는 것이 덜 창의적이고 시간을 많이
소모할 것이라는 아이디어가 나왔다는 것이죠.
'#'은 이미 말했듯이 답변 달려고 테스트하다가 그대로 붙여 넣기 했을 뿐입니다. i도 있다
정도의 의미로 이해하시기 바랍니다. 네 이것이 표준인지 아닌지 몰랐고, 관심도 없었습니다.
평소 결코 쓰지 않는 코드이기에요. 표준이 아니라고 지적해 주신 것에는 고맙게 생각합니다.

Quote:

> 그렇지 않습니다. 제 의도는 표준 해석과 프로그램 구조가 직결되는 전웅님의
> 사고의 근거가 무엇인지 기술적인 이유가 듣고 싶어서입니다.
>

모르면 모른다고 차라리 솔직히 말씀을 하시고 답변을 구하십시오.
undefined behavior 를 일으키는 것 자체가 잘못된 프로그램 구조입니다.
제가 인용해드린 정의를 보시면 나와 있는 내용입니다. 아니면 인터넷 상에
undefined behavior/unspecified behavior/implementation-defined
behavior 에 대해 설명하는 기사나 C 관련 뉴스 그룹에서 "undefined
behavior" 와 "incorrect construct(ion)" 혹은 "invalid construct(ion)"
정도를 함께 검색해 보시기 바랍니다.


제 의도를 여전히 모르시는군요. 현실적으로 잘못된 프로그램 구조가 무엇을 의미하는지
조금 이라도 고민해 보고 말씀하시기 바랍니다. 그리고 표준 안에서 잘못된 프로그램 구조의
정의가 어디에 있는지 알려주시기 바랍니다.

Quote:

> 예를 든다면, 프로그램 요구사항에 무슨 플랫폼에서 이런 포맷으로 출력될 것을
> 지킨 프로그램이 잘못된 프로그램 구조로 얘기할 수 있냐는 것입니다.
> 이건 표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조로 결론
> 날 수 있는 사항입니다. 요구사항에 표준과 관련 내용이 있다면 물론 다른 문제겠죠.

별별 개념을 다 끌고 오시는군요. 질문에 특정 환경이 명시되지 않으면
모든 환경에서 동일한 결론을 얻을 수 있는 표준을 두고 논하는 것이 일반
입니다. 기본 개념도 갖추지 못한 상태로 확장 운운 하시는데, 그럼 %#0*i
에서 대체 무엇을 의도하고 # 를 넣으셨는지요? 원 질문자의 질문에 부합
하기 위해 # 가 대체 어떤 역할을 하고 있습니까? (특정 환경이 d 나 i 에
# 를 확장으로 지원한다고 해도) 원 질문자의 환경에 대한 정보도 없이 #
를 넣고 그 역할에 대한 설명도 없는 것은 또 어떻게 해석할 수 있을까요?
차라리 실수로 넣었으니 정정하겠다고 하시는 편이 누가 보기에도 편안해
보입니다.


표준을 두고 논하는 것이 일반적이라는데 동의합니다. 그래서 표준에서 얘기하는
"잘못된 프로그램의 구조"에 대한 정의가 무엇이란 말인지요?
당연히 알고 넣은 것이 아닙니다. 무슨 얘기를 더 듣고 싶은 것입니까?
'%#0*i'이 표준이 아니라는, 어떤 컴파일러는 기본적으로 알려주는, man 3 printf
하면 바로 알 수 있는, 아주 대단한 지식을 가진 분임을 잘 알겠습니다.

Quote:

> 따질려고 물어본 것이 아닙니다. 답변을 하고 싶지 않으면 하지 않으셔도 됩니다.
> 단지, 표준 규정에 근거해서 "정의되지 않은 행동"이다라고 했으면 그 뿐입니다.
> 잘못된 프로그램 구조라고 말하기엔 비약이 있다고 생각했기에 그 근거가 궁금했을
> 뿐입니다. 이것은 다른 주제이기 별도의 장을 열 필요가 있겠군요.

별도의 장을 열 필요도 없는 주제입니다. "표준과 확장", "undefined
behavior", "incorrect/invalid construct" 에 대한 개념을 제대로
파악하고 계시지 못한다면 혼자 공부하시거나 질문을 하실 문제이지, 님의
잘못된 개념 파악으로 다른 분들 시간까지 낭비하게 만들 주제를 위해 새로
토론을 시작할 문제가 아닙니다.


표준에 부합하는 것과 부합하지 않는 것이 있을 뿐입니다.
잘못된 프로그램 구조의 정의를 표준에 무지한 개발자의 실수로 넣은 출력 포맷 플래그 설정에서
찾는 일이 없기를 바랍니다. 이건 마치 내 발음이 표준이 아니라서 넌 인간이 아니다라고
말하는 것처럼 들리는군요.
전웅의 이미지

[매크로 이름 이야기]

매크로 이름 이야기는 그만 하기로 하겠습니다. 구체적 형태가 아닌 구조
를 전달하려는 예에 대해 (지나가는 이야기일지라도) 형태(매크로 이름)에
대한 반박을 하셨지만, 그 문제(매크로 이름의 명명이 적절한가?)는 이
주제가 다루던 내용이 아니라는 뜻이었습니다. 이 정도 오고갔으면 읽는
분들이 알아서 판단하시리라 믿습니다.

[질문의 임의의 가정을 더했느냐는 문제]

> 그렇게 생각할 수 있습니다. 그러나 문제의 조건을 바꾸었다고 말하는 것은
> 역시 무리입니다. 코드 속 "04" 의미 자체에 이미 "만약 AA 매크로의 내용을
> 문자열로 변경해도 무방하다면"이란 의미가 들어가 있습니다.

교수님이 낸 문제에 제가 임의로 가정을 하여 문제를 풀어놓고도 그 가정
을 따로 적지 않으면 교수님이 알아서 가정을 고려하셔서 채점을
해주시던지요? 이 부분에서의 억지도 이 정도면 충분합니다.

> 결국 스스로의 가정을 원 질문자의 의도인양 다른 답변자에게 무리하게 적용한
> 모양일 뿐입니다.

제 가정은 원 질문자의 질문이 겉으로 보이는 모습에 기반한 것입니다.
그리고 "모든" 답변은 질문자의 질문이 겉으로 보이는 모습을 문제 상황
으로 가정하고 답변이 이루어집니다.

님의 논리적 모순은 이제 끝이 없어 보입니다. 누가 만든 진흙탕이든 님과
함께 뒹굴어봤자 저만 손해라는 생각입니다.

> 어디에 두냐 문제에서 지금 주장하는 목적으로 쓰이는 경우는 희귀하다고 생각
> 합니다. 정의에 따라 별도 출력 버젼을 사용하는 것도 아니고 printf의 한
> 플래그를 undef 하고 define하는 상황을 파일별로 컨트롤 해야 하는 것입니다.

구체적인 예를 들고 싶은 기분도 들지 않습니다. 이해하지 못하시면 그냥
그대로 살아 가시면 됩니다. 님과 함께 일 할 기회만 없다면 저로서는
만족입니다.

> 무엇이 단정이란 말이죠?

님이 씀: "물론 스타일의 문제지만 ..."

> 수 많은 주장과 토론을 보며 논지와 전혀 상관없는 이상한 단어를 쓰면 참 도움이
> 된다고 배우셨습니까?

제가 그렇게 배웠는진 모르겠지만, 다행스럽게도 님처럼 논리적 모순으로
점철된 글을 남기지는 않도록 배운 것은 확실합니다.

> 앞에 언급한 것이 마치 새로운 기술인양 얘기하시는군요.

질문이 나온 후 "처음" 언급된 기술들이라는 뜻입니다. 진지하게 드리는
질문 입니다만, 혹시 글을 이해하시는데 어려움이 있으신지요?

> 이 토론에서 꼭 나와야 한다는
> 뜻이 아닙니다면 이미 undef, define하는 수고를 하는 것이 덜 창의적이고 시간을 많이
> 소모할 것이라는 아이디어가 나왔다는 것이죠.

AA 를 "04" 로 정의해 문자열 연결로 사용하는 것도 #define, (필요에
따라) #undef 가 필요한 건 매 한가지입니다.

> 제 의도를 여전히 모르시는군요. 현실적으로 잘못된 프로그램 구조가 무엇을 의미하는지
> 조금 이라도 고민해 보고 말씀하시기 바랍니다. 그리고 표준 안에서 잘못된 프로그램 구조의
> 정의가 어디에 있는지 알려주시기 바랍니다.
>
[...]
>
> 표준을 두고 논하는 것이 일반적이라는데 동의합니다. 그래서 표준에서 얘기하는
> "잘못된 프로그램의 구조"에 대한 정의가 무엇이란 말인지요?
>

undefined behavior 를 일으키는 프로그램은 해당 프로그램이 잘못된 구조
(invalid construct)임을 의미합니다. undefined behavior 의 정의를 보고
이를 파악하지 못하셨다면, 표준이 기술하는 각 행동을 설명한 아래
글들을 참고하시기 바랍니다.

http://www.devx.com/tips/Tip/12684
http://www.embedded.com/story/OEG20020321S0014

표준은 프로그램의 행동을 크게 3가지로 구분하고 있습니다. 그 중 2개인
unspecified behavior/implementation-defined behavior 는 "올바른"
프로그램이지만 이식성을 갖지 못하는 행동을 규정할 때 사용하며,
undefined behavior 는 프로그램 자체가 올바르지 않음을 규정할 때
사용합니다. 따라서 똑같이 표준이 보장해주지 않는 행동이라 할지라도
행동의 "격"이 달라지는 것으로 볼 수 있습니다.

implementation-defined behavior 나 unspecified behavior 는 프로그램이
그와 같은 구조를 포함하고 있다고 해도 컴파일러가 그 이유만으로
프로그램 번역을 실패하거나 실행 중 오류를 일으키도록 만들 수
없습니다. 환경에 따라 서로 다른 행동을 보일지라도 올바른 프로그램이기
때문입니다.

반면, undefined behavior 는 표준이 잘못된 프로그램으로 규정하고 있기
때문에 그 행동이 발생할 경우 컴파일을 실패하거나 실행 중 오류를
일으키며 프로그램이 종료되는 것도 허용하고 있습니다.

님이 # 를 %i 에 적용한 것은 undefined behavior 에 해당하며, 이는 특정
표준 라이브러리의 printf 가 %#i 를 보고 프로그램을 강제 종료시키거나,
시스템을 강제 종료시키거나, 혹은 buffer overrun 을 일으켜 해당 시스템
에 보안을 위협하는 것도 C 표준에 의해 허용됨을 의미합니다.

puaxx 님의 답변에 대해 제가 단 답변이 그 태도 면에서 맘에 들지
않으셨다면 차라리 bootmeta 님처럼 그 부분을 지적하셨으면 됩니다.
옳지 않은 내용에 대한 주장을 이어 나가기 위해 도저히 어디로 튈지 알
수 없는 논리적 비약을 수차례에 걸쳐 게시판에 남기실 필요는
없었습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

다른 것은 모두 포기하고 이것만은 지적해야겠습니다.

Quote:

반면, undefined behavior 는 표준이 잘못된 프로그램으로 규정하고 있기
때문에 그 행동이 발생할 경우 컴파일을 실패하거나 실행 중 오류를
일으키며 프로그램이 종료되는 것도 허용하고 있습니다.

표준 어디에 잘못된 프로그램으로 지적하고 있습니까?
알기 쉽게 얘기하죠.
3.4.3에서 말하는 것은 쉽게 얘기하면 표준에서 어떻게 하라고 하지 않으니까 알아서 해라 이런 뜻입니다.
알아서 해라라는 행동을 일으키는 프로그램이 잘못된 구조라고 정의한 적이 없습니다. 있다면 알려달라는 것입니다.
전웅의 이미지

> 다른 것은 모두 포기하고 이것만은 지적해야겠습니다.
>
> > 반면, undefined behavior 는 표준이 잘못된 프로그램으로 규정하고 있기
> > 때문에 그 행동이 발생할 경우 컴파일을 실패하거나 실행 중 오류를
> > 일으키며 프로그램이 종료되는 것도 허용하고 있습니다.
>
> 표준 어디에 잘못된 프로그램으로 지적하고 있습니까?
> 알기 쉽게 얘기하죠.
> 3.4.3에서 말하는 것은 쉽게 얘기하면 표준에서 어떻게 하라고 하지 않으니까 알아서 해라 이런 뜻입니다.
> 알아서 해라라는 행동을 일으키는 프로그램이 잘못된 구조라고 정의한 적이 없습니다. 있다면 알려달라는 것입니다.
>

다른 부분에도 억지 논리 말고 그렇게 까다로운 분석을 적용해 보셨으면
좋지 않았을까 생각해 봅니다.

Quote:

4. Conformance

If a "shall" or "shall not" requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined behavior
is otherwise indicated in this International Standard by the words
"undefined behavior" or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe "behavior that is undefined".

표준이 undefined behavior 를 명시하는 방법에 대해 설명하고 있습니다.
그리고 이어서,

Quote:

A program that is correct in all other aspects, operating on correct
data, containing unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

라고 기술하고 있습니다.

즉, undefined behavior 를 포함하는 프로그램은 [A] program that is
correct in all other aspects, operating on correct data, ... 인
프로그램이 될 수 없습니다. 즉, 올바른 프로그램의 실행 양식에 대해
강제하는 5.1.2.3 이 적용되는 프로그램은 undefined behavior 를 품을 수
없습니다.

만약, 님이 undefined behavior 에 의미를 부여해서 implementation 이
확장을 제공하는 경우를 의미하고 계신 것이라면, 분명 implementation
은 undefined behavior 에 의미를 부여해 확장을 제공할 수 있습니다. 이는
단순한 undefined behavior 뿐만 아니라 거의 같은 수준의 잘못된 행동인
문법을 어기는 프로그램에도 가능합니다. 예를 들어, gcc 는 함수 안에
함수를 정의하는 것을 확장으로 제공하고 있습니다.

하지만, 동일한 확장이라도 표준 입장에서 undefined behavior 에 의미가
부여된 확장에 의존하는 프로그램은 correct program 이 아닙니다. 반대로
implementation 입장에서는 unspecified behavior 나 implementation-
defined behavior 를 통해 제공하던 부분은 버전이 변하더라도 유의미하게
제공해주어야 하지만, undefined behavior 를 통해 제공하던 확장은 통보
하나 없이 제거하는 것이 가능합니다 - 애초에 그 행동에 의존하던
프로그램이 잘못된 프로그램이기 때문입니다.

예를 들어, gcc 2.9.x 는 반환형이 정수형이고 return 문이 없는 함수가
(표준에 의하면 그런 함수의 반환값은 undefined 입니다) 암시적으로 1
(1 인지 0 인지는 기억이 가물가물합니다) 을 반환하도록 확장을 제공해
주고 있었습니다. 하지만, gcc 3.x 에 들어와 이 확장은 소리소문 없이
제거되었고, 덕분에 그 행동에 의존하던 몇몇 프로그램들이 오작동한다는
글이 여기저기 올라온 적이 있습니다.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:

즉, undefined behavior 를 포함하는 프로그램은 [A] program that is
correct in all other aspects, operating on correct data, ... 인
프로그램이 될 수 없습니다. 즉, 올바른 프로그램의 실행 양식에 대해
강제하는 5.1.2.3 이 적용되는 프로그램은 undefined behavior 를 품을 수
없습니다.

undefined behavior가 아니고 unspecified behavior입니다.

Quote:

하지만, 동일한 확장이라도 표준 입장에서 undefined behavior 에 의미가
부여된 확장에 의존하는 프로그램은 correct program 이 아닙니다. 반대로
implementation 입장에서는 unspecified behavior 나 implementation-
defined behavior를 통해 제공하던 부분은 버전이 변하더라도 유의미하게
제공해주어야 하지만, undefined behavior 를 통해 제공하던 확장은 통보
하나 없이 제거하는 것이 가능합니다 - 애초에 그 행동에 의존하던
프로그램이 잘못된 프로그램이기 때문입니다.

여기서 correct의 의미는 conforming하다는 것입니다.
correct라는 의미를 잘못된의 반대 의미로 생각하시는 것 같은데 그것이 아닙니다.
conforming한 상황만을 기술하고 있을 뿐입니다.
"정의되지 않은 행동"이 결론이기 때문에 정의되지 않은 행동에 의존하는 프로그램은
말 그대로 정의되지 않은 것입니다.
전웅의 이미지

> > 즉, undefined behavior 를 포함하는 프로그램은 [A] program that is
> > correct in all other aspects, operating on correct data, ... 인
> > 프로그램이 될 수 없습니다. 즉, 올바른 프로그램의 실행 양식에 대해
> > 강제하는 5.1.2.3 이 적용되는 프로그램은 undefined behavior 를 품을 수
> > 없습니다.
>
> undefined behavior가 아니고 unspecified behavior입니다.
>

--; 제가 인용한 문장의 의미는 correct program 은 unspecified behavior
를 품을 수 있다는 뜻입니다. 제가 이전에 링크해드린 다른 글들은
읽어보셨는지요? 위에서 그리 반복해 설명을 드렸는데도 왜 이런 반응이
나오는지 이해하기 어렵습니다.

> > 하지만, 동일한 확장이라도 표준 입장에서 undefined behavior 에 의미가
> > 부여된 확장에 의존하는 프로그램은 correct program 이 아닙니다. 반대로
> > implementation 입장에서는 unspecified behavior 나 implementation-
> > defined behavior를 통해 제공하던 부분은 버전이 변하더라도 유의미하게
> > 제공해주어야 하지만, undefined behavior 를 통해 제공하던 확장은 통보
> > 하나 없이 제거하는 것이 가능합니다 - 애초에 그 행동에 의존하던
> > 프로그램이 잘못된 프로그램이기 때문입니다.
>
> 여기서 correct의 의미는 conforming하다는 것입니다.
> correct라는 의미를 잘못된의 반대 의미로 생각하시는 것 같은데 그것이 아닙니다.
> conforming한 상황만을 기술하고 있을 뿐입니다.
> "정의되지 않은 행동"이 결론이기 때문에 정의되지 않은 행동에 의존하는 프로그램은
> 말 그대로 정의되지 않은 것입니다.
>

strictly conforming, conforming, correct 의 개념 조차 제대로 파악하고
계시지 못한 분이 너무 거침없이 거짓을 진실처럼 내뱉고 계시는군요.
어느 정도 친절히 설명을 드리면 님께서도 이해가 가능할 것이라 믿었는데
제가 바보였습니다. 다른 사람이 거짓을 진실로 믿는 것을 막을 권한은 그
누구에게도 없으니 그렇게 믿고 싶으시면 그렇게 알고 계시면 됩니다.

참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
correct 프로그램이지만 strictly conforming program 이 아닙니다. 또한,
undefined behavior 를 포함하는 프로그램도 conforming program 이 될 수
있습니다. 이런 내용은 알고 계신 상태로 말도 안되는 주장을 펴고 계신
것인지요? 참으로 답답합니다.

여러번 드리는 말씀이지만, 모르는 것은 죄가 아닙니다. 저를 포함해
누구든지 무엇인가를 모르던 시절이 있고 또 앞으로도 있을 것입니다.
하지만, 잘못 알고 있는 내용에 대해 질문을 통해 올바른 지식으로 수정
하려는 태도 없이 억지 주장만 늘어놓는 것은 더 이상 보고 있기
역겹습니다.

할 말도 다 한 것 같고 어느 정도 정리된 것 같으니 제대로 된 질문이
나오지 않는 이상 이 쓰래드는 그만 참여하렵니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:
> > 즉, undefined behavior 를 포함하는 프로그램은 [A] program that is
> > correct in all other aspects, operating on correct data, ... 인
> > 프로그램이 될 수 없습니다. 즉, 올바른 프로그램의 실행 양식에 대해
> > 강제하는 5.1.2.3 이 적용되는 프로그램은 undefined behavior 를 품을 수
> > 없습니다.
>
> undefined behavior가 아니고 unspecified behavior입니다.
>

--; 제가 인용한 문장의 의미는 correct program 은 unspecified behavior
를 품을 수 있다는 뜻입니다. 제가 이전에 링크해드린 다른 글들은
읽어보셨는지요? 위에서 그리 반복해 설명을 드렸는데도 왜 이런 반응이
나오는지 이해하기 어렵습니다.


아 이 부분은 프로그램이 될 수 없습니다를 있습니다로 읽은 것이네요.
당연히 동의합니다.
그래서 correct program 이 아니라서 잘못된 프로그램 구조라는 것입니까?
전웅의 이미지

> 그래서 correct program 이 아니라서 잘못된 프로그램 구조라는 것입니까?
>

답은 스스로 하고 계십니다. "correct program 이 아니다" 를 결국
"잘못된 프로그램(구조)이다" 라는 우리말로 옮긴 것 뿐입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:
답은 스스로 하고 계십니다. "correct program 이 아니다" 를 결국
"잘못된 프로그램(구조)이다" 라는 우리말로 옮긴 것 뿐입니다.

correct program이라는 말도 conformance라는 테두리 아래에서 정의되어
있습니다. 프로그램과 구조라는 이름을 같이 쓰는 것도 분명 문제가 있지만,
반대가 잘못된이란 의미로 사용되기는 어렵다고 봅니다.
경의 이미지

Quote:
4p7 에
의해 구현체에 따라 conforming program 에 해당될 순 있습니다.

결국 어떤 구현체에서는 conforming program이 잘못된 프로그램이 된다는 모순이 됩니다.
어떤 구현체에서 conforming하고 다른 구현체에서는 아니다라고 하는 것과는
무척 다른다는 것을 아실 것입니다.
전웅의 이미지

[3군데의 글이 관련되어 있으므로 한 곳으로 모아 답변합니다]

> 4p6에 따르면 printf의 undefined behavior에 해당하는 것을 conforming program
> 이라고 정의한 것이 없습니다.
>
> correct program이라는 말도 conformance라는 테두리 아래에서 정의되어
> 있습니다. 프로그램과 구조라는 이름을 같이 쓰는 것도 분명 문제가 있지만,
> 반대가 잘못된이란 의미로 사용되기는 어렵다고 봅니다.
>
> 결국 어떤 구현체에서는 conforming program이 잘못된 프로그램이 된다는 모순이 됩니다.
> 어떤 구현체에서 conforming하고 다른 구현체에서는 아니다라고 하는 것과는
> 무척 다른다는 것을 아실 것입니다.
>

표준은 순식간에 펼쳐서 한 1-2시간 읽은 후에 정확한 해석을 내릴 수 있는
문서가 아닙니다. 저는 제 스스로 최소한 평균 정도의 이해력을 가지고
있다고 생각하지만, 표준 전체에 대해서 자부할만큼 이해하는데 최소 5년
이상이 걸렸습니다.

표준에서 제목은 informative part 로 분류됩니다. 즉, 그 절에서 나오는
내용에 대한 안내일 뿐이지 correct program 이라는 "표현"이 conformance
제목 아래 나왔다고 해서 correct program 과 conforming program 이 어떤
연관성을 갖도록 강제할 수 있는 장치가 아닙니다. 참고로 이와 같은
전반적인 ISO 표준 해석에 대한 방법은 "ISO/IEC Directives" 라는 문서
에서 규정하고 있습니다. 님 말씀대로 conformance 라는 제목이 어떤
강제력을 띄어야 한다면 표준은 손봐야 할 곳이 한두 군데가 아닙니다.

conforming program 은 correct program 과 무관하게 정의된 개념입니다.
말 그대로 어떤 하나의 구현체가 특정 프로그램을 받아들인다면 해당
구현체에서 해당 프로그램을 conforming program 이라고 부르는 것입니다.
즉, conforming program 은 이식성이나 프로그램의 옳고 그름과는 아무런
관계가 없는 용어입니다. 예를 들어 어떤 C 컴파일러가 C 프로그램 뿐
아니라 FORTRAN 프로그램을 컴파일 해줄 수 있다면, C 표준에 의하면 해당
컴파일러에게 그 FORTRAN 프로그램도 conforming program 입니다 - 진담
으로 하는 이야기입니다.

이런 말도 되지 않는 개념이 왜 표준에 들어갔는지 그 이유를 설명하자면,
이른바 표준이 도입한 개념에 불만을 가질 수 있는 사람들을 "달래기" 위한
목적입니다. 즉, 표준이 strictly conforming program 만 엄격하게 정의
한다면 대부분의 규모 있는 프로그램들이 표준의 범위를 벗어나는 NOT
strictly conforming program 이 되는 것입니다. 이러한 사실에 불만이
제기되자 "conforming" program 이라는 그럴싸한 이름을 그런 프로그램에게
붙일 수 있도록 배려해준 것뿐입니다.

아래는 제가 초기 표준에 대해 공부할 때 conforming program 에 대해 문의
한 글입니다.

http://groups.google.co.kr/group/comp.std.c/browse_frm/thread/9394beafa2a2d528/ccb4fb84e7753c3b

Douglas Gwyn 의 답변을 참고하시기 바랍니다.

표준에 있어 correct program 은 프로그램 실행에 대해 기술하는
부분(5.1.2.3)의 요구가 적용되는 프로그램을 말합니다. undefined
behavior 를 일으키는 프로그램은 말 그대로 표준이 그 어떤 요구도 가하지
않으며, 따라서 5.1.2.3의 요구도 가해질 수 없습니다. 즉, undefined
behavior 를 일으키는 프로그램은 correct program 이 될 수 없는
것입니다. 4장에서 언급되는 "correct" program 은 위의 "conforming
program" 이나 "strictly conforming program" 처럼 명백한 정의를
갖는다기 보다는 (표준에서 정의는 3장에 보이거나 이탤릭체로 표기하거나
문법을 통해서 이루어집니다) 우리가 흔히 사용하는 "correct (올바른)"
program 에 대한 기술을 하고 있는 것입니다. 따라서 undefined behavior
를 갖는 프로그램을 표준은 "not correct (= incorrect) program" 으로
규정하고 있는 것이고, 이는 우리말로 "잘못된 프로그램"이라고 부를 수
있습니다.

더 이상 correct 와 conforming 을 결부시키지 마시기 바랍니다.

그리고 (돈 아까우니 구입하시라고 말씀을 드리지는 않겠습니다 :-) 근처
도서관에서 제 책의 앞부분을 한번 보시길 추천합니다. 졸작이지만 표준이
도입하고 있는 conformance 관련 용어를 나름대로 열심히 정리해
두었습니다.

또, "프로그램"과 "프로그램 구조"에 대한 언급을 하셨는데, 영어로 논의를
진행할 때 "program", "program constrcut" 는 종종 통용되어 사용되는
표현입니다. 이를 그대로 우리말로 옮겨 사용한 것뿐입니다. 실제 제가
이전에 링크했던 글을 보시면 undefined behavior 를 기술하면서
"erroneous program constructs" 라는 표현을 사용하고 계신 것을 보실 수
있습니다. 더구나 현재 논의에서 중심은 "incorrect" 입니다.

무엇인가를 저에게 가르치시려 하시는 것 같은데 그만 하시기 바랍니다.
님이 10-20분 보신 문장을 저는 수년간 보아왔고 표준의 이런 저런 문장을
놓고 지금까지 뉴스그룹에 올린 글만 도합 3000건이 넘습니다. 표준화
위원회 멤버나 기타 표준에 관여하신 분들과 개인적으로 나눈 메일은
그보다 더 많습니다.

잘난 척을 하자는 것이 아닙니다. 제가 드린 말씀은 표준을 1-2시간 읽어
보고 드리는 답변이 아닌만큼 일단 믿고 이해하려 노력해 달라는
뜻입니다. 설명에 부족한 부분이 많겠지만 제가 말씀드린 부분을
살펴보시고 궁금한 점 있으면 "질문"을 주시기 바랍니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

(이제 읽을 만합니다......)

Quote:
표준은 순식간에 펼쳐서 한 1-2시간 읽은 후에 정확한 해석을 내릴 수 있는
문서가 아닙니다. 저는 제 스스로 최소한 평균 정도의 이해력을 가지고
있다고 생각하지만, 표준 전체에 대해서 자부할만큼 이해하는데 최소 5년
이상이 걸렸습니다.

알겠습니다.
제가 말하는 것을 가르친다고 생각하지 말고 그냥 능력 것 해석하고 이해한대로
얘기한다고 생각하시기 바랍니다.

Quote:

표준에서 제목은 informative part 로 분류됩니다.

ISO/IEC Directives Part2 에서 Annex C에 보면 Clause(위에서 말한 제목)는
기본적으로 Normative입니다. Annex에서 괄호로 normative/informative를
표시하고 있을 뿐입니다. 5.2.2에서 나와 있듯이 문서의 내용을 구분하는 기본적인
컴포넌트입니다.

Quote:

즉, 그 절에서 나오는
내용에 대한 안내일 뿐이지 correct program 이라는 "표현"이 conformance
제목 아래 나왔다고 해서 correct program 과 conforming program 이 어떤
연관성을 갖도록 강제할 수 있는 장치가 아닙니다.

강제하는 장치가 아니라는데는 동의하지만 아주 심각하게 리뷰를 거친 결과라고 생각
합니다.

Quote:

참고로 이와 같은
전반적인 ISO 표준 해석에 대한 방법은 "ISO/IEC Directives" 라는 문서
에서 규정하고 있습니다.

적절한 레퍼런스를 지적해 주셔서 감사합니다.

Quote:

님 말씀대로 conformance 라는 제목이 어떤
강제력을 띄어야 한다면 표준은 손봐야 할 곳이 한두 군데가 아닙니다.

지금 형태의 표준이 완전하다고 볼 수 없기에 표준화 위원회에서 할 일이 계속있다는
뜻으로 알겠습니다.

Quote:
conforming program 은 correct program 과 무관하게 정의된 개념입니다.
말 그대로 어떤 하나의 구현체가 특정 프로그램을 받아들인다면 해당
구현체에서 해당 프로그램을 conforming program 이라고 부르는 것입니다.
즉, conforming program 은 이식성이나 프로그램의 옳고 그름과는 아무런
관계가 없는 용어입니다. 예를 들어 어떤 C 컴파일러가 C 프로그램 뿐
아니라 FORTRAN 프로그램을 컴파일 해줄 수 있다면, C 표준에 의하면 해당
컴파일러에게 그 FORTRAN 프로그램도 conforming program 입니다 - 진담
으로 하는 이야기입니다.

conforming program에 대해서는 알겠습니다.

Quote:
표준에 있어 correct program 은 프로그램 실행에 대해 기술하는
부분(5.1.2.3)의 요구가 적용되는 프로그램을 말합니다.

correct program을 위에서 말씀하신 요구사항을 만족하는 프로그램
이라고 할 수 있을 것입니다. conforming이 바로 요구 사항을 만족하는 뜻입니다.
correct가 conforming이다 라고 주장하지는 않겠습니다. 그러나 unspecified
behavior와 5.1.2.3을 만족하는, strictly conforming program은 아닌 한 셋의
조건을 요구하고 있을 뿐입니다.

Quote:

undefined
behavior 를 일으키는 프로그램은 말 그대로 표준이 그 어떤 요구도 가하지
않으며, 따라서 5.1.2.3의 요구도 가해질 수 없습니다. 즉, undefined
behavior 를 일으키는 프로그램은 correct program 이 될 수 없는
것입니다.

correct program이 될 수 없지만 "정의되지 않은 행동"이기에 그 반대의미도
될 수 없는 것입니다. "정의되지 않은 행동/특정 구현체에서 무엇이든 가능한 행동"이
correct program을 정의하는데 도움을 주고 있는 것입니다.

Quote:

4장에서 언급되는 "correct" program 은 위의 "conforming
program" 이나 "strictly conforming program" 처럼 명백한 정의를
갖는다기 보다는 (표준에서 정의는 3장에 보이거나 이탤릭체로 표기하거나
문법을 통해서 이루어집니다) 우리가 흔히 사용하는 "correct (올바른)"
program 에 대한 기술을 하고 있는 것입니다. 따라서 undefined behavior
를 갖는 프로그램을 표준은 "not correct (= incorrect) program" 으로
규정하고 있는 것이고, 이는 우리말로 "잘못된 프로그램"이라고 부를 수
있습니다.
또, "프로그램"과 "프로그램 구조"에 대한 언급을 하셨는데, 영어로 논의를
진행할 때 "program", "program constrcut" 는 종종 통용되어 사용되는
표현입니다. 이를 그대로 우리말로 옮겨 사용한 것뿐입니다.
실제 제가 이전에 링크했던 글을 보시면 undefined behavior 를 기술하면서
"erroneous program constructs" 라는 표현을 사용하고 계신 것을 보실 수
있습니다. 더구나 현재 논의에서 중심은 "incorrect" 입니다.

우리가 흔히 사용하는 올바른 프로그램이라고 하면 Thread 등과 같은 라이브러
리와 링크되는 것도 고려해야 합니다. 이것까지 correct program이라고
하시겠습니까?

애초에 잘못된 프로그램 구조의 정의를 5.1.1.1 에서 찾으려고 했었습니다.
그러나 잘 연결이 안 됐습니다.
SO/IEC TR 10176:2003(E)에 3.3.1 errors의 정의를 인용하면,

Quote:

The incorrect program constructs which are statically determinable solely from inspection of the program text,
without execution, and from knowledge of the language syntax. A fatal error is one from which recovery is not
possible, i.e. it is not possible to proceed to (or continue with) program execution. A non-fatal error is one
from which such recovery is possible

그리고 4.1.4.1.1 Errors of program structure 에서 알 수 있듯이 소스에서 눈으로
확인할 수 있는 구문 오류와 같은 것을 예로 들고 있습니다.
Quote:

Reasons for not adopting any particular guideline should be documented and made available, (e.g. in an
informative annex of the programming language standard)

소개에 나온 이걸 보면 그냥 가이드라인이 아님을 알 수 있습니다.

표준에 없는 단어를 이 문서를 기준으로 더해서 생각해 보면 "erroneous program
constructs"의 constructs는 program structure의 preprocessing translation unit
을 구성하는 부속품으로서 의미를 가진다고 할 수 있습니다. 이것은 잘못된 syntax 사용하는 프로그램 정도의 의미가 되고 correct program 반대 개념을 고려하지 않아도 됩니다.
이럴 경우 잘못된 프로그램 구조라고 말하기에는 번역이 어색합니다.

Quote:
그리고 (돈 아까우니 구입하시라고 말씀을 드리지는 않겠습니다 :-) 근처
도서관에서 제 책의 앞부분을 한번 보시길 추천합니다. 졸작이지만 표준이
도입하고 있는 conformance 관련 용어를 나름대로 열심히 정리해
두었습니다.

기회가 되면 그러겠습니다.

Quote:

무엇인가를 저에게 가르치시려 하시는 것 같은데 그만 하시기 바랍니다.
님이 10-20분 보신 문장을 저는 수년간 보아왔고 표준의 이런 저런 문장을
놓고 지금까지 뉴스그룹에 올린 글만 도합 3000건이 넘습니다. 표준화
위원회 멤버나 기타 표준에 관여하신 분들과 개인적으로 나눈 메일은
그보다 더 많습니다.

잘난 척을 하자는 것이 아닙니다. 제가 드린 말씀은 표준을 1-2시간 읽어
보고 드리는 답변이 아니라는 뜻입니다. 설명에 부족한 부분이 많겠지만
제가 말씀드린 부분을 살펴보시고 궁금한 점이나 이해가 어려운 부분
있으면 "질문"을 하시기 바랍니다.


경험에 우러나는 통찰력으로 표준에 대해 고민할 수 있는 좋은 기회를 주셔서
감사합니다. 또 많은 오류를 범했을지도 모르지만 너그럽게 임해주시면 더욱
고맙겠습니다.

- 경

전웅의 이미지

> > 표준에서 제목은 informative part 로 분류됩니다.
>
> ISO/IEC Directives Part2 에서 Annex C에 보면 Clause(위에서 말한 제목)는
> 기본적으로 Normative입니다. Annex에서 괄호로 normative/informative를
> 표시하고 있을 뿐입니다. 5.2.2에서 나와 있듯이 문서의 내용을 구분하는 기본적인
> 컴포넌트입니다.
>

ISO/IEC Directives Part 2 를 보시고 그 중 Annex C 를 보니 님이
보시기에 Clause (제목) 가 normative 로 되어 있는 것 같다고 생각이
드신다면, 올바른 순서는 "normative 로 되어 있습니다" 라고 주장하시기
전에 "normative 로 되어 있는데 왜 informative 라고 했느냐?" 라고
"묻는" 것이 아닐까 생각합니다. Directives 를 알려드린 제가 제 스스로
한번 들여다보지도 않고 님께 거짓을 주장할리는 없지 않겠습니까?

Annex C 는 님이 말씀하신 것처럼 "표준의 제목이 normative 라고" 보이기
위해 집어넣은 부록이 아닙니다. 전체적인 표준의 구조가 어떻게 될 수
있으며, 그 중 1, 2장은 반드시 Scope, Normative references 를 포함해야
하며, 숫자로 넘버링되는 장들의 "내용"은 반드시 normative 여야 하며,
알파벳으로 넘버링 되는 장들의 "내용"은 선택적으로
informative/normative 일 수 있다는 전체적인 구조를 예를 들어 보여주기
위한 것입니다. 이는 각 장, 절의 제목이 normative 이다, 아니다를
보이는 목적으로 넣은 부록이 아닙니다. 더구나 Annex C 자체가
informative 라는 사실은 Annex C 를 잘라내 없애도 Directives 가 전달
하는 내용에는 변화가 없음을 의미합니다.

제가 보기에 지금 님께서는 님의 주장에 근거를 맞추기 위해 다소 부족한
해석을 끌고와 붙이고 계십니다. 다시 한번 말씀드리지만, 제가 이전
글까지 드린 표준과 관련된 내용은 수십번 이상 확인된 내용이기 때문에
의심의 여지가 없는 참입니다. 님께서 이런 저런 부적절한 근거를 끌고와
달라질 수 있는 내용이 아닙니다. 만약, 해당 내용이 거짓이라면 지금까지
수백, 수천번 이루어졌을지 모르는 각종 논의와 위원회 결정 등이 모두
번복되어야 합니다.

> > 즉, 그 절에서 나오는
> > 내용에 대한 안내일 뿐이지 correct program 이라는 "표현"이 conformance
> > 제목 아래 나왔다고 해서 correct program 과 conforming program 이 어떤
> > 연관성을 갖도록 강제할 수 있는 장치가 아닙니다.
>
> 강제하는 장치가 아니라는데는 동의하지만 아주 심각하게 리뷰를 거친 결과라고 생각
> 합니다.

리뷰를 거치지만 어차피 informative 인 제목의 사소한 결함은 (설사
있더라도) 수정을 필요로 할만큼 중요성을 갖지 않는다는 뜻입니다.

[...]

> > 표준에 있어 correct program 은 프로그램 실행에 대해 기술하는
> > 부분(5.1.2.3)의 요구가 적용되는 프로그램을 말합니다.
>
> correct program을 위에서 말씀하신 요구사항을 만족하는 프로그램
> 이라고 할 수 있을 것입니다. conforming이 바로 요구 사항을 만족하는 뜻입니다.

제가 생략한 부분에서 conforming program 의 의미를 아시겠다고 하시면서
또 앞뒤가 맞지 않는 주장을 하고 계시면 저보고 어쩌란 말씀이신지요?
제가 "가"를 말하면 님께서 "가"로 알아들으셔야 대화가 가능하지, 제가
"가"라고 할 때마다 "무슨 말인지 알겠습니다. '나'라고 하신거죠?" 라고
답하시면 더 이상 이야기가 진행될 수 없습니다. correct program 의 개념
과 conforming program 의 정의는 "아무런" 관련이 없습니다. "일반적인"
의미가 비슷한 개념을 내포한다고 해서 관련 짓지 마시기 바랍니다. 표준
은 "conforming" program 에 일반적인 의미와 전혀 다른 고유의 정의를
부여하고 있습니다. 이를 제대로 보실 줄 모르면 표준을 전혀 이해하실 수
없게 됩니다. 이 부분은 더 이상 반복해 말씀드리지 않겠습니다. 스스로
깨달아 이해하시든, 꾸준히 잘못 알고 계시든 님의 선택이고 님의 책임
입니다.

> correct가 conforming이다 라고 주장하지는 않겠습니다. 그러나 unspecified
> behavior와 5.1.2.3을 만족하는, strictly conforming program은 아닌 한 셋의
> 조건을 요구하고 있을 뿐입니다.
>

correct program 의 subset 이 strictly conforming program 이고,
conforming program 은 이 둘과 아무런 관련이 없습니다.

> correct program이 될 수 없지만 "정의되지 않은 행동"이기에 그 반대의미도
> 될 수 없는 것입니다. "정의되지 않은 행동/특정 구현체에서 무엇이든 가능한 행동"이
> correct program을 정의하는데 도움을 주고 있는 것입니다.

표준이 correct program 의 개념에 대해 기술하고 있다면 그 기술된 내용
에 부합하는 프로그램은 correct program, 그렇지 않은 프로그램은
correct program 이 아니라고 말할 수 있습니다. undefined behavior 를
포함하는 프로그램은 그 기술에 부합하지 않는 프로그램이므로 correct
program 이 아니라고 말할 수 있습니다. 따라서 undefined behavior 를
포함하는 프로그램은 incorrect program 이라고 말할 수 있습니다. 이를
우리말로 옮기면 "잘못된 프로그램"에 해당됩니다.

"undefined behavior" 가 correct program 을 정의하는데 도움을 주지만
undefined behavior 를 포함하는 프로그램을 correct program 이라고
부를 수는 없다? 위의 논리적 과정을 못 따라오시니 계속 이런 주장을
하시고 계신 것이라 생각합니다. 위에 적어드린 방법이 해당 부분을
올바르게 해석하는 방법입니다.

> 우리가 흔히 사용하는 올바른 프로그램이라고 하면 Thread 등과 같은 라이브러
> 리와 링크되는 것도 고려해야 합니다. 이것까지 correct program이라고
> 하시겠습니까?

우리가 지금 표준에 대해 이야기하고 있지요? 그 점은 동의하십니까? C
표준은 multi-thread/multi-process 의 개념을 포함하고 있지 않습니다.
즉, C 표준의 입장에서 하나의 구현체에서 실행되는 프로그램은 하나이며,
그 프로그램에 비동기적으로 영향을 줄 수 있는 존재는 <signal.h> 에서
정의하는 signal 이 전부입니다. 따라서 thread 의 개념은 배제됩니다.

thread 가 아닌 다른 라이브러리를 고려한다면, 만약 해당 프로그램은
물론 함께 링크되는 라이브러리 모두가 C 언어로 작성되어 있고 undefined
behavior 를 포함하지 않는다면 correct program 입니다.

> 애초에 잘못된 프로그램 구조의 정의를 5.1.1.1 에서 찾으려고 했었습니다.
> 그러나 잘 연결이 안 됐습니다.
> SO/IEC TR 10176:2003(E)에 3.3.1 errors의 정의를 인용하면,
>
> [관련 없는 인용 생략]
>
> 표준에 없는 단어를 이 문서를 기준으로 더해서 생각해 보면 "erroneous program
> constructs"의 constructs는 program structure의 preprocessing translation unit
> 을 구성하는 부속품으로서 의미를 가진다고 할 수 있습니다. 이것은 잘못된 syntax 사용하는 프로그램 정도의 의미가 되고 correct program 반대 개념을 고려하지 않아도 됩니다.
> 이럴 경우 잘못된 프로그램 구조라고 말하기에는 번역이 어색합니다.

성경 해석하는데 불경 들고 오신 격입니다. 표준에서 따로 정의하는
용어는 배타적 의미를 갖습니다. 또한, 표준이 정의하지 않는 용어는

Quote:

Terms not defined in this International Standard are to be
interpreted according to ISO/IEC 2382−1.

에 의해 ISO/IEC 2382-1 에 의해서만 정의될 수 있습니다. 만약, ISO/IEC
2382-1 에서도 정의되지 않은 용어가 있다면, 이는 Directives 에 의해

The Shorter Oxford English Dictionary
The Concise Oxford Dictionary
The Collins Concise English Dictionary
Webster's New World College Dictionary
Chambers Concise Dictionary

에 의해 정의됩니다.

표준은 correct program 을 strictly conforming program 처럼 어떤
conformance category 정의하고 있는 것이 아닙니다. 4장에서 일반적인
의미의 correct program 을 표준의 용어를 사용해 기술하고 있는
것입니다.

=====================================================================
반복해 설명드리지만, undefined behavior 를 포함하고 있는 프로그램을
표준은 NOT "correct program" 으로 기술하고 있습니다.

이는 억지 주장이 아니라 위원회의 의도적인 선택입니다. 즉, 어떤
프로그램 구조를 undefined behavior 로 규정한다는 것은 해당 프로그램을
유의미하게 지원할 가치가 없는 잘못된 프로그램으로 규정한다는
것입니다. 즉, 이식성을 고려하는 프로그래머는 (이식성을 포기하며
unspecified 나 implementation-defined 에 의존해도 correct 로 남을 수
있음에 비교해) 그와 같은 행동을 피해야 함을 강조하는 것입니다.

님의 생각, 주장은 틀렸습니다. 그걸 억지로 끼워맞추기 위해 이런 저런
근거를 수집하실 필요는 없습니다. 설사 님께서 어떤 치명적인 근거를
발견해 표준 해석이 달라진다해도 위원회의 의도는 (제가 말씀드린대로)
분명하므로 이는 표준을 고쳐야 함을 의미하지, 표준의 해석을 달리해야
함을 의미하는 것이 아닙니다. 소모적인 노력은 이제 그만 하셔도 되지
않겠습니까?

이제 이 소주제도 서서히 같은 이야기가 반복되고 있는 것 같습니다.
더구나 제 기억으로 이곳 사람들 이런 이론적 이야기를 별로 좋아하지도
않습니다. 이 글이 KLDP 에서의 제 마지막 글이 되길 바랍니다.

* 처음 썼던 글에 쓸데 없이 공격적인 부분이 있어 한 차례 수정합니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

whitenoise의 이미지

C 표준에 관한 이야기 나오면 WG14/N1124 뒤져가며 재미있게 보고 있습니다. 정확한 정의를 내리는 동시에 정확한 의미를 전달하는 일이 역시나 쉽지는 않군요. 저번의 static, extern 글을 읽으면서 undefined behavior에 관해 불명확한 점이 많았는데 이번 글 읽고 찾아보면서 조금 정리가 되는 듯 합니다.

한 분야에 있어 흔들림 없는 앎의 체계를 갖춘 사람을 만나기가 쉽지 않습니다. 앞으로 KLDP에서 글 안 쓰신다니 아쉽긴 합니다만 다른 곳에서 관련 글을 볼 수 있었으면 좋겠습니다.

modestcode의 이미지

Quote:
흠... 대체 제가 어디까지 설명을 드려야 할지 모르겠습니다. ISO/IEC
Directives Part 2 를 보시고 그 중 Annex C 를 보니 님이 보시기에
Clause (제목) 가 normative 로 되어 있는 것 같다고 생각이 드신다면,
올바른 순서는 "normative 로 되어 있습니다" 라고 주장하시기 전에
"normative 로 되어 있는데 왜 informative 라고 했느냐?" 라고 "묻는"
것입니다. Directives 를 알려드린 제가 제 스스로 한번 들여다보지도
않고 님께 거짓을 주장할리는 없지 않겠습니까?

되어 있다고 한 의미를 모르신단 말이세요?
제가 그렇게 되어 있다고 한 것은 Information Part라고 명시된 곳이 어디냐고
의문을 제기하는 것입니다.
이것은 애초에 인용을 하고 얘기 했으면 불필요한 것입니다.

Quote:

Annex C 는 님이 말씀하신 것처럼 "표준의 제목이 normative 라고" 보이기
위해 집어넣은 부록이 아닙니다. 전체적인 표준의 구조가 어떻게 될 수
있으며, 그 중 1, 2장은 반드시 Scope, Normative references 를 포함해야
하며, 숫자로 넘버링되는 장들의 "내용"은 반드시 normative 여야 하며,
알파벳으로 넘버링 되는 장들의 "내용"은 선택적으로
informative/normative 일 수 있다는 전체적인 구조를 예를 들어 보여주기
위한 것입니다. 이는 각 장, 절의 제목이 normative 이다, 아니다를
보이는 목적으로 넣은 부록이 아닙니다. 더구나 Annex C 자체가
informative 라는 사실은 Annex C 를 잘라내 없애도 Directives 가 전달
하는 내용에는 변화가 없음을 의미합니다.

Information Part를 설명하기를 바랬지 이미 그림을 보고 한 번에 안 것을
다시 쓰라고 한 것이 아닙니다.
4. Conformance가 Normative인데 아니란 말씀이세요?

Quote:

제가 보기에 지금 님께서는 님의 주장에 근거를 맞추기 위해 다소 부족한
해석을 끌고와 붙이고 계십니다. 다시 한번 말씀드리지만, 제가 이전
글까지 드린 표준과 관련된 내용은 수십번 이상 확인된 내용이기 때문에
의심의 여지가 없는 참입니다. 님께서 이런 저런 부적절한 근거를 끌고와
달라질 수 있는 내용이 아닙니다. 만약, 해당 내용이 거짓이라면 지금까지
수백, 수천번 이루어졌을지 모르는 각종 논의와 위원회 결정 등이 모두
번복되어야 합니다.

지금 얘기하고 있는 것들이 많이 논의 됐음을 알고 있습니다.
근데 확인할 수록 의문이 드네요.
다음부턴 c.s.c를 활용해야겠습니다.

Quote:
리뷰를 거치지만 어차피 informative 인 제목의 사소한 결함은 (설사
있더라도) 수정을 필요로 할만큼 중요성을 갖지 않는다는 뜻입니다.

지금 문맥을 놓치신 것 같은데 4. Conformance를 informative라고 한것에
대한 답입니다.

Quote:
> correct가 conforming이다 라고 주장하지는 않겠습니다. 그러나 unspecified
> behavior와 5.1.2.3을 만족하는, strictly conforming program은 아닌 한 셋의
> 조건을 요구하고 있을 뿐입니다.
>

correct program 의 subset 이 strictly conforming program 이고,
conforming program 은 이 둘과 아무런 관련이 없습니다.


unspecified behavior를 갖는 correct program이 strictly conforming program을
subset 으로 가진다고 얘기하는 것입니까?

> correct program이 될 수 없지만 "정의되지 않은 행동"이기에 그 반대의미도
> 될 수 없는 것입니다. "정의되지 않은 행동/특정 구현체에서 무엇이든 가능한 행동"이
> correct program을 정의하는데 도움을 주고 있는 것입니다.

Quote:

세상 순억지도 이런 억지가 가능할까요. 표준이 correct program 의 개념
에 대해 기술하고 있다면 그 기술된 내용에 부합하는 프로그램은 correct
program, 그렇지 않은 프로그램은 correct program 이 아니라고 말할 수
있습니다. undefined behavior 를 포함하는 프로그램은 그 기술에 부합
하지 않는 프로그램이므로 correct program 이 아니라고 말할 수
있습니다. 따라서 undefined behavior 는 incorrect program 이라고 말할
수 있습니다. 이를 우리말로 옮기면 "잘못된 프로그램"에 해당됩니다.

반대 의미의 구체적인 정의가 없는 상태에서 세운 정의의 문제점을 얘기한
것입니다. "표준에서 correct program에 대한 정의를 분명히 했다"라는 주장을
염두해 두겠습니다.
incorrect의 의미에 잘못된만 있는 것이 아닙니다.
"not conforming with accepted standards of propriety or taste"라는
의미도 있습니다.
그리고 프로그램과 프로그램 구조를 같로 통용된다고 하셨는데 분명히 program
이란 단어와 구분되는 program construct, program structure라는 단어가
있습니다. 이 혼돈을 어떻게 하시겠습니까?
Quote:

우리가 지금 표준에 대해 이야기하고 있지요? 그 점은 동의하십니까? C
표준은 multi-thread/multi-process 의 개념을 포함하고 있지 않습니다.
즉, C 표준의 입장에서 하나의 구현체에서 실행되는 프로그램은 하나이며,
그 프로그램에 비동기적으로 영향을 줄 수 있는 존재는 에서
정의하는 signal 이 전부입니다. 따라서 thread 의 개념은 배제됩니다.

알겠습니다.

Quote:
성경 해석하는데 불경 들고 오신 격입니다. 표준에서 따로 정의하는
용어는 배타적 의미를 갖습니다. 또한, 표준이 정의하지 않는 용어는

인용:

Terms not defined in this International Standard are to be
interpreted according to ISO/IEC 2382−1.

에 의해 ISO/IEC 2382-1 에 의해서만 정의될 수 있습니다. 만약, ISO/IEC
2382-1 에서도 정의되지 않은 용어가 있다면, 이는 Directives 에 의해

The Shorter Oxford English Dictionary
The Concise Oxford Dictionary
The Collins Concise English Dictionary
Webster's New World College Dictionary
Chambers Concise Dictionary

에 의해 정의됩니다.

표준은 correct program 을 strictly conforming program 처럼 어떤
conformance category 정의하고 있는 것이 아닙니다. 4장에서 일반적인
의미의 correct program 을 표준의 용어를 사용해 기술하고 있는
것입니다.


Bibliography에 표준을 준비하면서 참조한 문서(ISO/IEC TR 10176)가 이렇게 가치가 없는 줄
몰랐네요. 용어의 참조 순서에 대해서 잘 알겠습니다.
그렇다면 용어집에 없을 테니 사전적인 의미로 incorrect program construct/incorrect
program structure/incorrect program을 구분해 보시기 바랍니다.
erroneous program constructs에 대한 것까지 고려한다면 더욱 좋겠습니다.
아 용어집에 있다면 죄송합니다. 제가 ISO/IEC 2382-1까지는 아직 못 봐서요.
program structure는 correct program처럼 이미 있으니 program structure에 없는 것을
포함하면 incorrect program structure를 기술했다고 생각해야 하나요?

Quote:
반복해 설명드리지만, undefined behavior 를 포함하고 있는 프로그램을
표준은 NOT "correct program" 으로 기술하고 있습니다.

incorrect 에서 not correct 로 가는 것은 조금 나은 듯합니다.
그러나 그렇게 기술하는데 문제가 전혀 없다고 얘기한다는 입장을 염두해 두겠습니다.

Quote:
이는 억지 주장이 아니라 위원회의 의도적인 선택입니다. 즉, 어떤
프로그램 구조를 undefined behavior 로 규정한다는 것은 해당 프로그램을
유의미하게 지원할 가치가 없는 잘못된 프로그램으로 규정한다는
것입니다. 즉, 이식성을 고려하는 프로그래머는 (이식성을 포기하며
unspecified 나 implementation-defined 에 의존해도 correct 로 남을 수
있음에 비교해) 그와 같은 행동을 피해야 함을 강조하는 것입니다.

위원회의 강조하려는 의도라면 왜 분명히 conforming program처럼 이탤랙채로
정의하지 않았단 말입니까? 그리고 이식성을 강조해서 strictly conforming
program을 만들어 놓고 왜 correct program이라고 정의하지 않았겠습니까?

Quote:
님의 생각, 주장은 틀렸습니다. 그걸 억지로 끼워맞추기 위해 이런 저런
근거를 수집하실 필요는 없습니다. 설사 님께서 어떤 치명적인 근거를
발견해 표준 해석이 달라진다해도 위원회의 의도는 (제가 말씀드린대로)
분명하므로 이는 표준을 고쳐야 함을 의미하지, 표준의 해석을 달리해야
함을 의미하는 것이 아닙니다. 소모적인 노력은 이제 그만 하셔도 되지
않겠습니까?

erroneous program constructs에서 잘못된 프로그램 구조를 찾다가 4p3에서
찾은 correct program에 애써 맞추려고 노력 많이 하셨습니다.
아직까지 납득할만한 레퍼런스도 주장도 찾을 수 없습니다.

Rev 1 이식성과 관련 한 줄 지웁니다.

modestcode의 이미지

ISO/IEC TR 10176을 근거로 했던 얘기를 표준을 근거로 다시 얘기 해 보겠습니다.
5p1에서

Quote:

Their characteristics define and
constrain the results of executing conforming C programs constructed according to the
syntactic and semantic rules for conforming implementations.

여기서 constructs는 syntactic, semantic rules을 말하는 것을 알 수 있습니다.
3.4.3에서 erroneous program constructs는 이 syntactic, semantic 오류를
두고 한 것입니다.
그러므로 correct program의 반대 개념으로 얘기한 것은 부적절하고 잘못된 프로그램
구조는 결국 아주 이상한 번역이라는 것을 다시 말씀드립니다.
전웅의 이미지

> ISO/IEC TR 10176을 근거로 했던 얘기를 표준을 근거로 다시 얘기 해 보겠습니다.
> 5p1에서
>
> 인용:
>
> Their characteristics define and
> constrain the results of executing conforming C programs constructed according to the
> syntactic and semantic rules for conforming implementations.
>
> 여기서 constructs는 syntactic, semantic rules을 말하는 것을 알 수 있습니다.
> 3.4.3에서 erroneous program constructs는 이 syntactic, semantic 오류를
> 두고 한 것입니다.
> 그러므로 correct program의 반대 개념으로 얘기한 것은 부적절하고 잘못된 프로그램
> 구조는 결국 아주 이상한 번역이라는 것을 다시 말씀드립니다.
>

1. synctacic 은 표준의 "Syntax" 부분에 의해 정의된 언어 요소를
말하며, semantic 은 그 외 부분에 의해 정의된 언어 요소를 말합니다.
printf() 문에 "%#i" 를 사용한 것은 semantic 요소의 요구 사항(rule)을
위반한 것으로 printf("%#i", x) 는 분명 ISO/IEC TR 10176 을 근거로
보아도 erroneous program construct 에 해당합니다. 그리고 제 영어
(영한/영영) 사전은 "erroneous" 의 동의어로 wrong 과 incorrect 를,
한국어 의미로 "잘못된"을 보여주고 있습니다.

2. ISO/IEC TR 10176 은 사실 ISO/IEC 9899 의 해석에 아무런 영향을 미칠
수 없으며, 미쳐서도 안 됩니다. ISO/IEC TR 10176 은 ISO/IEC 9899 의
normative reference 에 포함되어 있지 않습니다.

결론: 님이 말씀하신 바를 근거로 보아도 님의 주장은 틀린 것이며, 표준
을 근거로 본다면 님이 이번 글에 적으신 내용은 관계 없는 내용입니다.

도움 안되는 말씀은 그만 하시고 제가 드린 말씀을 이해하시려 노력하시는
것이 님에게 훨씬 더 도움이 될 겁니다. --;

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

역시 문맥을 잘못 집었습니다. 제가 한 말 또 인용합니다.

Quote:
ISO/IEC TR 10176을 근거로 했던 얘기를 표준을 근거로 다시 얘기 해 보겠습니다.

여기서 표준은 C 표준입니다. normative reference 가 아닌 걸 알고 있습니다. 그래서 ISO/IEC 9899 표준을
보고 다시 분석한 것입니다.

correct program의 반대 개념은 어디 갔습니까?

잘못된 프로그램 구조가 sematic 요구사항을 위반한 프로그램으로 결론을 내 주셔서 감사합니다.

전웅의 이미지

> 역시 문맥을 잘못 집었습니다. 제가 한 말 또 인용합니다.
>
> 인용:
>
> ISO/IEC TR 10176을 근거로 했던 얘기를 표준을 근거로 다시 얘기 해 보겠습니다.
>
> 여기서 표준은 C 표준입니다. normative reference 가 아닌 걸 알고 있습니다. 그래서 ISO/IEC 9899 표준을
> 보고 다시 분석한 것입니다.
>

ISO/IEC TR 10176 을 C 표준을 근거로 다시 얘기하시겠다는 뜻인가요?
우리가 지금까지 ISO/IEC TR 10176 에 대해 이야기하고 있었나요? ISO/IEC
TR 10176 이 C 프로그램의 의미에 영향을 주었던가요?

처음엔 ISO/IEC 9899 를 ISO/IEC TR 10176 을 근거로 접근하려다
normative reference 가 아니라 무의미하다고 답변 드리니 이제는
반대로 C 프로그램과는 아무런 관련도 없는 표준을 C 표준을 근거로
해석해 보시겠다는 말씀이시군요.

ISO/IEC TR 10176 에 대한 이야기라면 현재 C 표준에서 normative
reference 로 포함하지 않는 이상 C 표준과 무관하므로 관심 없습니다.
ISO/IEC TR 10176 열심히 공부하셔서 나중에 제가 관심 있을 때 전문가
로서 도움주시면 좋겠습니다.

> correct program의 반대 개념은 어디 갔습니까?
>

영어 사전을 찾아보니 correct 의 반대말은 incorrect 라고 하는군요.
표준에 사용된 "correct" 는 일반 영어의 의미를 갖습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
ISO/IEC TR 10176 을 C 표준을 근거로 다시 얘기하시겠다는 뜻인가요?
우리가 지금까지 ISO/IEC TR 10176 에 대해 이야기하고 있었나요? ISO/IEC
TR 10176 이 C 프로그램의 의미에 영향을 주었던가요?

글이 안 기억나시는 모양인데요, 다시 인용합니다.
Quote:
애초에 잘못된 프로그램 구조의 정의를 5.1.1.1 에서 찾으려고 했었습니다.
그러나 잘 연결이 안 됐습니다.
ISO/IEC TR 10176:2003(E)에 3.3.1 errors의 정의를 인용하면

로 시작하는 부문에서 했듯이 잘못된 프로그램 구조의 정의를 ISO/IEC TR 10176에서
찾으려 시도했다가 다시 ISO/IEC 9899로 했다는 뜻입니다.

전웅의 이미지

> [...]
>
> 글이 안 기억나시는 모양인데요, 다시 인용합니다.
>
> 인용:
>
> 애초에 잘못된 프로그램 구조의 정의를 5.1.1.1 에서 찾으려고 했었습니다.
> 그러나 잘 연결이 안 됐습니다.
> ISO/IEC TR 10176:2003(E)에 3.3.1 errors의 정의를 인용하면
>
> 로 시작하는 부문에서 했듯이 잘못된 프로그램 구조의 정의를 ISO/IEC TR 10176에서
> 찾으려 시도했다가 다시 ISO/IEC 9899로 했다는 뜻입니다.
>

이미 ISO/IEC TR 10176 에서 C 표준에서 사용하는 용어의 의미를 찾는 것은
불가능하며 (다시 말해, ISO/IEC TR 10176 에서 C 표준이 사용하는 용어를
정의, 설명해 주고 있다고 해도 이는 C 표준과 무관한 정의, 설명임을
C 표준 스스로가 분명히 하고 있습니다), 따라서 C 표준에 대한 이야기를
나누는 이 논의에서 불필요한 과정임을 지적해 드린 바 있습니다.

이 논의와 무관하게 "correct program" 에 대한 의미에 대해 보다 깊이
있게 탐구하기 위해 ISO/IEC TR 10176 을 뒤적이고 계신 것이라면, C 표준
과는 무관한 문맥의 글임을 분명히 하기 위해 관련 내용을 독립된 글로
포스팅하시면 됩니다.

또한, 말씀드렸듯이 "저는" ISO/IEC 9899 (C 표준) 가 ISO/IEC TR 10176 을
normative reference 로 삼지 않는 이상 ISO/IEC TR 10176 에는 관심
없습니다.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
그리고 제 영어
(영한/영영) 사전은 "erroneous" 의 동의어로 wrong 과 incorrect 를,
한국어 의미로 "잘못된"을 보여주고 있습니다.

erroneous의미를 문제삼은 적 없지만 이것도 오류라는 단어가 있는 상태에서 적절한
단어가 아니라고 생각합니다.

다른 관련 것들도 표준 관련 문서를 볼수록 의문점이 많지만 나중으로 미루도록 하고,
다시, 잘못된 프로그램 구조로 돌아가서 얘기하면, 문법성 오류를 구조의 잘못이라고 한데
있습니다. construct 라는 의미에 사전적으로 구조의 의미도 있습니다. 사전적인 의미에서
architecture, structure, construct 모두 구조로 번역할 수 있습니다. 그러나 그냥 사전에
있는 한 단어를 대치하는 것이 번역이 아니라는 사실을 잘 아시듯이, 문맥을 살려줘야 합니다.
C 표준에서 construct는 분명 구문, 의미상 규칙으로 이루져 있음을 알고 있습니다. 이것은
언어를 구성하는 요소로서 말하고 있는 것입니다.
6.2.7p3에서

Quote:

A composite type can be constructed from two types that are compatible

6.4.4.4p12
Quote:

The construction '\0' is commonly used to represent the null character.

표준에서 program structure란 단어가 분명히 있기 때문에 번역할 때는 이 둘과 구분해
줘야 합니다.

참고로 한국정보통신기술협회(TTA)에서 정의한 언어 구성소는 다음과 같습니다.

Quote:

언어 구성소 [ 言語構成素, language construct A ]
프로그램 언어를 기술할 때 필요한 구문상의 구성 요소. 식별자, 명령문, 모듈 등이 있다.

영어를 그대로 쓰지 않았을 경우에는 그에 합당한 번역을 해 줘야 하는 것입니다.
제가 처음에 Architecture적인 의미로 듣고 의문을 제기하는 것은 합당하다고 생각합니다.

language lawyer적인 측면에서 문제를 고민하신다면, 번역을 생각하신다면 분명 부딛칠
문제입니다. 그것이 아니라면 상관없습니다.

전웅의 이미지

따로 답변드렸다가 depth 가 깊어져 글 3개를 모아 아래에서
답변 드립니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:

"정의되지 않은 행동"이 결론이기 때문에 정의되지 않은 행동에 의존하는 프로그램은
말 그대로 정의되지 않은 것입니다.

4.3에 의해서 conforming program에 해당되지 않고, 4.5에의해 strictly conforming program에
해당되지 않는다고 말할 수 있겠네요.
전웅의 이미지

> > "정의되지 않은 행동"이 결론이기 때문에 정의되지 않은 행동에 의존하는 프로그램은
> > 말 그대로 정의되지 않은 것입니다.
>
> 4.3에 의해서 conforming program에 해당되지 않고, 4.5에의해 strictly conforming program에
> 해당되지 않는다고 말할 수 있겠네요.
>

그만하십시오. 이젠 측은하기까지 합니다.

4p3 에 의해 correct program 에 해당되지 않고, 4p5 에 의해 strictly
conforming program 에 해당될 순 없지만, (님이 아직 보지 못하신) 4p7 에
의해 구현체에 따라 conforming program 에 해당될 순 있습니다.

4p7 에서 정의된 형태를 보시면 아시겠지만, conforming 과 correct 는
표준에서 같은 뜻으로 쓰이는 용어가 아닙니다. 표준은 program 을
수식하는 conforming 에 배제적인 의미를 부여해 사용하고 있습니다.

참고로, 표준을 인용할 때 . 은 subclause 번호를 분리할 때만 사용합니다.
각 문단 앞의 번호는 말 그대로 문단 번호로, 인용할 때는 # 나 p 혹은 /
등 . 가 아닌 기호를 사용하는 것이 관례입니다. 4p5 를 4.5 라고 인용해
놓으시면 표준에 익숙한 사람들은 4장의 5번째 문단이 아닌 4.5절을 찾으려
하게 됩니다.

혹시라도 표준에 관심이 생겨 공부하시다가 궁금한 부분 있으면 "메일"로
문의 주시기 바랍니다 (개인적인 사정으로 현재 진행 중인 두 쓰래드
마무리되는 대로 KLDP 에 더 이상 글 쓸 생각은 없습니다). 게시판에서
서로 감정 세운건 세운거고 공부하면서 도와주는건 별개의 문제지요.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

경의 이미지

Quote:
그만하십시오. 이젠 측은하기까지 합니다.

전 오래전에 측은하게 느꼈습니다. :)

Quote:

p3 에 의해 correct program 에 해당되지 않고, 4p5 에 의해 strictly
conforming program 에 해당될 순 없지만, (님이 아직 보지 못하신) 4p7 에
의해 구현체에 따라 conforming program 에 해당될 순 있습니다.

4p7을 읽고 바꾸려던 참이였습니다(포스팅이 한 참 후에 확인이 되어서, 지금 op code cache
program 때문인 것 같은데 포스팅에 문제가 있습니다.).
이 부분은 제가 아는 척해서 죄송합니다. 너무 성급하게 표준 문서를 먹다가 체했다고
생각하시길.

Quote:

The twoforms ofconforming implementationare hosted and freestanding. Aconforming
hosted implementation shall accept any strictly conforming program. Aconforming
freestanding implementationshall accept anystrictly conforming program that does not
use complextypes and in which the use of the features specified in the library clause
(clause 7) is confined to the contents of the standard headers ,
, , , , , and
. Aconforming implementation may have extensions (including additional
library functions), provided theydonot alter the behavior of anystrictly conforming
program.3)

4p6에 따르면 printf의 undefined behavior에 해당하는 것을 conforming program
이라고 정의한 것이 없습니다.

Quote:

참고로, 표준을 인용할 때 . 은 subclause 번호를 분리할 때만 사용합니다.
각 문단 앞의 번호는 말 그대로 문단 번호로, 인용할 때는 # 나 p 혹은 /
등 . 가 아닌 기호를 사용하는 것이 관례입니다. 4p5 를 4.5 라고 인용해
놓으시면 표준에 익숙한 사람들은 4장의 5번째 문단이 아닌 4.5절을 찾으려
하게 됩니다.

알겠습니다.

Quote:

혹시라도 표준에 관심이 생겨 공부하시다가 궁금한 부분 있으면 "메일"로
문의 주시기 바랍니다 (개인적인 사정으로 현재 진행 중인 두 쓰래드
마무리되는 대로 KLDP 에 더 이상 글 쓸 생각은 없습니다). 게시판에서
서로 감정 세운건 세운거고 공부하면서 도와주는건 별개의 문제지요.

그럼...


완전함에 대한 야망이 높다는 것은 좋은 것입니다.
그러나 감정을 세울 필요가 없는 사안입니다.

전웅의 이미지

[너무 답변의 depth 가 깊어져 독립된 글처럼 올립니다]

> 제가 그렇게 되어 있다고 한 것은 Information Part라고 명시된 곳이 어디냐고
> 의문을 제기하는 것입니다.
> 이것은 애초에 인용을 하고 얘기 했으면 불필요한 것입니다.

인용해서 한번에 보일 수 있는 내용이었다면 그랬을 것입니다. 님께서는
줄곧 말도 안되는 주장을 들고 오시고, 전 그에 대한 근거를 들어가며
틀린 부분을 설명하고, 또 님은 어디선가 엉뚱한 주장을 들고 오시고...
저도 직업이 있고 할 일이 있는 사람입니다. 이젠 알아서 찾아보시기
바랍니다.

참고로 오래전 뉴스그룹에서 저 역시도 clause/subclause 제목을
normative text 로 보아야 한다고 잘못 주장했던 사람이랍니다. 그
글이라도 찾으신다면 도움이 될지 모르겠군요. 당시 논의에서는 C 표준
편집자가 직접 답변한 바 있습니다.

> 4. Conformance가 Normative인데 아니란 말씀이세요?
>

대체 무슨 말씀이신지... 4장의 내용을 이해하는데 Conformance 라는
제목이 강제적 기능을 하는 부분이 없다는 뜻입니다. 즉, 이상적으로 볼
때 (참조를 위해) 4 라는 숫자만 남기고 Conformance 라는 부분을 삭제
해도 무방하다는 뜻입니다. 사실, subclause 의 경우 글로 제목을
쓰라고 요구하지도 않습니다.

> unspecified behavior를 갖는 correct program이 strictly conforming program을
> subset 으로 가진다고 얘기하는 것입니까?
>

더 이상 설명 안하겠습니다. 얼마나 될지는 모르겠지만 제 글 읽는 다른
분들은 벌써 이해하셔도 한참 이해하셨을 것입니다. 님의 이해력을 문제
삼는 것은 아닙니다. 저의 인내력이 한계에 도달한 것입니다.

지금까지 수차례 설명드렸고, 표준도 보고 계시고, 설명한 책도 알려
드렸고... 이젠 직접 공부하고 직접 이해하시기 바랍니다. 님이 잘못 이해
한다고해서 진실이 변하는 것도 아니고, 표준에 문제가 생기는 것도
아니고, 제 밥벌이에 이상이 생기는 것도 아닙니다.

지난 글에 답변 드렸듯이, 위 언급된 용어들의 개념은 스스로 세우시기
바랍니다. 밥상 차려드렸으면 충분하지 떠먹여드릴 필요까지는 없다고
생각합니다.

> 반대 의미의 구체적인 정의가 없는 상태에서 세운 정의의 문제점을 얘기한
> 것입니다. "표준에서 correct program에 대한 정의를 분명히 했다"라는 주장을
> 염두해 두겠습니다.

??? 표준 수준의 "정의"(3장에서 정의/이탤릭체 표시/문법 상의 정의)가
이루어졌다고 말씀드린 적 없습니다 - 아래에서도 말씀하셨듯이 오히려
반대라고 설명드린 바 있습니다. 제가 다분히 의도적으로 "correct
program 을 설명하다, 기술하다" 등의 표현을 쓰고 있음에 주목하시기
바랍니다.

> incorrect의 의미에 잘못된만 있는 것이 아닙니다.

영어 사전을 새로 쓰실 생각인가 보군요.

> "not conforming with accepted standards of propriety or taste"라는
> 의미도 있습니다.

대체 무슨 말씀을... ??? (incorrect 의 반대말이며 실제 표준에 언급된
표현인) "correct" 의 의미를 표준이 님이 말씀하신 뜻으로 따로 정의
혹은 기술하고 있는 부분이 있습니까? 지난번 보여드린 순서에 따라
"corrrect" 는 일반 영어의 뜻을 갖게 되며 영어에서 "incorrect" 는 "not
correct" 의 의미입니다. 그런 의미의 "correct program" 에 대해 표준은
undefined behavior 를 가질 수 없는 프로그램이라고 설명하고 있는
것입니다. 바로 이 전 글에서 나눈 이야기가 표준에 나온 용어를 해석하는
방법에 대한 것이 아니었던지요? --;

> 그리고 프로그램과 프로그램 구조를 같로 통용된다고 하셨는데 분명히 program
> 이란 단어와 구분되는 program construct, program structure라는 단어가
> 있습니다. 이 혼돈을 어떻게 하시겠습니까?
>

일반적으로 통용되는 의미를 따질 때 program construct 는 program 의
의미적인 한 부분을 가리키는데 사용됩니다. 하지만, 잘못된 프로그램
구조를 포함하는 프로그램이 곧 잘못된 프로그램이 될 수밖에 없기에
undefined behavior 를 설명할 때는 그 둘의 차이를 크게 두지 않습니다.
혹시, "correct program 은 아니지만, correct program construct 이
될 수는 있다" 내지는 "incorrect program 일 순 있지만, incorrect
program construct 인 것은 아니다" 라는 주장을 하고 계시는 것은
아니리라 믿습니다. 저는 상식적 수준의 대화가 가능한 분과 이야기를
나누고 싶습니다.

> 그렇다면 용어집에 없을 테니 사전적인 의미로 incorrect program construct/incorrect
> program structure/incorrect program을 구분해 보시기 바랍니다.
>

분명 또 이런 쓸모없는 이야기를 끌고 오실까봐 지난 글에서 중요한 것은
"incorrect" 라고 강조를 드렸는데도, 왜 아무도 언급하지 않은
"structure" 까지 끌고 들어오시는지요? "incorrect" 에 대해서 하실 말씀
이 점점 없어지니 이젠 다른 부분을 걸고 넘어가시겠다는 뜻인가요?
undefined behavior 를 포함하는 프로그램이 올바른 프로그램 아니라는
사실을 설명하는데 위에서 말씀하신 구분은 필요 없습니다. 저런 것 구분
하는게 취미라면 혼자 하시기 바랍니다.

> erroneous program constructs에 대한 것까지 고려한다면 더욱 좋겠습니다.

점입가경입니다.

> 아 용어집에 있다면 죄송합니다. 제가 ISO/IEC 2382-1까지는 아직 못 봐서요.
> program structure는 correct program처럼 이미 있으니 program structure에 없는 것을
> 포함하면 incorrect program structure를 기술했다고 생각해야 하나요?
>
> [...]
> incorrect 에서 not correct 로 가는 것은 조금 나은 듯합니다.
> 그러나 그렇게 기술하는데 문제가 전혀 없다고 얘기한다는 입장을 염두해 두겠습니다.

솔직히 이젠 웃음이 나오고 있습니다. 전 제 능력 한도 내에서 처음
문제 제기가 되었던 부분에 대해서 충분히 설명드렸습니다. 님이
incorrect 와 not correct 의 개념을 어떻게 이해하시는지, program 과
program construct, program structure 의 개념을 어떻게 이해하는지는
제 관심사 밖입니다.

> 위원회의 강조하려는 의도라면 왜 분명히 conforming program처럼 이탤랙채로
> 정의하지 않았단 말입니까? 그리고 이식성을 강조해서 strictly conforming
> program을 만들어 놓고 왜 correct program이라고 정의하지 않았겠습니까?
> 또 correct와 conforming이 관련 없다고 말한 것을 잊으셨습니까?
>

설마 "strictly conforming program 이 correct program 의 subset 이라고
해놓고 왜 correct ... 와 (strictly conforming 에서 strictly 만을 뺀)
conforming ... 은 관련 없다고 하느냐" 라고 묻고 계신 것인지요?

그렇게 물으신게 맞다면, 님은 ISO 표준 같은 기술 문서를 제대로 읽고
이해하는 기본 방식도 가지고 계시지 못한 것입니다. 지금 이 자리가
"ISO 표준 읽기" 강의 시간도 아니고 제가 그런 것까지 모두 설명드릴
수는 없습니다. 그렇게 물으신게 아니라면 마지막 질문이 이해가 되지
않습니다.

correct program 의 정의 문제는, 표준은 conformance category 를 애초에
최대한의 이식성을 얻을 수 있는 strictly conforming program 과
이식성과 전혀 무관하지만 사람들을 만족시키기 위한 용어인 conforming
program 으로 나누고자 한 것 뿐입니다. 따라서 두 용어는 배타적인 개념
으로 정의하고 있는 것입니다. 그리고 "correct program" 을 언급하는
문장을 통해 표준이 어떤 프로그램을 표준 관점에서 "correct program"
으로 보고자 하는지를 설명하고 있는 것입니다. 따라서 correct program
은 엄격한 의미의 conformance category 가 아니라 correct/incorrect
program 을 바라보는 표준의 입장을 기술하기 위해 사용된 용어로 보시면
됩니다.

표준화 위원회 멤버 중 한 명인 Clive Feather 가 C99 표준을 제정하는
과정에서 unspecified behavior/implementation-defined behavior 의
의미를 보다 명확히 하기 위해 각 behavior 의 개념을 정리해 제출한 글이
있습니다. 그 글을 보시면 표준이 "correct program" 이라는 표현을 통해
무엇을 표현하려 했는지 조금이라도 더 이해하실 수 있습니다.

흠... 뭐, 이렇게 설명을 드리면 뭐하겠습니까. 어차피 또 엉뚱한 소리로
다 흐려 놓으실텐데요. 더 이상 님이 이해하시고 마시고는 제게 중요한
문제가 아닙니다. 혹시라도 이 글을 읽으시는 다른 분들이 진실/거짓을
구분하실 수 있게 된다면 저로서는 만족합니다.

> erroneous program constructs에서 잘못된 프로그램 구조를 찾다가 4p3에서
> 찾은 correct program에 애써 맞추려고 노력 많이 하셨습니다.
> 아직까지 납득할만한 레퍼런스도 주장도 찾을 수 없습니다.
>

넵, 지금까지 이야기 나눈 사람 중에 가장 의사 전달이 어렵고 고집불통인
분에게 마이동풍 격으로 많은 내용을 떠들기 위해 노력도 많이 했습니다.

처음엔 어느 정도 설명과 각종 참조할 만한 것들을 드리면 님께서도
이해하실 수 있으리라 믿었습니다. 하지만, 이젠 님이 이해하고
못하고를 떠나 이 주제에 대한 포스팅을 마무리하려 합니다.

님과 긴 이야기를 나누다가 혹시나 아래와 같은 이유로 님께서 "undefined
behavior 를 포함한 프로그램이 잘못된 프로그램은 아니다" 라는 입장을
포기 못하시는 것은 아닐까 하는 생각이 들어 마지막으로 정리해
남깁니다.

애초부터 님께서 "실제로는 undefined behavior 를 품은 프로그램도
일반적인 개념으로 올바른 프로그램이라고 불릴만큼 많이 존재하고 또 그
역할을 충분히 하고 있지 않느냐" 고 주장하셨다면, 충분히 동의했을
것입니다. 말씀드린 바 있듯이 엄격한 표준 안에서 만든 프로그램은 그
유용성에 의심이 많이 가는 것이 분명한 사실입니다. 따라서 그와 같은
견해가 가능하도록 "conforming program" 의 개념이 존재하는 것입니다.
즉, 이때 나온 "올바른 프로그램"이라는 표현은 표준 관점에서
"conforming program" 에 해당 하는 것으로 볼 수 있습니다.

하지만, 표준을 고려했을 때 "undefined behavior 를 포함한 프로그램도
올바른 프로그램이 될 수 있다" 내지는 동일한 관점에서 "undefined
behavior 를 포함한 프로그램이 잘못된 프로그램은 아니다" 라고 말씀
하신다면 이는 지금까지 설명드렸듯이 분명히 거짓인 명제가 됩니다.

어쩌면 님이 (표준의) conforming program 으로서의 "올바른 프로그램"
을 말씀하시려다 표준에 대한 경험이 부족한 탓에 논의가 (표준의)
correct program 으로서의 "올바른 프로그램" 을 이야기하는 쪽으로 기운
것은 아닐까 추측해 봅니다 - 저로서는 님께서 애초부터 표준에서의
근거를 찾으셨기에 님이 conforming program 으로서의 "올바른 프로그램"
을 주장했을 수도 있다는 가능성을 포함시키지 못했습니다.

어쨌든 최소한 한 분은 이 지리한 논의 과정에서 도움을 얻으셨다니 전
충분히 만족스럽습니다.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
대체 무슨 말씀이신지... 4장의 내용을 이해하는데 Conformance 라는
제목이 강제적 기능을 하는 부분이 없다는 뜻입니다. 즉, 이상적으로 볼
때 (참조를 위해) 4 라는 숫자만 남기고 Conformance 라는 부분을 삭제
해도 무방하다는 뜻입니다.

제가 저 위에 인용했지만 다시 인용합니다.

Quote:
5.2.2 Clause
A clause is the basic component in the subdivision of the content of a document.
The clauses in each document or part shall be numbered with Arabic numerals, beginning
with 1 for the “Scope” clause. The numbering shall be continuous up to but excluding any
annexes (see 5.2.6).
Each clause shall have a title, placed immediately after its number, on a line separate from
the text that follows it.

전웅의 이미지


> > 대체 무슨 말씀이신지... 4장의 내용을 이해하는데 Conformance 라는
> > 제목이 강제적 기능을 하는 부분이 없다는 뜻입니다. 즉, 이상적으로 볼
> > 때 (참조를 위해) 4 라는 숫자만 남기고 Conformance 라는 부분을 삭제
> > 해도 무방하다는 뜻입니다.
>
> 제가 저 위에 인용했지만 다시 인용합니다.
>
> 5.2.2 Clause
> A clause is the basic component in the subdivision of the content of a document.
> The clauses in each document or part shall be numbered with Arabic numerals, beginning
> with 1 for the “Scope” clause. The numbering shall be continuous up to but excluding any
> annexes (see 5.2.6).
> Each clause shall have a title, placed immediately after its number, on a line separate from
> the text that follows it.
>

으... 님! 제발 좀 제가 쓴 문장이 무슨 뜻인지 천천히 읽어 보신 후에
완전히 이해했다고 생각이 들면 글을 남기시길 부탁드립니다. Conformance
라는 제목을 표준 문서에서 삭제해도 된다는 뜻이 아니라, 제목은
provision 이라기 보다는 다른 provision 들을 이해하는 것을 돕는
informative 요소이기 때문에 사실상 conformace 라는 title 이 없어도
다른 부분을 이해하는데 아무런 문제가 없다는 뜻입니다!

그리고 인용을 하시려면 온전히 다 하시지 왜 아래 부분은
빼놓으시는지요?

제가 쓴 글 나머지 부분:
] 사실, subclause 의 경우 글로 제목을 쓰라고 요구하지도 않습니다.

즉, clause 의 경우 title 을 써야 하지만, subclause 의 경우 title 없이
번호만 붙이는 것도 가능하다는 것을 말씀드린 바 있습니다. 표준이
clause 와 subclause 를 구분하고 있다는 것은 알고 계시리라 믿습니다.

아직도 뭐가 더 남아 있습니까?

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

제가 처음에 말한 것을 인용한 것입니다.

Quote:

5.2.2에서 나와 있듯이 문서의 내용을 구분하는 기본적인
컴포넌트입니다.

문서의 내용을 구분하는 기본적인 컴포넌트이기 때문에 관련성을 강조한 것입니다.

Quote:

그리고 인용을 하시려면 온전히 다 하시지 왜 아래 부분은
빼놓으시는지요?

Clause 에 대해서 처음부터 얘기했느데 무슨 엉뚱한 소리세요?
Quote:

즉, clause 의 경우 title 을 써야 하지만, subclause 의 경우 title 없이
번호만 붙이는 것도 가능하다는 것을 말씀드린 바 있습니다. 표준이
clause 와 subclause 를 구분하고 있다는 것은 알고 계시리라 믿습니다.

왜 관련없고 이미 아는 내용을 자꾸 보태세요.
표준에 있는 말로 레퍼런스를 들 경우만 인정하겠습니다.
전웅의 이미지

> 5.2.2에서 나와 있듯이 문서의 내용을 구분하는 기본적인
> 컴포넌트입니다.
>
> 문서의 내용을 구분하는 기본적인 컴포넌트이기 때문에 관련성을 강조한 것입니다.
>

그 관련성이 님이 생각하시는 것처럼 그렇게 강력하지 않음을 말씀드린
것입니다.

> > 그리고 인용을 하시려면 온전히 다 하시지 왜 아래 부분은
> > 빼놓으시는지요?
>
> Clause 에 대해서 처음부터 얘기했느데 무슨 엉뚱한 소리세요?
>

제 문장의 한 문장을 빼고 인용하신 것에 대해 드린 말씀입니다. 마지막
문장을 보면 제가 Conformance 라는 제목을 실제 표준에도 빼도
무방하다는 뜻이 아닌, Conformance 라는 제목을 무시하고 나머지 내용을
이해해도 무방하다는 뜻으로 기술했다는 것을 분명히 알 수 있기
때문입니다 - 단, 표준이 clause 와 subclause 를 구분하고 있다는 사실을
안다는 전제 아래 그렇습니다.

> > 즉, clause 의 경우 title 을 써야 하지만, subclause 의 경우 title 없이
> > 번호만 붙이는 것도 가능하다는 것을 말씀드린 바 있습니다. 표준이
> > clause 와 subclause 를 구분하고 있다는 것은 알고 계시리라 믿습니다.
>
> 왜 관련없고 이미 아는 내용을 자꾸 보태세요.
>

바로 위 제 답변을 보시면 어떤 점에서 관련이 있는지 설명드렸습니다.

> 표준에 있는 말로 레퍼런스를 들 경우만 인정하겠습니다.
>

무엇에 대한 레퍼런스 말씀이신지요? 표준이 clause 와 subclause 를
구분한다는 것이요? 아니면 subclause 의 경우에는 실제 표준 문서에서
title 을 생략해도 무방하다는 것이요?

왜 제가 님의 이해를 위해 문서를 찾아 인용해야 하는 수고를 해야 하는지
모르겠습니다. 전 님이 올바르게 이해하든 그렇지 않든 상관 없습니다.
(더러워진 글이지만) 이 글을 읽을 다른 분들을 위해 마지막까지 답변을
쓰고 있는 것 뿐입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
마지막 문장을 보면 제가 Conformance 라는 제목을 실제 표준에도 빼도
무방하다는 뜻이 아닌, Conformance 라는 제목을 무시하고 나머지 내용을
이해해도 무방하다는 뜻으로 기술했다는 것을 분명히 알 수 있기
때문입니다 - 단, 표준이 clause 와 subclause 를 구분하고 있다는 사실을
안다는 전제 아래 그렇습니다.

4. Conformance 에서 Conformance가
Informative Part가 아니라는데 인정하신다는 것입니까?

전웅의 이미지

> [...]
>
> 4. Conformance 에서 Conformance가
> Informative Part가 아니라는데 인정하신다는 것입니까?
>

아닙니다.

스스로의 글을 인용하시는 것을 보면 단기 기억 상실증에 걸리신 것도
아니신 듯 한데 왜 자꾸 한번 나왔던 이야기를 다시 끌고 나오십니까?
죄송하지만, 전 하나도 심심하지 않습니다. --;

http://kldp.org/node/81963/390454

이젠 무엇을 위해서 님과 글을 주고 받으며 게시판을 더럽히고 있는지
의미도 없는 것 같습니다.

오해가 있었으면 오해가 있었다 인정하시면 되는 부분이고, 확신이 서지
않거나 납득이 되지 않는 부분은 (제가 드릴 수 있는 설명은 다
드렸으므로) 스스로 찾아 공부하시면 됩니다 (도움이 되는 자료를 찾는데
필요한 힌트는 이미 여러개 드린 것으로 기억하고 있습니다).

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

4. Conformance를 informative 로 말한 것이 틀렸다고
이미 규정을 보여드리고 말한 것으로 제 역할은 다 했습니다.

Quote:
강제하는 장치가 아니라는데는 동의하지만 아주 심각하게 리뷰를 거친 결과라고 생각
합니다.

에서 말했듯이 내용관련 문제는 계속 거론할 필요 없습니다.
전웅의 이미지

> 4. Conformance를 informative 로 말한 것이 틀렸다고
> 이미 규정을 보여드리고 말한 것으로 제 역할은 다 했습니다.
>

ISO/IEC Directives 의 informative annex 인 Annex C 를 인용한 것을
말씀하시는지요? Annex C 의 내용이 의미하는 바가 clause/subclause
제목이 normative 임을 말하는 것이 아니라고 이미 설명드린바 있습니다.

더구나, informative 로 명시되어 있는 annex 는 없다고 가정해도 해당
문서의 요구 사항에 변화가 없는 부분입니다. 그런 부분이
clause/subclause 제목이 normative 라는 규정(provision)을 포함할 수는
없습니다.

informative/normative 를 논하시기 전에 그 진정한 의미부터 다시 생각해
보면 좋겠습니다.

표준의 normative 부분은 표준의 한계 범위인 scope 를 설정하는 부분과
표준의 핵심적인 요구 사항을 기술하는 provision 으로 구성됩니다.
informative 부분은 그와 같은 표준의 핵심 내용에 참고 자료를 더하거나,
내용을 소개 혹은 도입하거나, 오해의 여지를 없애기 위해 보충하는 역할을
하게 됩니다. informative + normative text 가 온전한 표준을 구성하게
되며, informative 라 할지라도 잘못된 부분이 있다면 이상적으로는
수정되어야 합니다.

하지만, normative text 에서 전달하고자 하는 바가 분명한 가운데
informative 에 (실수로라도) 잘못된 내용이 포함되어 normative text 와
상충된다면 우선적으로는 normative text 를 취하고 informative 를 버리는
것이 올바른 접근 방법입니다.

표준 해석시 informative 부분이 normative 부분의 애매모호함을 해결해
주는 일은 종종 있으며, informative/normative 의 엄격한 구분이 표준
해석에 큰 역할을 하는 경우는 많지 않지만, 가끔이나마 의도(intent)의
경중을 가늠하기에 유용한 경우는 있습니다.

> > 강제하는 장치가 아니라는데는 동의하지만 아주 심각하게 리뷰를 거친 결과라고 생각
> > 합니다.
>
> 에서 말했듯이 내용관련 문제는 계속 거론할 필요 없습니다.

다른 말씀드린 적 없습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
ISO/IEC Directives 의 informative annex 인 Annex C 를 인용한 것을
말씀하시는지요? Annex C 의 내용이 의미하는 바가 clause/subclause
제목이 normative 임을 말하는 것이 아니라고 이미 설명드린바 있습니다.

더구나, informative 로 명시되어 있는 annex 는 없다고 가정해도 해당
문서의 요구 사항에 변화가 없는 부분입니다. 그런 부분이
clause/subclause 제목이 normative 라는 규정(provision)을 포함할 수는
없습니다.


Annex C(Informative)라고 한 것은 이 그림을 보충하는 문서가 Informaitve한 것이라는
뜻입니다. 왜냐면 이미 그 내용은 본문에 있기 때문입니다.
Normative general elements만 있고 normative technical elements가 없는 표준을
만들 이유가 무엇이라고 생각하십니까?
modestcode의 이미지

clause는 없을 수 없고 subclause 제목을 그럴 수 있다는 것을 기술한 Directives 문서에서
바로 이 부분이 normative technical elements 인 것입니다.

전웅의 이미지

> > ISO/IEC Directives 의 informative annex 인 Annex C 를 인용한 것을
> > 말씀하시는지요? Annex C 의 내용이 의미하는 바가 clause/subclause
> > 제목이 normative 임을 말하는 것이 아니라고 이미 설명드린바 있습니다.
> >
> > [...]
>
> Annex C(Informative)라고 한 것은 이 그림을 보충하는 문서가 Informaitve한 것이라는
> 뜻입니다. 왜냐면 이미 그 내용은 본문에 있기 때문입니다.
> [...]

Annex C 이든, Annex C 에 대응하는 normative text 이든 그 부분은
(sub)clause 의 제목을 normative text 로 만들어 주는 부분이 아닙니다 -
제 글의 핵심은 2번째 문단이 아니라 위에서 인용한 첫 번째 문단에
있습니다.

"conforming program" 의 표준 정의가 exclusive 하다는 점을 고려할 때 이
문제가 "correct program" 과 관련된 논의에 주는 영향은 없더라도, 언급된
내용에 대해 말씀드리자면,

> clause는 없을 수 없고 subclause 제목을 그럴 수 있다는 것을 기술한 Directives 문서에서
> 바로 이 부분이 normative technical elements 인 것입니다.
>

Directives 는 clause 1, 2 가 담는 내용이 Scope, Normative reference
여야 한다는 점과 그 외의 각 clause 는 제목을 "가져야 한다는 사실"만을
강제할 뿐입니다. 누구든 아이를 하나 이상 가져야 한다는 단순한 요구가
그 아이가 남아인지 여아인지에 대한 요구가 될 수는 없는 것처럼, 제목을
가져야 한다는 요구가 제목의 "내용"이 그 자체만으로 provision 에
해당함을 의미하는 것은 아닙니다 - normative element 와 informative
element 의 정의를 포함해 provision 에 대해 좀 더 고민해보시기
바랍니다.

그리고 무엇보다도 저는 더 이상 님과 표준 (sub)clause 제목의
normative/informative 여부를 논하는 것 자체에 흥미 없습니다. 현재 님이
ISO/IEC Directives 를 이해하고 계신 수준과 지금까지 님과 저 사이의
토론 과정을 생각할 때, 더구나 상당히 수용적인 자세를 가지고 있는 제가
이 내용을 완전히 이해하는데 들인 시간을 고려할 때, 제가 말씀드리고
싶은 바를 님이 납득할 정도로 전달하려면 앞으로 십수번에 걸친 포스팅을
수일동안 진행해야 할 것 같습니다. 전 님을 위해 그런 정성을 쏟을
생각도, 힘도, 시간도 없습니다.

단적인 예를 하나 말씀드리자면, 표준화 위원회는 (사소하지만 분명 문제가
될 수 있는) 표준 (sub)clause heading 에 대한 수정 요청에 대해 표준의
나머지 부분을 이해하는데 문제가 되지 않는다는 의견과 함께 거절한 경우
가 대부분입니다. 이는 normative text 의 아주 사소한 문제라도
수정하는데 망설이지 않는 위원회가 (sub)clause 제목을 어떻게 생각하고
있는지 보여주는 예입니다.

다소 일방적이라 죄송스럽지만 이것이 제 마지막 글입니다. 님의 글에 대한
더 이상의 대응은 게시판을 지저분하게 한다는 사실을 제외하면 제게 아무
의미가 없습니다. 저는 자고 일어나 또 돈벌러 가야겠습니다. 열심히
공부하시기 바랍니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
Directives 는 clause 1, 2 가 담는 내용이 Scope, Normative reference
여야 한다는 점과 그 외의 각 clause 는 제목을 "가져야 한다는 사실"만을
강제할 뿐입니다.

어떻게 구성돼야 하는 지는 5. Structure에서 설명하고 있습니다.
특히 5.1.3의 table 2가 보기 좋을 것입니다.
Informative Part 라고 했을 때 Part도 Clause /Subclause/Paragraph 등의 일종인 걸
깨닫게 되시면 4.Conformance에 사용할 수 없다는 것도 아시게 될 것입니다.

건투를 빕니다.

전웅의 이미지

> Informative Part 라고 했을 때 Part도 Clause /Subclause/Paragraph 등의 일종인 걸
> 깨닫게 되시면 4.Conformance에 사용할 수 없다는 것도 아시게 될 것입니다.

제가 쓴 글:
] normative element 와 informative element 의 정의를 포함해 provision
] 에 대해 좀 더 고민해보시기 바랍니다.

라고 말씀을 드리면 그래도 한번은 찾아보시기 않을까 생각했습니다 :-(

ISO/IEC 9899:1999 drafting 에 사용된 ISO/IEC Directives part 3 - 1997
에서 인용합니다:

Quote:

3. Terms and definitions

...

3.4
normative elements

those elements setting out the provisions to which it is necessary to
conform in order to be able to claim compliance with the standard

...

3.8
provision

expression in the content of a normative document, that takes the form
of a statement, an instruction, a recommendation or a requirement

NOTE These types of provision are distinguished by the form of wording
they employ; e.g. instructions are expressed in the imperative mood,
recommendations by the use of the auxiliary "should" and requirements
by the use of the auxiliary "shall".

...

6.6.1 Verbal forms for the expression of provisions

6.6.1.3 Annex E gives, in the first column of each table, the verbal
form that shall be used to express each kind of provision. [...]

...

Annex E
(normative)
Verbal forms for the expression of provisions

shall, shall not, should, should not, may, need not, can, cannot 과
그 명확한 의미 기술

이 과정이 Directives 의 가장 엄격한 해석을 적용한 것입니다. 하지만,
이렇게 해석하면 C 표준 해석에 다소 지나친 비약이 발생하게 됩니다. 그
비약을 표준화 과정에 있었던 편집 상의 사건을 언급하며 합리적으로
설명하고 이해하는 과정이 만만치 않아 위의 과정을 스스로 찾아가며
알게 되시길 바랬습니다만, 제 조언에도 불구하고 그러시지 않는 것 같아
(마지막 글이라는 제 말을 번복하는 쪽팔림을 무릅쓰고) 이렇게 글
남깁니다.

사실 Directives 를 이렇게까지 이해하는 것이 C 언어의 기술적인 부분을
올바르게 이해하는데 큰 도움이 되지는 않습니다. --;

이젠 진짜로 코 자러 갑니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

애초에 제기된 문맥과 자꾸 동떨지느데요,
provision이 보여주기 위한 구성 요소로 normative elements 를 사용하고 있습니다.
normative elements 에는 general/technical 이 있고요.
general 안에 scope/normative reference가 있고 technical 안에 option으로 terms and definitions
와 같은 것을 둘 수 있고 scope에 맞게 이름을 지어서 넣을 수 있습니다.
구리니까 techical 안에 본문이 들어간단 말입니다. 이름을 어떻게 지어라고 한 것이 normative 라고 한 적이
있습니까? 4. Conformance 가 이름이 없으면 안되는 normative elements 라고 했죠.
애초에 시작된 주제에서 왜 자꾸 벗어나세요.

modestcode의 이미지

물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
nomative 로 Annex D에서 얘기 하고 있습니다.

modestcode의 이미지

Quote:
애초부터 님께서 "실제로는 undefined behavior 를 품은 프로그램도
일반적인 개념으로 올바른 프로그램이라고 불릴만큼 많이 존재하고 또 그
역할을 충분히 하고 있지 않느냐" 고 주장하셨다면, 충분히 동의했을
것입니다.

이미 위에도 나왔지만 논리 전개가 비슷하시군요.
문제를 부정한 후에 긍정하는 것 처럼하고 또 다른 문제를 부정하고 오프타픽거리나
만들고.
저의 애초 주장을 전혀 존중하지 않았기 때문에 그래 표준에서 말하는 것이 무엇이냐
라고 접근한 것입니다.
전웅의 이미지

> > 애초부터 님께서 "실제로는 undefined behavior 를 품은 프로그램도
> > 일반적인 개념으로 올바른 프로그램이라고 불릴만큼 많이 존재하고 또 그
> > 역할을 충분히 하고 있지 않느냐" 고 주장하셨다면, 충분히 동의했을
> > 것입니다.
>
> 이미 위에도 나왔지만 논리 전개가 비슷하시군요.
> 문제를 부정한 후에 긍정하는 것 처럼하고 또 다른 문제를 부정하고 오프타픽거리나
> 만들고.
> 저의 애초 주장을 전혀 존중하지 않았기 때문에 그래 표준에서 말하는 것이 무엇이냐
> 라고 접근한 것입니다.
>

문제를 부정하고 긍정하면서 또 다른 문제를 부정하고... 를 하는 것이
아니라, 인용하신 부분은 제가 제 마지막 글을 정리하면서 님의 억지
주장을 이해할 수 있는 마지막 방법을 찾아본 것 뿐입니다 - 즉, 사실은
억지 주장이 아니라 시작부터 어떤 오해가 있는 것은 아니었을까 하는
생각을 해보게 된 것입니다.

같은 현상, 다른 해석... 세상에 다양한 사람이 존재한다는 것은 알고
있었지만 이토록 넓은 스팩트럼일 줄은 몰랐습니다.

더 이상 기술적인 논의거리가 없다면 서로 추해지는 행동은 그만
자제했으면 합니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

whitenoise의 이미지

두분 다 다음 질문에 답을 해보시면 '잘못된'의 해석에 서로 어떤 차이점이 있는지 알 수 있을 것 같군요.

[질문] 아래 코드는 잘못된 프로그램입니까?

#include <stdio.h>
 
main()
{
    printf("%2$s %1$s\n", "World!", "Hello");
}
익명 사용자의 이미지

그만 두는 게 좋겠습니다.
보기에 너무 안쓰러워요.
modestcode라는 사람은 자기가 무슨 소리를 하는지 자기도 모를걸요.

전웅의 이미지

> 두분 다 다음 질문에 답을 해보시면 '잘못된'의 해석에 서로 어떤 차이점이 있는지 알 수 있을 것 같군요.
>

더 이상 게시판을 더럽히고 싶지 않아 답변을 피하고 싶지만, 차이점을
확인하기 위한 목적이 아닌 순수한 질문에 대한 답변이라 생각하고
말씀드리겠습니다.

> [질문] 아래 코드는 잘못된 프로그램입니까?
>
> #include
>
> main()
> {
> printf("%2$s %1$s\n", "World!", "Hello");
> }
>

n$ 의 확장으로서의 존재를 알고 있는 일반적인 상황에서 물어보신다면
"표준 수준의 이식성 없는 확장을 사용한 프로그램입니다" 라고
말씀드렸겠지만, 현 논의의 주제를 고려해 보다 엄격한 표준의 관점에서
답변드리면,

- $ 가 undefined behavior 에 해당하므로 (strictly conforming program
은 물론) correct program 이 아닙니다.

- 하지만, 해당 확장을 지원하는 구현체에서 conforming program 입니다.

라고 말씀드릴 수 있습니다.

첫번째 문장 때문에 실망하시는 분들이 있을 수 있습니다. 그래서 표준이
(표준 입장에서는 불필요함에도 불구하고) 나름 멋드러진 이름의
conforming program 을 도입해 그런 분들을 위로하고자 하는 것입니다.

n$ 를 확장으로 지원하는 구현체에 익숙한 분들은 이 프로그램을 correct
program 이라고 하지 않는 표준이 이해되기 어려울 수도 있겠지만, 이와
같은 확장을 지원하지 않는 구현체에 익숙한 분들에게는 반대로 저
프로그램이 correct program 으로 다가오기 어렵다는 점도 생각해 주시기
바랍니다 - $ 를 전혀 다른 의미로 사용하는 구현체도 있습니다.

추가로 드리고 싶은 말씀은, $ 는 표준이 (최대의 이식성을 추구하는)
strictly conforming program 이 사용할 수 있다고 정의해 준 문자가
아닙니다 - (논란의 여지가 있긴 합니다만) Ada 가 ASCII 를 기반으로
정의되었다가 겪은 고초 때문에 C 표준은 ASCII 가 아닌 ISO 646 에 기반을
두고 정의되어 있습니다. 그래서 (표준이 그 문자를 앞으로도 사용할 일이
없기에) 더더욱 ASCII 기반의 구현체에서 안심하고 "자신만의" 고유한 확장
을 제공하기 위해 사용되는 문자입니다.

----------------------------------------------------------------------

고리타분하고 쓸데없는 얘기로 본의 아니게 게시판을 어지럽히게 되어
죄송스럽게 생각합니다. 이제 글 올리는 것 좀 그만 하고 저도 제 맡은 일
하러 가야 겠습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

전웅의 이미지

[depth 가 깊어져 따로 모아 답변 답니다]

가치 있는 내용이 별로 없어 어지간하면 그냥 지나가려 했는데 하도
이야기가 길어져 더 이상 보고 있을 수 없네요. (한숨이 나옵니다)

> 애초에 제기된 문맥과 자꾸 동떨지느데요,
> provision이 보여주기 위한 구성 요소로 normative elements 를 사용하고 있습니다.
> normative elements 에는 general/technical 이 있고요.
> general 안에 scope/normative reference가 있고 technical 안에 option으로 terms and definitions
> 와 같은 것을 둘 수 있고 scope에 맞게 이름을 지어서 넣을 수 있습니다.

이렇게 허겁지겁 드시면 또 저번처럼 탈납니다.

> 구리니까

뭐가 구린진 모르겠습니다 ;-)

> techical 안에 본문이 들어간단 말입니다. 이름을 어떻게 지어라고 한 것이 normative 라고 한 적이
> 있습니까? 4. Conformance 가 이름이 없으면 안되는 normative elements 라고 했죠.
> 애초에 시작된 주제에서 왜 자꾸 벗어나세요.
>

처음에는 "4. Conformance" 의 의미를 문제 삼아 correct 와 conforming 을
엮어보려다가, 제가 정의를 인용해 clause 제목이 내용 해석에 절대적 영향
을 줄 수 있는 normative element 가 아님을 보이자, 금새 언제 그런 말
했었냐며 발뺌을 하시는군요. 님 말씀대로 subclause 와는 달리 clause 의
경우 반드시 제목을 가져야 한다는 것을 놓고 이야기하는 것이었다면 벌써
한참 전에 나온 이야기입니다.

http://kldp.org/node/81963#comment-390454

지금 하고 계신 말씀은 한참 전부터 이 논의를 따라오신 모든 분들이
알고있던 사실을 님 혼자서 논란거리로 만들어 지금까지 주장해 오셨다는
얘기뿐이 되지 않습니다.

> 물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
> nomative 로 Annex D에서 얘기 하고 있습니다.
>

혼자 공부한 내용은 집에 있는 개인 노트에 정리하시는 것이 좋겠습니다.

---------------------------------------------------------------------

표준에 대해 기본 개념이 갖춰지지 않은 상태로 몇일 보게 되었다고 뭔가
의미있는 것들을 깨우친 것처럼 말씀하지 마시기 바랍니다.

> > 그리고 제 영어
> > (영한/영영) 사전은 "erroneous" 의 동의어로 wrong 과 incorrect 를,
> > 한국어 의미로 "잘못된"을 보여주고 있습니다.
>
> erroneous의미를 문제삼은 적 없지만 이것도 오류라는 단어가 있는 상태에서 적절한
> 단어가 아니라고 생각합니다.
>

표준과 ISO 2382-1 이 따로 정의해주지 않은 용어의 개념은 어디서 규정해
준다고 말씀드렸죠? (기억이 나지 않으시면 지금까지의 논의를 천천히
읽으면서 살펴보시길 추천합니다.)

제 영어 사전이 바로 Directives 에서 언급하고 있는 사전 중 하나입니다.

> 다른 관련 것들도 표준 관련 문서를 볼수록 의문점이 많지만 나중으로 미루도록 하고,
>

부탁입니다만, 의문점이 생겨도 수용적 자세로 하는 질문이 아닌 이상
최소한 저한텐 말씀하지 말아 주십시오. 님같이 의미 전달이 어렵고 고집만
강한 분께 답변할 생각만해도 한숨부터 나옵니다. 계속 이런 방식이라면
님과 저 사이에 "나중"은 없습니다.

> 다시, 잘못된 프로그램 구조로 돌아가서 얘기하면, 문법성 오류를 구조의 잘못이라고 한데
> 있습니다.

엄밀히 말해 문법 오류는 undefined behavior 보다 더 엄격한 제약을 받는
constraint violation 입니다. 하지만 행동의 측면에서, syntactic rule
을 어긴 프로그램과 semantic rule 을 어긴 프로그램 모두 undefined
behavior 로 기술됩니다. "구조"라는 표현에 무의미하게 딴지 걸며 문법성
오류만을 연결한 사람은 (제가 보기엔) 님 혼자만이었습니다.

> construct 라는 의미에 사전적으로 구조의 의미도 있습니다. 사전적인 의미에서
> architecture, structure, construct 모두 구조로 번역할 수 있습니다. 그러나 그냥 사전에
> 있는 한 단어를 대치하는 것이 번역이 아니라는 사실을 잘 아시듯이, 문맥을 살려줘야 합니다.

제가 "구조"라는 단어를 사용했을 때 어떤 의도로 사용했는지는 이미 말씀
드린 바 있습니다. 제가 영어 논의 등을 운운하며 construct 를
언급했음에도 불구하고 structure, architecture 라는 거리감 있는 단어를
꾸준히 끌고 들어온 것은 님입니다. 잔잔한 호수에 스스로 돌 던져놓고
파문이 일었다고 큰 소리 내시는 셈입니다.

> C 표준에서 construct는 분명 구문, 의미상 규칙으로 이루져 있음을 알고 있습니다. 이것은
> 언어를 구성하는 요소로서 말하고 있는 것입니다.

그렇게 어렵게 따지지 않아도 문맥을 통해서 자연스럽게 뜻이 배어 나올
수 있는 용어입니다. 그렇지 않았다면 표준이 본문을 통해 분명히 정의해
주었을 것입니다. 또한, 그 정도로 깊이 있게 탐구해야 할 용어는
construct 같은 애들이 아니라 character 같은 애들입니다 - construct 에
집착하는 것은 에너지 낭비일 뿐입니다.

> 6.2.7p3에서
>
> 인용:
>
> A composite type can be constructed from two types that are compatible
>
> 6.4.4.4p12
>

부적절한 인용입니다. 여기서 "constrcut" 는 "구조(something built)"의
의미라기 보다는 "생성(produced)"의 의미에 가깝습니다. composite type
이 무엇인지 알고는 인용하셨습니까? (프로그래머에게) composite type 은
소스 상에 눈으로 보이는 존재가 아니라 비슷한 type 들의 합성으로
"허공에" 생성되는 존재에 가깝습니다. 따라서 program construct 로부터
유도 혹은 유추될 수 있는 것이지, 구체적인 program construct 자체를
구성하는 개념은 아닙니다.

> 인용:
>
> The construction '\0' is commonly used to represent the null character.
>

맞습니다. 여기서의 construction 이 제가 "프로그램 구조"에서 언급한
"구조"에 부합하는 의미입니다.

> 표준에서 program structure란 단어가 분명히 있기 때문에 번역할 때는 이 둘과 구분해
> 줘야 합니다.
>

construct/construction 만 존재하던 곳에 structure 를 끌고 들어온 분은
님입니다. (최소한 제가 "construct" 를 언급한 이후) 다른 사람들은 오해
없이 다들 잘 이해하고 있는데 혼자서 construct 와 structure 를
혼동하더니 대단한 발견이라도 한 것처럼 글을 남기시는 이유는...

> 참고로 한국정보통신기술협회(TTA)에서 정의한 언어 구성소는 다음과 같습니다.
>
> 인용:
>
> 언어 구성소 [ 言語構成素, language construct A ]
> 프로그램 언어를 기술할 때 필요한 구문상의 구성 요소. 식별자, 명령문, 모듈 등이 있다.
>
>
> 영어를 그대로 쓰지 않았을 경우에는 그에 합당한 번역을 해 줘야 하는 것입니다.
> 제가 처음에 Architecture적인 의미로 듣고 의문을 제기하는 것은 합당하다고 생각합니다.
>

알겠습니다. 제가 항상 저와 대화를 나누고 논의를 하던 분들만을 생각해
표준에 대한 경험이 적은 님이 "구조"라는 용어에 (제 의도와 다른
의미의) structure 와 architecture 를 생각하실 수 있다는 사실은 전혀
생각하지 못했습니다. 하지만 아직도 "구조"의 의도한 의미로 보다 분명한
"construct/construction" 을 한참 전에 언급했음에도 불구하고 끝까지
structure/architecture 와 혼동된다 말씀하시는 님이 온전히 이해가
되지는 않습니다.

> language lawyer적인 측면에서 문제를 고민하신다면, 번역을 생각하신다면 분명 부딛칠
> 문제입니다. 그것이 아니라면 상관없습니다.
>

표준의 "권위 있는" 번역은 아무나 할 수 있는 것이 아닙니다. 현재 ISO
에 우리나라를 대표하고 있는 기관인 기술표준원만이 가능합니다 - 실제
C89 의 경우 우리말 번역본이 나왔던 것으로 알고 있습니다. 그럼에도
불구하고 제가 해당 문맥에서 language lawyer 로서 엄격한 번역을
시도했다고 생각하시나요? 아래 제 답변을 님은 보신 기억이 없다는
뜻인가요?

제가 씀:
] 영어로 논의를 진행할 때 "program", "program constrcut" 는 종종
] 통용되어 사용되는 표현입니다.

제가 표준의 우리말 번역을 시도했다면 "영어로 논의를 진행할 때",
"종종 통용되어" 와 같은 표현을 사용하지 않았을 것입니다.

어쨌든 (아직도 중반부부터는 그 의미가 분명해졌음에도 이제서야 정리가
되는 님을 온전히 이해하긴 어렵지만) 애초에 님이 왜 "구조"라는 표현에
대해 의문을 표했는지는 이해했으며, 오해라는 것이 일방의 잘못이
아니기에 처음부터 보다 분명한 표현을 사용하지 못한 점에 대해
사과드립니다.

그리고 더불어 부탁드립니다만, 질문이든 주장이든 글 올리시기 전에
(비록 상당히 길긴 하지만) 전체 논의를 쭉 훑어보시기 바랍니다.
님이 앞으로 쓰실 글을 정리하는데에도 도움이 될 뿐더러, 종종 지금까지
남아있던 의문이나 오해에 대한 답을 얻을 수 있기도 합니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:
> 애초에 제기된 문맥과 자꾸 동떨지느데요,
> provision이 보여주기 위한 구성 요소로 normative elements 를 사용하고 있습니다.
> normative elements 에는 general/technical 이 있고요.
> general 안에 scope/normative reference가 있고 technical 안에 option으로 terms and definitions
> 와 같은 것을 둘 수 있고 scope에 맞게 이름을 지어서 넣을 수 있습니다.

이렇게 허겁지겁 드시면 또 저번처럼 탈납니다.


탈날 수도 있습니다. 그러나 방치하면 더 큰 탈을 부를 수 있기에......

Quote:

> 구리니까

뭐가 구린진 모르겠습니다 ;-)


키보드와 의자로 연결된 선이 구리랍니다.

Quote:

처음에는 "4. Conformance" 의 의미를 문제 삼아 correct 와 conforming 을
엮어보려다가,

correct와 conforming이 전혀 관련없다고 말하는데 동의하지 않습니다.
아마 위에서 알겠다고 했을껍니다. 자꾸 핵심을 벗어났기 때문에 이제 다른 것들이
어느 정도 정리 됐기고 새로운 이해 바탕위해 다시 시도하는 것입니다.

correct program(이하 cr.p.)은 이미 말한대로 정의가 아니라 단순히 기술했다는 것을
알고 있습니다. 이 말은 곧 이미 정의된 conforming program(이하 cf.p.) 이나 strictly
conforming program(이하 s.c.p.)에 어떤 식으로든 속해 있다는 뜻입니다. 이것이 cf.p., s.c.p.
개념 위에 세워졌지는 않지만 결국 한 형태로 자리 잡고 있기 때문에 4.Conformance에 기술하고 있다는
생각입니다.
cr.p.는 unspecified behavior를 포함하고 있기 때문에 cf.p. 한 형태입니다. 그런데
unspecified behavior이지만 4p5에 의해 output을 만들지 않으면 s.c.p.
이라고 할 수 있기에 어떤 cf.p.는 s.c.p.도 되는 것입니다. 그러므로,

Quote:

참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
correct 프로그램이지만 strictly conforming program 이 아닙니다.

이것을 틀린 말입니다. 그리고,
Quote:

correct program 의 subset 이 strictly conforming program 이고,
conforming program 은 이 둘과 아무런 관련이 없습니다.

이것 역시 틀리고, 아무런 관련이 없다고 할 수 없는 것입니다.
틀린 것이 있다면 지적바랍니다.

Quote:

제가 정의를 인용해 clause 제목이 내용 해석에 절대적 영향
을 줄 수 있는 normative element 가 아님을 보이자, 금새 언제 그런 말
했었냐며 발뺌을 하시는군요. 님 말씀대로 subclause 와는 달리 clause 의
경우 반드시 제목을 가져야 한다는 것을 놓고 이야기하는 것이었다면 벌써
한참 전에 나온 이야기입니다.

http://kldp.org/node/81963#comment-390454


제가 이해한 것을 읽어 보고 다시 생각해 보시기 바랍니다.
normative를 말할 때 확실히 normative general elements(n.g.e.), normative
technical elements(n.t.e.)와 좀 더 작은 개념인 normative elements(n.e.) 및
content를 구분하는 것을 처음에 분명 놓쳤습니다. n.e.에는 님이 말하신 Scope(clause 1),
Normative References(clause 2)와 Title(n.g.e.에 속하는)와 Terms and Definitions,
각 clause 3부터 끌 clause까지, Normative Annex 등등(n.t.e.에 속하는) 있습니다.
그리고 n.e.에는 선택이거나 필수인, 최종 레벨의 normative이거나 informative인 허용된
content가 있습니다.
Normative References를 예로 들면 허용된 content가 Reference와 footnote가 있는데
Reference는 필수 이고 informative인 footnote만 허용돼 있습니다.
근데 Normative References를 필수라고 말하셨지만 Directives 6.2.2에의하면 옵션입니다.
그리고 이미 말하셨듯이 clause들도 옵션입니다. 쓰면 normative인데 생략할 수도 있다는 것입
니다. 그래서 clause를 쓰면 structure 형식에 의해 아시다시피 제목을 써야하고 subclause
에서는 안 써도 되는 것입니다. clause에 허용된 컨텐트 Text/Figures/Tables/Notes/
Footnotes 증에 Notes, Footnotes는 infomative입니다.
이제 이미 언급한 테이블을 보면 이해가 더 잘 될 것입니다. 틀린 것이 있다면 지적바랍니다.

Quote:

> 물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
> nomative 로 Annex D에서 얘기 하고 있습니다.
>

혼자 공부한 내용은 집에 있는 개인 노트에 정리하시는 것이 좋겠습니다.


clause 제목을 지을 때 제한이 전혀 없는 것이 아니기에 언급한 것입니다.

(......문제에 집중하기 위해 컷 합니다......)

Quote:
어쨌든 (아직도 중반부부터는 그 의미가 분명해졌음에도 이제서야 정리가
되는 님을 온전히 이해하긴 어렵지만) 애초에 님이 왜 "구조"라는 표현에
대해 의문을 표했는지는 이해했으며, 오해라는 것이 일방의 잘못이
아니기에 처음부터 보다 분명한 표현을 사용하지 못한 점에 대해
사과드립니다.

네 감사합니다. 애초의 제기된 문제에 준한(but not strictly conforming)
사과라고 생각합니다.
저 역시 기술적인 문맥과 다른 의도로 해석될 수 있는 표현이 있었다면 사과드립니다.
정말이지 전 아무 감정없습니다. 앙금이 남아 있다면 또 무지한 저를 질책하시기
바랍니다.

(......)

전웅의 이미지

> correct와 conforming이 전혀 관련없다고 말하는데 동의하지 않습니다.
> 아마 위에서 알겠다고 했을껍니다. 자꾸 핵심을 벗어났기 때문에 이제 다른 것들이
> 어느 정도 정리 됐기고 새로운 이해 바탕위해 다시 시도하는 것입니다.
>

그럼 이제부터 고쳐 아시기 바랍니다. 제가 많이 바쁜 관계로 아래
간단히(?) 설명 드립니다.

>
> correct program(이하 cr.p.)은 이미 말한대로 정의가 아니라 단순히 기술했다는 것을
> 알고 있습니다.
>

맞습니다. 엄밀한 정의가 아닙니다. 즉 우리가 흔히 사용하는 "correct
program" 이라는 표현을 표준화 위원회는 어떤 기준으로 생각하고 있는가
를 표준의 용어를 통해 보인 것이라 생각하시면 됩니다.

> 이 말은 곧 이미 정의된 conforming program(이하 cf.p.) 이나 strictly
> conforming program(이하 s.c.p.)에 어떤 식으로든 속해 있다는 뜻입니다. 이것이 cf.p., s.c.p.
> 개념 위에 세워졌지는 않지만 결국 한 형태로 자리 잡고 있기 때문에 4.Conformance에 기술하고 있다는
> 생각입니다.

엄밀히 따지고 들어가면 100% 맞는 이야긴 아니지만, 이렇게 이해해도 큰
무리는 없다는데 동의합니다.

> cr.p.는 unspecified behavior를 포함하고 있기 때문에 cf.p. 한 형태입니다. 그런데
> unspecified behavior이지만 4p5에 의해 output을 만들지 않으면 s.c.p.
> 이라고 할 수 있기에 어떤 cf.p.는 s.c.p.도 되는 것입니다. 그러므로,

논리적 포함 관계를 좀 더 면밀하게 따져 보시기 바랍니다.

conforming program:
- undefined, unspecified, i-d behavior 모두 포함 가능
- 단지 특정 구현체에서 받아들여주기만(accept) 하면 됨

strictly conforming program:
- undefined behavior 를 포함할 수 없음
- 프로그램의 출력이 unspecified, i-d behavior 에 의존 불가능
- 표준이 기술하는 기능 안에서 구현되어야 함
- 구현체가 받아들여준다는(accept) 보장 없음 (*)

correct program:
- undefined behavior 를 포함할 수 없음
- 구현체가 받아들여준다는(accept) 보장 없음 (*)

표준을 엄밀하게 해석하면 s.c. program 이든 correct program 이든 표준
을 준수하는 구현체가 받아들여줘야(accept) 한다는 요구 사항은
없습니다. 하지만 이는 어디까지나 다소 정치적, 이론적인 문제이기
때문에 현실적으로 상식적인 구현체는 s.c. program, correct program 을
모두 수용할 수 있다고 가정하겠습니다. 따라서 위에서 (*) 로 표시된
항목은 잠시 무시합니다.

자, 이제 각 제약에 따라 논리적으로 따져 보겠습니다.

"s.c. program 이면 correct program 입니다" 는 참
(역) "correct program 이면 s.c. program 입니다" 는 거짓
(대우) "correct program 이 아니면 s.c. program 이 아닙니다" 는 참

"correct program 이면 conforming program 입니다" 는 참
(역) "conforming program 이면 correct program 입니다" 는 거
(대우) "conforming program 이 아니면 correct program 이 아닙니다" 는 참

(명제와 연결해) "s.c. program 이면 conforming program 입니다" 는 참
(역) "conforming program 이면 s.c. program 입니다" 는 거짓
(대우) "conforming program 이 아니면 s.c. program 이 아닙니다" 는 참

* 다시 한번 말씀드리지만, s.c. program 과 correct program 을 모든
구현체가 수용 가능하다는 가정 아래에서의 논리입니다!!!

이제 님이 말씀하신 명제들을 나열해 보겠습니다.

- cr.p.는 unspecified behavior를 포함하고 있기 때문에 cf.p. 한 형태입니다.

이를 "correct program 은 conforming program 입니다" 로 놓으면 맞는
이야기입니다.

- 그런데 unspecified behavior이지만 4p5에 의해 output을 만들지 않으면 s.c.p.
이라고 할 수 있기에 어떤 cf.p.는 s.c.p.도 되는 것입니다.

위에서 나열한 명제에 의해 s.c. program 은 conforming program 의
subset 이 됩니다. 따라서 "어떤" conforming program 은 s.c. program 이
될 수 있습니다. 따라서 맞습니다.

> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
>
> 이것을 틀린 말입니다. 그리고,
>

잘 정리해 놓으시고 왜 틀린 결론을... 제가 글을 천천히 잘 읽어봐달라고
그렇게 부탁을 드렸건만...

출력(output)이 unspecified behavior 에 의존하는 프로그램은 정의에
의해 s.c. program 이 아닙니다. 위에서는 출력(output)을 하지 않는
경우를 말씀해 놓으시고는 왜 밑에서는 출력(output)을 하는 경우임에도
s.c. program 이 될 수 있다고 생각하십니까? --; 다시 확인해 보시기
바랍니다.

> > correct program 의 subset 이 strictly conforming program 이고,
> > conforming program 은 이 둘과 아무런 관련이 없습니다.
>
> 이것 역시 틀리고, 아무런 관련이 없다고 할 수 없는 것입니다.
> 틀린 것이 있다면 지적바랍니다.
>

넵, 님 말씀대로 위에서 제가 정리해 놓은 명제와 같은 관계를 가지고
있습니다. 하지만, 그 이전에 제가 가정한 것([*] 항목 무시)을 보시기
바랍니다. conforming program 을 결정짓는 중요한 요소는 구현체가
받아들일 수 있느냐, 없느냐 입니다. 받아들인 다는 것은 번역과 실행을
허용한다는 것입니다.

하지만, 표준은 s.c. program 이라고 해서, 혹은 correct program 이라고
해서 구현체가 번역과 실행을 해주어야 한다고 요구하지 않습니다.
correct program 을 기술하면서 특정 subclause 에 따라 행동해야 한다고
요구한 부분은 일단 번역과 실행이 성공한 이후에는 그래야 한다는
뜻입니다. 이론적으로 구현체는 특정 조건을 만족하는 s.c. program
하나만을 올바르게 번역, 실행해 주면 됩니다 - 그 외에는 번역, 실행해
줄 필요가 없습니다. (또, 버럭하시면서 틀린 반박을 하실까봐 아래 표준
인용해 드립니다. 이와 관련된 내용은 제가 csc 에서 길게 토론한 글이
있습니다. 궁금하신 내용은 직접 검색해 보시기 바랍니다)

Quote:

5.2.4.1:

The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of the
following limits:

이는 매우 정치적으로 결정된 비현실적인 사항이지만, 실제 시장의 힘에
의해 컴파일러 회사들은 품질 좋은 컴파일러를 만들려고 할 것이기 때문에
현실적인 문제를 일으키지는 않습니다.

따라서 제가 conforming program 이 무관하다고 드린 말씀은 그와 같은
해석을 적용할 경우 관계가 없다는 뜻입니다 - 설사 억지로 관계를 찾는다
해도 s.c. program 딱 하나와만 교집합을 만들 수 있다는 뜻입니다.
더구나, conforming program 의 의도 자체가 어떤 conformance level 을
결정짓기 위한 것이 아니라 (이전에 보여드린 %1$ 에 대한 답에서처럼)
사람들을 달래기 위한 정치적 목적이라는 것입니다.

한 가지 궁금한 것은 제가 이전에 인용, 언급해 드린 csc 논의 등은
확인해 보셨나요? 해당 내용을 검색해 공부하셨다면 저보다 더 영향력
있는 분들의 답변을 확인하실 수 있습니다. Directives 파실 시간에 그런
논의 몇 개 더 읽는 것이 훨씬 더 도움이 됩니다.

> > 제가 정의를 인용해 clause 제목이 내용 해석에 절대적 영향
> > 을 줄 수 있는 normative element 가 아님을 보이자, 금새 언제 그런 말
> > 했었냐며 발뺌을 하시는군요. 님 말씀대로 subclause 와는 달리 clause 의
> > 경우 반드시 제목을 가져야 한다는 것을 놓고 이야기하는 것이었다면 벌써
> > 한참 전에 나온 이야기입니다.
> >
> > http://kldp.org/node/81963#comment-390454
>
> 제가 이해한 것을 읽어 보고 다시 생각해 보시기 바랍니다.
> normative를 말할 때 확실히 normative general elements(n.g.e.), normative
> technical elements(n.t.e.)와 좀 더 작은 개념인 normative elements(n.e.) 및
> content를 구분하는 것을 처음에 분명 놓쳤습니다. n.e.에는 님이 말하신 Scope(clause 1),
> Normative References(clause 2)와 Title(n.g.e.에 속하는)와 Terms and Definitions,
> 각 clause 3부터 끌 clause까지, Normative Annex 등등(n.t.e.에 속하는) 있습니다.
> 그리고 n.e.에는 선택이거나 필수인, 최종 레벨의 normative이거나 informative인 허용된
> content가 있습니다.
> Normative References를 예로 들면 허용된 content가 Reference와 footnote가 있는데
> Reference는 필수 이고 informative인 footnote만 허용돼 있습니다.
> 근데 Normative References를 필수라고 말하셨지만 Directives 6.2.2에의하면 옵션입니다.
> 그리고 이미 말하셨듯이 clause들도 옵션입니다. 쓰면 normative인데 생략할 수도 있다는 것입
> 니다. 그래서 clause를 쓰면 structure 형식에 의해 아시다시피 제목을 써야하고 subclause
> 에서는 안 써도 되는 것입니다. clause에 허용된 컨텐트 Text/Figures/Tables/Notes/
> Footnotes 증에 Notes, Footnotes는 infomative입니다.
> 이제 이미 언급한 테이블을 보면 이해가 더 잘 될 것입니다. 틀린 것이 있다면 지적바랍니다.
>

ISO 표준 drafting 을 준비 중이신지요? ;-)

님이 이런 내용을 잘못 이해하고 있다고 드린 말씀이 아닙니다.

길게 적으셨지만 clause/subclause 제목과 관련된 결론은 짧게 적으면,
"clause 는 제목을 적어야 하고, subclause 에서는 안 적어도 된다"
입니다.

혹은 그 외에 clause/subclause 제목과 관련해 제가 주의깊게 봐야 하는
결론이 있나요?

> > 물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
> > nomative 로 Annex D에서 얘기 하고 있습니다.
> >
>
> 혼자 공부한 내용은 집에 있는 개인 노트에 정리하시는 것이 좋겠습니다.
> clause 제목을 지을 때 제한이 전혀 없는 것이 아니기에 언급한 것입니다.
>

--; Homogeneity 의 내용은 제목 뿐 아니라 표준 문서 전반에 걸쳐
적용되어야 하는 일반적 내용입니다. 즉, 지극히 상식적인 내용으로 이미
님과 저 사이에 암시적으로 동의가 이루어진 부분이므로, 지금까지 중점이
되었던 문제와 직접적 관련이 있는 부분으로 생각하지 않는다는 뜻입니다.

>
> 네 감사합니다. 애초의 제기된 문제에 준한(but not strictly conforming)
> 사과라고 생각합니다.

남의 말을 왜곡하는데 일가견이 있으신 것 같습니다. "구조"라는 표현을
불명확하게 사용한 것에 대한 사과입니다.

> 저 역시 기술적인 문맥과 다른 의도로 해석될 수 있는 표현이 있었다면 사과드립니다.
> 정말이지 전 아무 감정없습니다. 앙금이 남아 있다면 또 무지한 저를 질책하시기
> 바랍니다.
>

목적이 무엇인지 모르겠으나, 뭔가를 열심히 탐구하고 계시는 것
좋습니다. 또한 님이 설사 무지하시다 하더라도 무지한 것은 (제가 님의
선생님이 아니고서야) 질책의 대상이 될 수 없습니다. 중요한 것은 님이
그와 같은 무지의 상태에서 나오는 방법과 태도에 있습니다. 님이
지금까지 고민하셨던 것, 혹시나 앞으로 고민하실 것들 모두 저는 5-10년
전에 미리 고민하고 일부는 긴 시간에 걸쳐 결론을 내린 것들입니다.

제가 님의 입장이라면 무턱대고 잘못된 주장을 나열해 놓고 지적되길
기다리고 있지는 않을 것입니다. 이는 매우 위험한 태도입니다. 만약,
저나 혹은 해당 내용을 올바르게 알고 있는 다른 분이 지적을 해주지
않으면 님은 그것이 올바른 사실이라 가정하실테고, 더구나 님 글을 읽는
다른 분들 중에서도 님의 주장을 사실로 받아들이는 분들이 나올 수
있습니다. 이 얼마나 무책임한 행동입니까?

하지만, 반대로 님이 이해한 바를 확인하기 위해 질문의 형태를 취한다면,
님 스스로는 물론 다른 분들의 오해를 낳는 일도 없을 것입니다 - 최소한
물음표가 박힌 문장을 읽고 참이라 가정하는 사람이 더 적지 않겠습니까?

제가 님께 원망스러운 부분은 바로 그런 방식의 부분입니다. 이 점을 좀
더 고려해 보시기 바랍니다.

KLDP 에 글 올리는 것 힘듭니다. 앞으로 제게 "질문" 있으시면 질문하실
내용만 간추려 메일로 부탁드립니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

이 게시판이 디자인된 대로 답글을 다시기 바랍니다.
애초에 글을 합치는 것도 그냥 넘어 갔지만 혼란만 가중시킬 뿐입니다.
결국 제가 말한 대로 질문자의 주제와 다른 OT이지만 이미 늦었으니
계속합니다.

(게시판 인용이 이상해서 편집하고 몇자 지웁니다.)

Quote:

>> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
>> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
>>
>> 이것을 틀린 말입니다. 그리고,
>>
>
>잘 정리해 놓으시고 왜 틀린 결론을... 제가 글을 천천히 잘 읽어봐달라고
>그렇게 부탁을 드렸건만...
>
>
>출력(output)이 unspecified behavior 에 의존하는 프로그램은 정의에
>의해 s.c. program 이 아닙니다. 위에서는 출력(output)을 하지 않는
>경우를 말씀해 놓으시고는 왜 밑에서는 출력(output)을 하는 경우임에도
>s.c. program 이 될 수 있다고 생각하십니까? --; 다시 확인해 보시기
>바랍니다.

표준 자체에서도 분명하고 c.s.c 에서 글도 읽었지만 당연히 배워야할 사실에
대해서 지금 또 오류를 반복하고 있습니다.

4p5에서

Quote:

It shall not produce output dependent on any unspecified, undefined,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
or implementation-defined behavior, and shall not exceed any minimum
implementation limit.

에 따라
Quote:

>프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은

output(출력)을 unspecified behavior에 의존한다는 뜻이 출력을 produce(생산)
한다는 뜻이 아님이 분명합니다.
제발 표준에 대한 잘못된 이해를 퍼뜨리지 마십시오.

Quote:

>ISO 표준 drafting 을 준비 중이신지요? ;-)
>
>님이 이런 내용을 잘못 이해하고 있다고 드린 말씀이 아닙니다.
>
>길게 적으셨지만 clause/subclause 제목과 관련된 결론은 짧게 적으면,
>"clause 는 제목을 적어야 하고, subclause 에서는 안 적어도 된다"
>입니다.
>
>혹은 그 외에 clause/subclause 제목과 관련해 제가 주의깊게 봐야 하는
>결론이 있나요?

제가 어떤 분의 알 수 없는 정신세계를 ISO Drafting이라도 해야 멈추겠습니까.

Quote:

>> 네 감사합니다. 애초의 제기된 문제에 준한(but not strictly conforming)
>> 사과라고 생각합니다.
>
>남의 말을 왜곡하는데 일가견이 있으신 것 같습니다. "구조"라는 표현을
>불명확하게 사용한 것에 대한 사과입니다.

전 그 구조에 대한 불명확한게 사용한 것에 대한 사과를 받아들였다는 의미입니다.
이것은 애초에 제기된 문제였습니다. 확실히 의도적으로든 알 수 없는 이유로 뭔가
있는 그대로 읽는 것을 방해하는 것이 아닌가 하는 생각이 듭니다.

전웅의 이미지

> 이 게시판이 디자인된 대로 답글을 다시기 바랍니다.
> 애초에 글을 합치는 것도 그냥 넘어 갔지만 혼란만 가중시킬 뿐입니다.
> 결국 제가 말한 대로 질문자의 주제와 다른 OT이지만 이미 늦었으니
> 계속합니다.
>
> (게시판 인용이 이상해서 편집하고 몇자 지웁니다.)
>

유사 주제에 대해 여러 곳에 나눠 글을 다는 것은 동일한 이야기를 여러
곳에서 반복하게 만들기 때문에 하나의 글로 합쳐 답변한 것이며, Drupal
의 인용 시스템이 별로 효율적이지 못해 직접 인용을 하고 있는
것뿐입니다 (인용 시스템이 지금도 말썽이죠).

[s.c. program 의 제한에 대해:]

제가 쓴 글:
>> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
>> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
>>

님의 답변:
>>
>> 이것을 틀린 말입니다. 그리고,
>>

다시 제가 쓴 글:
>
>출력(output)이 unspecified behavior 에 의존하는 프로그램은 정의에
>의해 s.c. program 이 아닙니다. 위에서는 출력(output)을 하지 않는
>경우를 말씀해 놓으시고는 왜 밑에서는 출력(output)을 하는 경우임에도
>s.c. program 이 될 수 있다고 생각하십니까? --; 다시 확인해 보시기
>바랍니다.

님의 답변:
>
> 표준 자체에서도 분명하고 c.s.c 에서 글도 읽었지만 당연히 배워야할 사실에
> 대해서 지금 또 오류를 반복하고 있습니다.
>
> 4p5에서 인용:
> It shall not produce output dependent on any unspecified, undefined,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> or implementation-defined behavior, and shall not exceed any minimum
> implementation limit.
>
> > 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
>
> output(출력)을 unspecified behavior에 의존한다는 뜻이 출력을 produce(생산)
> 한다는 뜻이 아님이 분명합니다.
> 제발 표준에 대한 잘못된 이해를 퍼뜨리지 마십시오.
>

스스로 모순이 있음을 모르시나요? 그 "분명하다"는 표현 함부로 쓰지
마시고 제발 질문을 하십시오. 부탁드립니다.

문제가 되는 표준의 부분:
- 프로그램이 unspecified behavior 에 의존하는 출력을 생성하면 안 된다.

어떤 프로그램이 이 조건을 위반하기 위해서는:

- 프로그램이 출력을 생성해야 한다 (출력을 생성하지 않으면 그 출력이
unspecified 에 의존할 수도 없게 됩니다)

- 그렇게 출력된 내용이 unspecified behavior 에 의존해야 한다.

이제 좀 단도직입적으로 물어 보겠습니다.

- 해당 부분이 말하는 출력은 정확히 무엇이라고 생각하시는지요? 예를
들어, main() 함수의 반환값은 표준이 말하는 출력에 포함될까요? 혹은
프로그램 실행으로 실행 환경에 미치는 영향 (레지스터 값의 변화, 특정
메모리 값의 변화 등) 은 모두 프로그램의 출력에 포함되어야 할까요?

아마도 님께서 인용하신 부분에서 말하는 "output" 을 오해하고 계신 것
같아 드리는 질문입니다.

또 다른 질문 하나 드려보겠습니다. 인용하신 규정을 어기는 예 하나를
보여보시기 바랍니다. 즉, unspecified behavior 에 출력이 의존하는
(따라서 strictly conforming program 이 아닌) 프로그램 하나 만들어
보시기 바랍니다.

또, 반대로 unspecified behavior 를 포함하지만 출력이 그 행동에
의존하지 않는 (따라서 strictly conforming program 인) 예를 하나 만들어
보시기 바랍니다.

님께서 해당 부분을 그토록 완벽하게 이해하고 계시다면 위의 질문 정도는
어렵지 않은 것들입니다.

그렇게 답변을 다 하고도 "출력이 unspecified behavior 에 의존한다는
것이 (일단) 출력을 생산한다는 것을 의미하지는 않는다"고 주장하실 수
있는지 궁금해지는군요.

[ISO/IEC Directives 관련:]

> >ISO 표준 drafting 을 준비 중이신지요? ;-)
> >
> >님이 이런 내용을 잘못 이해하고 있다고 드린 말씀이 아닙니다.
> >
> >길게 적으셨지만 clause/subclause 제목과 관련된 결론은 짧게 적으면,
> >"clause 는 제목을 적어야 하고, subclause 에서는 안 적어도 된다"
> >입니다.
> >
> >혹은 그 외에 clause/subclause 제목과 관련해 제가 주의깊게 봐야 하는
> >결론이 있나요?
>
> 제가 어떤 분의 알 수 없는 정신세계를 ISO Drafting이라도 해야 멈추겠습니까.
>

뭐가 그렇게 어렵습니까? 제가 봐야 하는 다른 결론이 있으면 말씀하시면
되고, 없으면 없다고 인정하시면 됩니다.

[사과 관련:]

> >> 네 감사합니다. 애초의 제기된 문제에 준한(but not strictly conforming)
> >> 사과라고 생각합니다.
> >
> >남의 말을 왜곡하는데 일가견이 있으신 것 같습니다. "구조"라는 표현을
> >불명확하게 사용한 것에 대한 사과입니다.
>
> 전 그 구조에 대한 불명확한게 사용한 것에 대한 사과를 받아들였다는 의미입니다.
> 이것은 애초에 제기된 문제였습니다. 확실히 의도적으로든 알 수 없는 이유로 뭔가
> 있는 그대로 읽는 것을 방해하는 것이 아닌가 하는 생각이 듭니다.
>

아, 그렇군요. 님이 제 글의 "구조"를 오해했듯이 제가 님 글의 "애초의
제기된 문제"를 오해한 것입니다. ;-) 그래도 최소한 기술적인 내용에 대한
오해가 아니니 다행이군요.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:

>또 다른 질문 하나 드려보겠습니다. 인용하신 규정을 어기는 예 하나를
>보여보시기 바랍니다. 즉, unspecified behavior 에 출력이 의존하는
>(따라서 strictly conforming program 이 아닌) 프로그램 하나 만들어
>보시기 바랍니다.
>
>또, 반대로 unspecified behavior 를 포함하지만 출력이 그 행동에
>의존하지 않는 (따라서 strictly conforming program 인) 예를 하나 만들어
>보시기 바랍니다.

#include <stdio.h>
#define AA "04"
void do_my_job()
{
    // send my inputs to the blackhole
}
void do_your_job()
{
    // send your inputs to the stdout
}
int main(int argc, char **argv)
{
    if (AA == "04") { // gcc 3.4.2 compiler
        do_my_job();
    }
    else { // Sun C 5.8 compiler
        do_your_job();
    }
    return 0;
}

위 다른 분의 답변도 포함합니다.
어떤 conforming implementation이냐에 따라 s.c. program이 될 수도
있고 아닐 수도 있습니다.

제가 단기간에 표준에 관한 전체적인 안목에서 볼 수 없다는 것을 인정합니다.
그러나 있는 그대로 저도 해석할 수 있는 권리(?)가 있습니다. 저의 그런 시도를
허용할 여지를 텍스트는 있는 그대로 말하고 있는 것입니다. 이것이 순진한 저의
해석때문이라면 전 이미 무식하고 용감하게 그 댓가를 치루고 있습니다.
제가 그 이상 또는 그 이하로 쓸 데 없는 말을 들을 필요가 없는 것입니다.

Quote:

>뭐가 그렇게 어렵습니까? 제가 봐야 하는 다른 결론이 있으면 말씀하시면
>되고, 없으면 없다고 인정하시면 됩니다

반듯이 적어야한다만 말했다면 많은 글이 불필요했다는 것은 인정합니다.

Quote:

>그래도 최소한 기술적인 내용에 대한
>오해가 아니니 다행이군요.

정확한 번역을 할 생각도 없었고 language lawyer 적인 측면에서 고민한 것도
아니라고 하시니 기술적이라고 부를 이유도 없는 것이 맞습니다.
whitenoise의 이미지

#include <stdio.h>
 
main()
{
    printf("%2$s %1$s\n", "World!", "Hello");
}

modestcode wrote:
> 위 다른 분의 답변도 포함합니다.
> 어떤 conforming implementation이냐에 따라 s.c. program이 될 수도 있고 아닐 수도 있습니다.

strictly conforming program인지 아닌지 여부는 어떤 implementation인가하는 사항과는 전혀 상관이 없는 문제입니다. 그 이전에 correct program인지 아닌지 여부도 마찬가지로 implementation과 전혀 상관이 없는 것이죠.

C 표준에 따르면 제가 질문에 사용했던 위 코드는 (implemetation이 어떻던지 간에) 그냥 잘못된(incorrect) 프로그램일 뿐입니다. 그러나, SUSv2(Single Unix Specification version 2)에 따르면 위 코드는 올바른(correct) 프로그램입니다.

이 두 문장을 간단하게 표현하면 다음과 같습니다.
- 위 코드는 표준 C 프로그램이 아닙니다.
- 위 코드는 SUSv2 규격의 프로그램입니다.

Specification(technical standard)이란 것의 목적은 요구사항에 맞는 것과 그렇지 않은 것을 구분해 내는데 있습니다. 즉, S={x|P(x)}를 결정하는 P(x)를 기술한 것입니다. 이때 Correctness는 x∈S를 말하는 것이고, undefined behavior란 Q(x) → ~P(x)인 Q(x)를 말하는 것일 뿐입니다. 매우 간단하죠? 보시다시피 implementation과는 전혀 상관없는 개념들입니다.

이제 논의의 첫부분으로 돌아가서 이런 개념들에 대한 modestcode님의 이해가 어떠했는지 살펴봅시다.

modestcode wrote:
> 예를 든다면, 프로그램 요구사항에 무슨 플랫폼에서 이런 포맷으로 출력될 것을
지킨 프로그램이 잘못된 프로그램 구조로 얘기할 수 있냐는 것입니다.
> 이건 표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조로 결론날 수 있는 사항입니다.

'표준에 없는 확장 기능'이 표준 상의 undefined behavior를 가리키는 것은 명확합니다. 따라서 표준에 없는 확장 기능을 사용해서 개발한 모든 제품은 표준에 따르면 모두 잘못된 프로그램입니다. 그러나, 여기서 확장 기능은 다른 어떤 specification에 정의가 되어 있는 경우를 말한 것이겠죠? 그 기능을 사용해서 개발했다고 하니 그렇게 생각하는게 자연스럽습니다. 만약 그 specification의 기준으로 본다면 이 제품은 (그 specification을 준수하는 경우라면) 잘못된 프로그램이 아닌 것이죠. 제 질문에 대한 답변 내용을 보면 알 수 있듯이 modecode님은 correctness의 판단 기준이 specification이 아닌 implementation에 있다고 부정확하게 이해하고 계시지만, 어쨌든 이런 식의 이해가 배경에 있었습니다.

제가 이해한 바 대로 상황을 간략하게 묘사하면 이렇습니다.

전웅님: (표준에 따르면) modestcode님의 예시에 사용된 #는 undefined behavior이기 때문에 (표준에 따르면) 잘못된 프로그램입니다.
modestcode님: (어떤 프로그램이) 표준에 없는 확장 기능을 사용했다고 (모든 경우에) 잘못된 프로그램은 아닙니다.
전웅님: ???

이 과정에 전웅님은 처음 지적할 당시에는 그 내용이 표준에 따른다고 명시를 하지 않았지만 한결같이 표준 C의 경우에 한정해서 얘기를 진행하셨고, modecode님은 표준 C가 아닌 다른 경우도 포함시켜서 얘기하신 것이죠. 즉, 별개의 얘기를 한 셈입니다. 이후, correctness의 판단 기준이 specification이라는 사실을 명확하게 이해하지 못한 modestcode님이 그 판단 기준을 specification 그 자체가 아닌 C 표준 내부에서 찾으려고 하는 바람에 직접 관련이 없는 논의가 이렇게 길어지게 된 것입니다.

이렇게 설명드리면 전후관계를 이해하시겠죠?

modestcode의 이미지

Quote:

>modestcode 씀: > 위 다른 분의 답변도 포함합니다.
>> 어떤 conforming implementation이냐에 따라 s.c. program이 될 수도 있고 아닐 수도 있습니다.
>strictly conforming program인지 아닌지 여부는 어떤 implementation인가하는 사항과는 전혀 상관이 없는 문제입니다.
>

여기서 위 다른 분의 답변이란 것은 lovewar님을 얘기한 것이였습니다.
strictly conforming program이 모든 implementation에 대해서 동일한 결과를 가져와야한다는데 동의합니다.

지금은 C 표준 안에서 의미가 주제입니다.

whitenoise의 이미지

modestcode wrote:

>위 다른 분의 답변도 포함합니다.
>어떤 conforming implementation이냐에 따라 s.c. program이 될 수도 있고 아닐 수도 있습니다.

이 답변이 lovewar님의 질문에 대한 답변이라면 왜 이런 답변을 하셨는지 이해가 가지않는데 좀더 자세한 설명 부탁드려도 될까요? strictly conforming program이 출력의 unspecified behavior에 대한 의존성과 어떤 관련이 있는 것이지요?

modestcode wrote:

>strictly conforming program이 모든 implementation에 대해서 동일한 결과를 가져와야한다는데 동의합니다.

이건 제가 하고자 한 얘기와 상관없는 내용입니다.

modestcode wrote:

>지금은 C 표준 안에서 의미가 주제입니다.

C 표준 안에서 무엇의 의미를 찾고 계시는 중인가요? 여전히 '표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조인 것은 아니다'라는 내용을 C 표준 안에서 확인해보시려는 건가요?
modestcode의 이미지

Quote:

>이 답변이 lovewar님의 질문에 대한 답변이라면 왜 이런 답변을 하셨는지 이해가 가지않는데 좀더 자세한 설명 부탁드려도 될까요? strictly conforming program이 출력의 >unspecified behavior에 대한 의존성과 어떤 관련이 있는 것이지요?

제가 예를 든 프로그램은 unspecified behavior에 의존적이지만 출력은 만들거나 만들지 않은 경우를 포함합니다.
제가 원래 얘기하려던 것은 전웅님이
http://kldp.org/node/81963#comment-390258
> 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
> correct 프로그램이지만 strictly conforming program 이 아닙니다.
라고 하고선
http://kldp.org/node/81963#comment-390359 에서
> correct program 의 subset 이 strictly conforming program 이다
라고 한 것에 반박하다가 의존적이지만 출력을 만드는 경우와 만들지 않는 경우를 분리할 필요가 없는데
아주 좁게 해석한 결과가 돼 버렸습니다.

unspecified behavior와 strictly conforming program와의 관계는 4p5에 있습니다.

>C 표준 안에서 무엇의 의미를 찾고 계시는 중인가요? 여전히 '표준에 없는 확장 기능을 사용해서 개발한 모든 제품이 잘못된 구조인 것은 아니다'라는 내용을 C 표준 안에서 확인
>해보시려는 건가요?
아닙니다. 위에서 전웅님이 correct program 관련 하신 말에 대한 것입니다.

전웅의 이미지

>
> 제가 예를 든 프로그램은 unspecified behavior에 의존적이지만 출력은 만들거나 만들지 않은 경우를 포함합니다.
>

unspecified behavior 에 의존해 출력을 만들거나 만들지 않는 것도
NOT s.c. program 입니다. strictly conforming program 은 (locale-
specific behavior 에 의존한 출력을 제외하고) 모든 conforming
implementation 에서 동일한 출력을 보장하기 위한 것입니다. 즉, 출력이
있는지 없는지 여부도 동일해야 합니다.

>
> 제가 원래 얘기하려던 것은 전웅님이
>
> http://kldp.org/node/81963#comment-390258
>
> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
> >
>
> 라고 하고선
>
> http://kldp.org/node/81963#comment-390359 에서
>
> > correct program 의 subset 이 strictly conforming program 이다
> >
>

흠, 제가 말씀드린 두 문장은 논리적으로 아무 문제가 없습니다. 즉,
이전에 논리적 관계를 통해 보여드렸듯이, "s.c. program 이면 correct
program 이지만, 모든 correct program 이 s.c. program 은 아니다" 라는
말씀을 드린 것입니다 - 두번째 문장은 명제에서 집합적 관계를 끌어내
기술한 것에 불과합니다.

>
> 라고 한 것에 반박하다가 의존적이지만 출력을 만드는 경우와 만들지 않는 경우를 분리할 필요가 없는데
> 아주 좁게 해석한 결과가 돼 버렸습니다.
>

correct program 의 부분 집합이 s.c. program 입니다. 만약, 이 논리가
틀렸음을 보이고 싶으시다면 s.c. program 이면서 correct program 이 아닌
프로그램을 반례로 보이시면 됩니다 - 하지만, 조금만 고민해보면
아시겠지만 그런 프로그램은 존재하지 않습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:

>> 제가 원래 얘기하려던 것은 전웅님이
>>
>> http://kldp.org/node/81963#comment-390258
>>
>> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
>> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
>> >
>>
>> 라고 하고선
>>
>> http://kldp.org/node/81963#comment-390359 에서
>>
>> > correct program 의 subset 이 strictly conforming program 이다
>> >
>>>
>
>흠, 제가 말씀드린 두 문장은 논리적으로 아무 문제가 없습니다. 즉,
>이전에 논리적 관계를 통해 보여드렸듯이, "s.c. program 이면 correct
>program 이지만, 모든 correct program 이 s.c. program 은 아니다" 라는
>말씀을 드린 것입니다 - 두번째 문장은 명제에서 집합적 관계를 끌어내
>기술한 것에 불과합니다.
>
>> 라고 한 것에 반박하다가 의존적이지만 출력을 만드는 경우와 만들지 않는 경우를 분리할 필요가 없는데
>> 아주 좁게 해석한 결과가 돼 버렸습니다.
>>
>
>correct program 의 부분 집합이 s.c. program 입니다. 만약, 이 논리가
>틀렸음을 보이고 싶으시다면 s.c. program 이면서 correct program 이 아닌
>프로그램을 반례로 보이시면 됩니다 - 하지만, 조금만 고민해보면
>아시겠지만 그런 프로그램은 존재하지 않습니다.
>

제가 이해하기 어려운 부분은 "모든 s.c. program이 correct program이다"
(correct program 의 subset 이 strictly conforming program 이다와
동일한 의미인)라고 하는 것입니다.
correct program은 unspecified behavior을 포함하고 5.1.2.3에 준해서
행동한다라고 돼 있는 기술에 의하면 unspecified behavior를 포함하고 있지도
않는 s.c. program이 correct program이 되는 것입니다. 위에서 언급한
Clive Feather의 conforming issues란 글에서 처럼 correct program을
기술할 때 "unspecified behavior를 포함하는"을 "undefined behavior를
포함하지 않는"으로 고치면 말이됩니다.

전웅의 이미지

>
> 제가 이해하기 어려운 부분은 "모든 s.c. program이 correct program이다"
> (correct program 의 subset 이 strictly conforming program 이다와
> 동일한 의미인)라고 하는 것입니다.
> correct program은 unspecified behavior을 포함하고 5.1.2.3에 준해서
> 행동한다라고 돼 있는 기술에 의하면 unspecified behavior를 포함하고 있지도
> 않는 s.c. program이 correct program이 되는 것입니다. 위에서 언급한
> Clive Feather의 conforming issues란 글에서 처럼 correct program을
> 기술할 때 "unspecified behavior를 포함하는"을 "undefined behavior를
> 포함하지 않는"으로 고치면 말이됩니다.
>

s.c. program 의 판단 기준에서 중요한 것은 "행동"이 아닌 (stdio.h 에
의한) "출력"이 unspecified behavior/implementation-defined behavior
에 의존하는지 여부임을 다른 글에서 답변 드렸습니다. 이렇게 이해하시면
저 위의 제 문장에 대한 오해가 풀렸으리라 생각합니다.

중간 중간 감정적인 대응으로 부끄러운 글도 있었지만, 다행스럽게도
기술적으로 유용한 내용으로 마무리가 되어 가는 느낌입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

행동의 차이를 만들든 안 만들든 간에, 출력의 차이를 만들지 않는 unspecified behavior를
포함하고 있는 프로그램이 s.c. program이라고 했을 때도,
unspecified behavior를 포함하지 않는 s.c. program이 unspecified behavior를 포함하고
5.1.2.3에 따라 행동하는 correct program과 차이가 좁혀 지지 않습니다.
correct program은 기본적으로 unspecified behavior를 포함하고 있으니까요.

Quote:

>중간 중간 감정적인 대응으로 부끄러운 글도 있었지만, 다행스럽게도
>기술적으로 유용한 내용으로 마무리가 되어 가는 느낌입니다.

네 어려울 것 없습니다.
whitenoise의 이미지

바로 위에 전웅님이 설명하셨듯이 출력의 의존성에 출력의 여부도 포함된다는 사실을 이해 못하셨던 거군요. 그 부분을 잘못 이해하실 경우는 제가 미처 생각을 못해서 제 질문에 대한 답변으로 오해했습니다.

그렇다면, 전웅님이 쓰신 위 답글의 두가지 내용을 마저 이해하시면 이제 추론에 필요한 논리는 다 나온 것 같으니, 좀 늦은 감이 있으나 다시 정리하는 의미에서 제 질문에 대한 답을 들을 수 있을까요?

제가 이야기하고 싶었던 핵심은 아래 인용 부분임을 염두에 두시고 이해 안되거나 틀렸다고 생각되는 부분은 질문이나 지적 부탁드립니다.

whitenoise wrote:
Specification(technical standard)이란 것의 목적은 요구사항에 맞는 것과 그렇지 않은 것을 구분해 내는데 있습니다. 즉, S={x|P(x)}를 결정하는 P(x)를 기술한 것입니다. 이때 Correctness는 x∈S를 말하는 것이고, undefined behavior란 Q(x) → ~P(x)인 Q(x)를 말하는 것일 뿐입니다. 매우 간단하죠? 보시다시피 implementation과는 전혀 상관없는 개념들입니다.
전웅의 이미지

> >
> >또 다른 질문 하나 드려보겠습니다. 인용하신 규정을 어기는 예 하나를
> >보여보시기 바랍니다. 즉, unspecified behavior 에 출력이 의존하는
> >(따라서 strictly conforming program 이 아닌) 프로그램 하나 만들어
> >보시기 바랍니다.
> >
> >또, 반대로 unspecified behavior 를 포함하지만 출력이 그 행동에
> >의존하지 않는 (따라서 strictly conforming program 인) 예를 하나 만들어
> >보시기 바랍니다.
>
> #include
> #define AA "04"
> void do_my_job()
> {
> // send my inputs to the blackhole
> }
> void do_your_job()
> {
> // send your inputs to the stdout
> }
> int main(int argc, char **argv)
> {
> if (AA == "04") { // gcc 3.4.2 compiler
> do_my_job();
> }
> else { // Sun C 5.8 compiler
> do_your_job();
> }
> return 0;
> }
>

정작 중요한 "to the blackhole", "to the stdout" 부분을 주석으로 대체
하셔서 님이 의도하신 바대로 프로그램을 이해한다고 해도, 이 프로그램은
제가 부탁드린 2가지 프로그램을 모두 보여주신 것이 아닙니다. 단지,
출력이 unspecified behavior 에 의존하는 프로그램 (즉, 제 글의 첫번째
프로그램) 을 보여주신 것에 불과합니다. 이 프로그램은 s.c. program 은
아니지만 correct program 에 해당합니다.

표준에서 strictly conforming program 을 제한할 때 사용한 "output" 은
에 의해 이루어지는 출력을 말합니다. 보다 정확히 모든 출력이
결국은 fputc 에 의해 이루어지는 것처럼 정의되어 있기 때문에, 결국
fputc 에 의해 이루어지는 출력만을 의미합니다.

따라서 어떤 프로그램이 애초에 출력을 생성하지 않는다면 그 프로그램은
unspecified behavior 를 포함해도 s.c. program 으로 남을 수 있습니다.

하지만, 어떤 프로그램이 출력을 생성하고 그리고 그 출력이 unspecified
behavior 에 의존한다면, 해당 프로그램은 s.c. program 이 될 수
없습니다. 그럼에도 여전히 correct program 으로 남을 수 있습니다.

>
> 위 다른 분의 답변도 포함합니다.
> 어떤 conforming implementation이냐에 따라 s.c. program이 될 수도
> 있고 아닐 수도 있습니다.
>

아하, 님께서 어느 부분을 오해하고 계신지 알았습니다 - 저 위의 코드와
이 주장을 함께 보니 보이는군요.

같은 논리라면, 말씀하신대로 한 implementation 에서는 s.c. program 이
다른 implementation 에서는 NOT s.c. program 이 되는 것이 아니라, 두
implementation 모두에서 s.c. program 이 되어야 합니다. 즉, gcc 3.4.2
에서는 출력을 아예 생성하지 않으므로 s.c. program 이고, Sun 에서는
(항상 do_your_job() 을 호출해) 동일한 출력을 생성함으로써 s.c. program
이 됩니다 (사용자 입력이 달라지면서 출력이 달라지는 것은 프로그램을
NOT s.c. program 으로 만들지 않습니다).

하지만, 님이 다른 글에서

>
> strictly conforming program이 모든 implementation에 대해서 동일한 결과를 가져와야한다는데 동의합니다.
>

라고 말씀하셨듯이 이는 잘못된 논리입니다. "AA" == "AA" 가 참으로 평가
되는지는 표준에서 unspecified behavior 입니다. 보여 주신 프로그램은 한
implementation 에서는 수식을 참으로 평가하며 그에 의존해 출력을
생성하며, 다른 implementation 에서는 거짓으로 평가하며 출력을 생성하지
않습니다. 그 자체가 해당 프로그램을 NOT s.c. program 으로 만들게
됩니다. 위와 같은 코드를 놓고 한 implementation 에서는 s.c. program,
다른 implementation 에서는 not s.c. program 이라고 부르거나, 혹은 두
implementation 에서 모두 s.c. program 이라고 부르지 않습니다.

>
> 제가 단기간에 표준에 관한 전체적인 안목에서 볼 수 없다는 것을 인정합니다.
> 그러나 있는 그대로 저도 해석할 수 있는 권리(?)가 있습니다. 저의 그런 시도를
> 허용할 여지를 텍스트는 있는 그대로 말하고 있는 것입니다. 이것이 순진한 저의
> 해석때문이라면 전 이미 무식하고 용감하게 그 댓가를 치루고 있습니다.
> 제가 그 이상 또는 그 이하로 쓸 데 없는 말을 들을 필요가 없는 것입니다.
>

넵, 주어진 표준 텍스트를 있는 님 마음대로 해석하실 권리가 있습니다.
하지만 솔직히 잘못 해석한 내용을 그토록 당당하게 주장하실 권리도 있는
지 저는 잘 모르겠습니다. 하지만, 분명한 것은 잘못된 주장에 대해 반박할
권리도 저를 포함해 다른 분들에게 있다는 것입니다.

님이 상당히 짧은 시간에 논의에 필요한 표준의 부분을 상당히 정확하게
찾아서 이해하려 하고 계신다는 것은 분명한 사실입니다 - 상당히 인상
깊은 부분입니다. 제가 "그 이상 그 이하"의 말씀을 드린 부분은 단지
상당히 확고한 어조로 잘못된 주장을 하시기 전에 질문 등을 통해 좀 더
확인해 주시길 부탁드린 것입니다. 님 스스로가 표준에 대해 전체적인
안목이 없다고 인정하셨으니 님께서 무엇인가를 오해하실 가능성이 있다는
것은 당연한 일이고, 따라서 무엇인가를 이해하시기 전에 질문 등을 통해
그와 같은 가능성을 줄이는 것은 그리 어려운 일이 아니라고 생각합니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:

>따라서 어떤 프로그램이 애초에 출력을 생성하지 않는다면 그 프로그램은
>unspecified behavior 를 포함해도 s.c. program 으로 남을 수 있습니다.

do_your_job()을 다음과 같이 고치면,

void do_your_job()
{
    // do some other jobs with no output but not same with do_my_job()
}

이것은 s.c. program이 모든 implementation에 대해서 동일한 결과를 가져와야한다는데 위배
됩니다. 이것을 표준에서 용어 선택의 문제라고 보고 어떤 unspecified behavior일 출력을
생성하든 하지 않든 간에 포함하는 것만으로도 s.c. program이 될 수 없다라고 고치면 말이 됩니다.

현재 텍스트에서는 unsepecified behavior와 관련해서 다음과 같이 나눌 수 있습니다.
1. 출력에 영향을 주는 unspecified behavior
2. 출력에 영향을 주지 않는 unspecified behavior
2.1 동일한 결과에 영향을 주는 unspecified behavior
2.2 동일한 결과에 영향을 주지 않는 unspecified behavior

이런 상황을 고치려면

Quote:

결국
fputc 에 의해 이루어지는 출력만을 의미합니다.

라는 의미의 출력이란 개념을 수정해야 하는 것입니다.
그러나 4p5에서도 언급됐듯이 "only those features of the language and library
specified in this International Standard"이란 의미로도 커버가 된다고 생각합니다.

그래서 전,

Quote:

output(출력)을 unspecified behavior에 의존한다는 뜻이 출력을 produce(생산)
> 한다는 뜻이 아님이 분명합니다.

라고 말한 것입니다.
전웅의 이미지

> >
> >따라서 어떤 프로그램이 애초에 출력을 생성하지 않는다면 그 프로그램은
> >unspecified behavior 를 포함해도 s.c. program 으로 남을 수 있습니다.
>
> do_your_job()을 다음과 같이 고치면,
>
> void do_your_job()
> {
> // do some other jobs with no output but not same with do_my_job()
> }
>
> 이것은 s.c. program이 모든 implementation에 대해서 동일한 결과를 가져와야한다는데 위배
> 됩니다.
>

표준은 동일한 "결과"라는 표현을 사용하지 않습니다. s.c. program 이
모든 implementation 에서 동일한 "출력(output)"을 보여야 한다는 것이
요구입니다. 동일한 "행동"을 보여야 한다는 것이 요구가 아닙니다.

실례로 위원회 회의록을 보시면 프로그램 실행 중의 다양한 행동을 관찰할
수 있는 debugger 를 위원회는 conforming implementaion 이 아니라고
강조한 바 있습니다. 또한, csc 논의를 검색해 보시면 s.c. program 을
제한할 때 사용한 "output" 의 의미에 대한 위원회 멤버의 답변을 찾으실
수 있습니다. 확인해 보시기 바랍니다.

>
> 이것을 표준에서 용어 선택의 문제라고 보고 어떤 unspecified behavior일 출력을
> 생성하든 하지 않든 간에 포함하는 것만으로도 s.c. program이 될 수 없다라고 고치면 말이 됩니다.
>

do_your_job(), do_my_job() 모두 출력을 생성하지 않으면 s.c. program
이 됩니다. s.c. program 에서 중요한 것은 이식성 없는 행동에 의존해
(stdio.h 를 통해) "출력"을 생성하느냐는 것입니다.

>
> 현재 텍스트에서는 unsepecified behavior와 관련해서 다음과 같이 나눌 수 있습니다.
> 1. 출력에 영향을 주는 unspecified behavior
> 2. 출력에 영향을 주지 않는 unspecified behavior

이 둘의 구분만 의미가 있습니다.

> 2.1 동일한 결과에 영향을 주는 unspecified behavior
> 2.2 동일한 결과에 영향을 주지 않는 unspecified behavior
>

이 둘은 s.c. program 의 관점에서 무의미합니다. 예를 들어,

#include &lt;stdio.h&gt;
#include &lt;limits.h&gt;
 
int main(void)
{
    unsigned char uc;
 
    if (uc < UCHAR_MAX / 2)
       printf("%d\n", uc - uc);
    else
       printf("%d\n", 0);
 
    return 0;
}

이와 같은 코드는 unspecified behavior 를 포함하고 그에 따라 uc 에 다른
값이 담기고 또 프로그램의 행동도 달라지지만, 항상 0 을 출력하기 때문에
s.c. program 입니다. 하물며, 결과를 아무 것도 출력하지 않으면
undefined behavior 를 일으키지 않는 범위 내에서 uc 를 가지고 무엇을
하든 당연히 s.c. program 으로 남게됩니다.

위와 유사한 예는 이전에 말씀드린 제 책에서도 다룬 바 있습니다.
혹시라도 제가 드린 말씀을 도저히 못 믿으시겠다면 저 예를 그대로 옮겨
s.c. program 인지 묻는 질문을 뉴스그룹에 올려 보시기 바랍니다 - 제
기억으론 csc 에서 C90/C99 의 차이를 논하면서 제가 유사한 예를 s.c.
program 이라며 게시했던 것으로 알고 있습니다.

>
> 이런 상황을 고치려면
>
> > 결국
> > fputc 에 의해 이루어지는 출력만을 의미합니다.
>
> >
> 라는 의미의 출력이란 개념을 수정해야 하는 것입니다.
>
[...]
>
> 그래서 전,
> > output(출력)을 unspecified behavior에 의존한다는 뜻이 출력을 produce(생산)
> > 한다는 뜻이 아님이 분명합니다.
>
> 라고 말한 것입니다.
>

s.c. program 을 기술할 때 말한 output 은 fpuct 에 의해 이루어지는
출력만을 의미합니다. 표준이 기술한 "output" 에는 프로그램의 "행동"은
포함되지 않습니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

그럼 위원회는,

Quote:

#include
#include

int main(void)
{
unsigned char uc;

if (uc < UCHAR_MAX / 2) {
malloc(INT_MAX);
printf("%d\n", uc - uc);
}
else {
printf("%d\n", 0);
}

return 0;
}


같은 프로그램도 s.c. program으로 인정한단 말이네요.
전웅의 이미지

> 그럼 위원회는,
>
> #include
> #include
>
> int main(void)
> {
> unsigned char uc;
>
> if (uc < UCHAR_MAX / 2) {
> malloc(INT_MAX);
> printf("%d\n", uc - uc);
> }
> else {
> printf("%d\n", 0);
> }
>
> return 0;
> }
>
> 같은 프로그램도 s.c. program으로 인정한단 말이네요.
>

이런... 현재 KLDP 에서 코드가 다 깨져 나오는군요. --;

&lt;, &gt; 를 사용하지 않으셔서 어떤 헤더가 #include 되었는지
보이지 않지만, 제 코드를 그대로 가져가셨다고 가정할 때 stdio.h,
limits.h 라 가정하겠습니다. 또한, malloc 를 사용하셨으니 hosted
implementation 을 가정하셨다고 생각하겠습니다.

보여주신 코드는 의도와는 다르게 undefined behavior 를 포함할 수
있습니다. malloc 를 호출하시면서 stdlib.h 를 #include 하지 않으셨기
때문에 implementation 이 size_t 로 무엇을 선택하느냐에 따라 비원형
함수 호출 문맥에서 undefined behavior 가 발생할 수 있습니다.

하지만, 분명 이것이 의도가 아니니 #include <stdlib.h> 를
하셨다고 가정하겠습니다.

이 경우 원형 선언에 의해 INT_MAX 값이 무부호 정수형이 size_t 형으로
(wrap-around 가 일어날지언정) 항상 안전하게 변환되기 때문에 malloc
호출에는 아무 문제 없습니다. 또한, malloc 가 할당에 성공하든 실패하든
프로그램 출력에는 영향을 주지 않기 때문에 보여주신 코드는 s.c. program
이 맞습니다.

다소 비직관적으로 보이실 수 있겠지만 표준에는 그보다 더 비직관적인
부분들도 많습니다. 표준을 보실 때에는 언어에 대해 경험이나 다른 책을
통해 얻은 고정 관념을 버리신 후 접근하시는 것이 이해에 큰 도움이
됩니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

Quote:

>또한, malloc 가 할당에 성공하든 실패하든
>프로그램 출력에는 영향을 주지 않기 때문에 보여주신 코드는 s.c. program
>이 맞습니다.

malloc에 의해서 다른 프로그램이 할당할 메모리가 없어서 output이 달라집니다.
물론 리소스의 제한이 없다고 가정한다면 전혀 영향을 안 주는 것이겠지만요.

Quote:

and shall not exceed any
minimum implementation limit.

로 커버가 되겠군요. 그러나 그럴려면 다른 s.c. program까지 고려해야 하니
그렇지가 않군요.
전웅의 이미지

> >
> >또한, malloc 가 할당에 성공하든 실패하든
> >프로그램 출력에는 영향을 주지 않기 때문에 보여주신 코드는 s.c. program
> >이 맞습니다.
>
> malloc에 의해서 다른 프로그램이 할당할 메모리가 없어서 output이 달라집니다.
> 물론 리소스의 제한이 없다고 가정한다면 전혀 영향을 안 주는 것이겠지만요.
> 인용:
> and shall not exceed any
> minimum implementation limit.
>
> 로 커버가 되겠군요. 그러나 그럴려면 다른 s.c. program까지 고려해야 하니
> 그렇지가 않군요.
>

무엇인가를 단정하시기 전에 질문 먼저 해보시길 부탁드립니다. 지금까지
여러 번 볼 수 있듯이 표준은 그 내용을 쉽게 오해할 수 있는 문서입니다.
표준에 대한 전체적인 틀을 잡기 전까지 자신이 읽고 이해한 내용에 대해
우선적으로 의심을 해보는 것이 정확한 내용을 파악하는데 중요한 역할을
합니다 - 경험에서 우러나온 이야기입니다, 초기 제가 각 뉴스그룹에
포스팅한 글을 보시면 아시겠지만 대부분 질문에서 시작해 점차 주장으로
그 형태가 변해 가시는 것을 보실 수 있습니다.

s.c. program 을 말할 때 min. implementation limit 은 malloc 와는 무관
합니다. 흔히 "rubber teeth" 로 불리는 5.1.4.1 의 translation limit 을
의미하는 것입니다. 불과 수개월 전에 "min. implementation limit" 의
의미에 대한 논의가 csc 에 있었습니다. 가능하면 확인해 보시기
바랍니다.

malloc 는 자신이 메모리를 할당할 수 없으면 null pointer 를 그렇지
않으면 할당된 메모리를 반환하도록 행동이 정의되어 있습니다. 더구나
malloc 의 인자가 갖는 type 으로 인해 malloc 에 이론적으로만 가능한
무한대의 메모리를 요청할 수 있는 것도 아닙니다. malloc 를 적법하게
호출하고 그 결과를 무시해 버렸다고 해서 min. implementation limit 을
어기는 것은 아닙니다.

거의 표준 문장의 한 부분 한 부분을 주석을 달듯이 설명을 드리고 있는
듯 합니다. 원 주제와 관련된 문제는 거의 다 정리된 듯 싶으니 이제 이
글타래는 마감하는 것이 좋겠습니다.

표준 해석 중 생긴 다른 궁금한 부분은 별도의 주제를 시작하시거나,
뉴스그룹을 이용하시는 것이 낫지 않을까 생각해 봅니다 - 더구나 이 동네
사람들 이런 이야기 별로 안 좋아 합니다.

그럼...

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

--
Jun, Woong (woong at gmail.com)
http://www.woong.org

modestcode의 이미지

단정코자 단 커멘트가 아닙니다.
malloc limit이 어디이 있던 간에 malloc에 의존하는 출력이 있을 것이고
이것을 무시할 수 있다는 뜻이 됩니다.

Quote:

>표준 해석 중 생긴 다른 궁금한 부분은 별도의 주제를 시작하시거나,
>뉴스그룹을 이용하시는 것이 낫지 않을까 생각해 봅니다 - 더구나 이 동네
>사람들 이런 이야기 별로 안 좋아 합니다.

앞으로 csc를 이용하도록 하지요.

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.