>
> malloc limit이 어디이 있던 간에 malloc에 의존하는 출력이 있을 것이고
> 이것을 무시할 수 있다는 뜻이 됩니다.
>
이전 글에서 malloc 사용으로 resource 가 부족해 다른 프로그램에 영향을
주는 경우를 언급하셨는데, 이전에 말씀드렸듯이 표준은 single thread
만을 가정하고 있기 때문에 표준을 논할 때는 다른 프로그램에 주는
영향을 논할 수 없습니다. 실제 예가 되고 있는 malloc 를 호출하고 그
결과를 무시해버리는 코드 만을 이야기해야 합니다. 물론, 문제의 코드
에서 malloc 의 반환값에 따라 출력 결과를 달리 한다면 더 이상 s.c.
program 으로 남을 수 없습니다.
> >
> >표준 해석 중 생긴 다른 궁금한 부분은 별도의 주제를 시작하시거나,
> >뉴스그룹을 이용하시는 것이 낫지 않을까 생각해 봅니다 - 더구나 이 동네
> >사람들 이런 이야기 별로 안 좋아 합니다.
>
> 앞으로 csc를 이용하도록 하지요.
>
넵, 잘 알고 계시겠지만, topic 과 (형식적인 측면의) 뉴스그룹 매너만 잘
지켜 주시면 여기서보다 더 만족스러운 답변을 얻으실 수 있을 겁니다.
csc 는 표준 해석에 대한 질문, clc 나 clcm 은 (표준 C 언어를 기반으로
한) 일반적인 프로그래밍 문제를 다루는 그룹으로 생각하시면 됩니다.
>
> 프로그램이 unspecified behavior에 의존한다는 뜻이
>
> 3.4p1에 있는 behavior의 의미로
> 인용:
> external appearance or action
>
> 인데 제가 예제에서 든 것이 이 분류 안에 들어가지 못할 이유가 무엇이라고 생각하세요?
>
behavior 의 정의가 그러하다고 해서 output 의 자격을 갖지는 못합니다.
실제 표준은 output 을 표준 안에서 배타적으로 정의해주지 않고 있습니다
- 따라서 님이 의심하시는 것이 무리는 아닙니다. 때문에 csc 에서는 s.c.
program 을 기술할 때 표준이 말하는 output 이 뭐냐를 놓고 열띤 논쟁이
있었던 적이 있었고, 최종적으로 위원회의 답변은 stdio.h 에 의한
명시적인 출력만을 의도한 것이라 답변한 바 있습니다. 아마도 이 이후
개정에서 보다 엄격한 정의가 추가될 것이라 기대하고 있습니다 - 현재
제가 제출하기 위해 정리해놓은 PDR list 에 포함되어 있는 항목입니다.
s.c. program 을 논할 때에는, 이미 여러번 언급되었듯이 단순히
unspecified 혹은 implementation-defined behavior 를 포함했느냐, 혹은
그로 인해 프로그램의 행동이 달라지느냐가 기준이 되지 못합니다. 오직
출력이 그런 행동에 의존하느냐만이 기준이 됩니다. 이것이
Quote:
It shall not produce output dependent on any unspecified, undefined,
or implementation-defined behavior, ...
output의 의미는 건드리지 않고, behavior 자체의 의미에서,
malloc과 같은 다른 action을 유발하는 것을 포함한다고 생각
할 수 없냐는 것입니다.
s.c. program이냐 아니냐 문제는 "A strictly conforming program
shall use only those features of the language and library
specified in this International Standard."
라는 의미로 커버하고요.
>
> output의 의미는 건드리지 않고, behavior 자체의 의미에서,
> malloc과 같은 다른 action을 유발하는 것을 포함한다고 생각
> 할 수 없냐는 것입니다.
> s.c. program이냐 아니냐 문제는 "A strictly conforming program
> shall use only those features of the language and library
> specified in this International Standard."
> 라는 의미로 커버하고요.
>
굳이 malloc 를 호출해야만 behavior 에 의한 어떤 action 이 유발되는
것은 아닙니다. main 함수를 시작하는 것, 전처리문을 처리하는 것, 각
문장을 실행하는 것, if 문에 의해 분기하는 것, 변수에 값을 저장하는 것
등 모두가 action 입니다. malloc 를 적법한 인자를 통해 호출하는 것
자체는 더구나 표준에 의해 정의된 행동입니다. (undefined behavior 를
통한 action 이 아닌 이상) 그와 같은 정상적인 action (unspecified/
implementation-defined behavior 포함) 을 일으키는 것만으로 어떤
프로그램의 strictly conforming 여부를 바꿀 수는 없습니다.
만약, 그처럼 특정 action (예를 들면, unspecified beheavior) 을
포함하는 것이 위원회의 의도였다면, output 어쩌구 저쩌구 하는 부분에서
힘들게 output 을 언급할 필요도 없이 단순히 그와 같은 행동에 의존할 수
없다고만 명시했을 것입니다.
솔직히 개인적인 생각을 적자면, 지금 modestcode 님이 어떤 기술적 내용에
대해서 올바르게 이해하기 위해, 혹은 다른 사람의 글을 올바르게 이해하기
위해, 혹은 최소한 제가 쓴 글의 기술적 오류를 정당하게 지적하기 위해
이 논의를 지리하게 끌고 있다고 생각하지 않습니다.
또한, 표준이며 관련 문서가 열심히 인용되고 있지만, modestcode 님이 이
기회를 통해 체계적으로 표준을 공부하고 계신 것이라 생각하지도
않습니다 - 이 논의가 끝나고 과연 표준을 펴보시기라도 할지 궁금합니다.
논의 초기에는 의심, 지금은 거의 확신 수준이지만, modestcode 님의
유일한 목적은 제 "잘못"을 찾는 것입니다. 한 부분에 대해 시도하다가
그게 되지 않으면 다시 다른 부분, 다시 다른 부분을 수차례 반복하고
있습니다. 애초에 문제가 되었던 부분은 이미 마무리가 되었음에도 제가
글 쓰며 인용했던 부분, 사용했던 표현 하나하나에 딴지거리만 찾고 있다는
생각이 강하게 들 뿐입니다.
지금까지는 modestcode 님의 주장이 잘못되었음을 보이기 위해 관련 내용을
인용하고 설명하며 이해를 도우려 했으나 (그나마 그렇게 하지 않으면 이
논의를 지리하게 끄는 것 자체가 부당하다고 생각했습니다), 더 이상 의미
가 없다는 생각에 modestcode 님이 스스로 문제 삼고 있는 부분을 제대로
이해한 후에 그와 같은 주장을 하고 계신지 묻기 위한 질문으로 답변을
대신하려 합니다.
개인적으로 (올린 글이 많진 않지만) 이곳에 글을 쓰며 뺏기는 시간이 적지
않아 이 논의를 마무리하고 더 이상 글쓰기를 하지 않으려 했으나 쉽게
끝나지 않는군요.
>
> 행동의 차이를 만들든 안 만들든 간에, 출력의 차이를 만들지 않는 unspecified behavior를
> 포함하고 있는 프로그램이 s.c. program이라고 했을 때도,
> unspecified behavior를 포함하지 않는 s.c. program이 unspecified behavior를 포함하고
> 5.1.2.3에 따라 행동하는 correct program과 차이가 좁혀 지지 않습니다.
> correct program은 기본적으로 unspecified behavior를 포함하고 있으니까요.
>
unspecified behavior 를 포함하지 않는 s.c. program 도 correct program
입니다. correct program 을 설명하는 곳에서 correct program 이
unspecified behavior 를 반드시 포함해야 한다고 요구하는 부분은
없습니다. s.c. program 과 마찬가지로 단지 unspecified behavior 를
"포함할 수" 있는 것입니다 - 해당 부분을 자세히 보시면 "unspecified
behavior 를 포함할 수 있음" 을 의미하는 것이지, "unspecified behavior
를 포함해야 함" 을 의미하는 것이 아님을 확인하실 수 있습니다.
추가로 제가 이전에 각 program 의 특성을 정리해 놓은 부분을 참고하시기
바랍니다 - 이 역시 제가 오래전 위원회 멤버와 메일로 논의를 주고 받을
때 정리했던 것을 이해가 쉽도록 옮겨놓은 것입니다. s.c. program 은
correct program 이 갖는 제한에 "더해" 출력과 관련된 추가적인 제한을
가지고 있습니다. 따라서 일단 s.c. program 의 제한을 만족하게 되면
correct program 의 제한을 만족할 수 밖에 없게 되는 것입니다.
> 단정코자 단
>
> 단정코자 단 커멘트가 아닙니다.
넵, 제가 글을 급하게 읽어 오해한 부분이 없지 않습니다.
>
> malloc limit이 어디이 있던 간에 malloc에 의존하는 출력이 있을 것이고
> 이것을 무시할 수 있다는 뜻이 됩니다.
>
이전 글에서 malloc 사용으로 resource 가 부족해 다른 프로그램에 영향을
주는 경우를 언급하셨는데, 이전에 말씀드렸듯이 표준은 single thread
만을 가정하고 있기 때문에 표준을 논할 때는 다른 프로그램에 주는
영향을 논할 수 없습니다. 실제 예가 되고 있는 malloc 를 호출하고 그
결과를 무시해버리는 코드 만을 이야기해야 합니다. 물론, 문제의 코드
에서 malloc 의 반환값에 따라 출력 결과를 달리 한다면 더 이상 s.c.
program 으로 남을 수 없습니다.
> >
> >표준 해석 중 생긴 다른 궁금한 부분은 별도의 주제를 시작하시거나,
> >뉴스그룹을 이용하시는 것이 낫지 않을까 생각해 봅니다 - 더구나 이 동네
> >사람들 이런 이야기 별로 안 좋아 합니다.
>
> 앞으로 csc를 이용하도록 하지요.
>
넵, 잘 알고 계시겠지만, topic 과 (형식적인 측면의) 뉴스그룹 매너만 잘
지켜 주시면 여기서보다 더 만족스러운 답변을 얻으실 수 있을 겁니다.
csc 는 표준 해석에 대한 질문, clc 나 clcm 은 (표준 C 언어를 기반으로
한) 일반적인 프로그래밍 문제를 다루는 그룹으로 생각하시면 됩니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
프로그램이 unspecified
프로그램이 unspecified behavior에 의존한다는 뜻이
3.4p1에 있는 behavior의 의미로
인데 제가 예제에서 든 것이 이 분류 안에 들어가지 못할 이유가 무엇이라고 생각하세요?
> 프로그램이
>
> 프로그램이 unspecified behavior에 의존한다는 뜻이
>
> 3.4p1에 있는 behavior의 의미로
> 인용:
> external appearance or action
>
> 인데 제가 예제에서 든 것이 이 분류 안에 들어가지 못할 이유가 무엇이라고 생각하세요?
>
behavior 의 정의가 그러하다고 해서 output 의 자격을 갖지는 못합니다.
실제 표준은 output 을 표준 안에서 배타적으로 정의해주지 않고 있습니다
- 따라서 님이 의심하시는 것이 무리는 아닙니다. 때문에 csc 에서는 s.c.
program 을 기술할 때 표준이 말하는 output 이 뭐냐를 놓고 열띤 논쟁이
있었던 적이 있었고, 최종적으로 위원회의 답변은 stdio.h 에 의한
명시적인 출력만을 의도한 것이라 답변한 바 있습니다. 아마도 이 이후
개정에서 보다 엄격한 정의가 추가될 것이라 기대하고 있습니다 - 현재
제가 제출하기 위해 정리해놓은 PDR list 에 포함되어 있는 항목입니다.
s.c. program 을 논할 때에는, 이미 여러번 언급되었듯이 단순히
unspecified 혹은 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
output의 의미는
output의 의미는 건드리지 않고, behavior 자체의 의미에서,
malloc과 같은 다른 action을 유발하는 것을 포함한다고 생각
할 수 없냐는 것입니다.
s.c. program이냐 아니냐 문제는 "A strictly conforming program
shall use only those features of the language and library
specified in this International Standard."
라는 의미로 커버하고요.
이 부분은 언급 안 된
이 부분은 언급 안 된 문제고 재귀적인 의미가 들어가기 때문에 무시해야 겠네요.
> output의 의미는
>
> output의 의미는 건드리지 않고, behavior 자체의 의미에서,
> malloc과 같은 다른 action을 유발하는 것을 포함한다고 생각
> 할 수 없냐는 것입니다.
> s.c. program이냐 아니냐 문제는 "A strictly conforming program
> shall use only those features of the language and library
> specified in this International Standard."
> 라는 의미로 커버하고요.
>
굳이 malloc 를 호출해야만 behavior 에 의한 어떤 action 이 유발되는
것은 아닙니다. main 함수를 시작하는 것, 전처리문을 처리하는 것, 각
문장을 실행하는 것, if 문에 의해 분기하는 것, 변수에 값을 저장하는 것
등 모두가 action 입니다. malloc 를 적법한 인자를 통해 호출하는 것
자체는 더구나 표준에 의해 정의된 행동입니다. (undefined behavior 를
통한 action 이 아닌 이상) 그와 같은 정상적인 action (unspecified/
implementation-defined behavior 포함) 을 일으키는 것만으로 어떤
프로그램의 strictly conforming 여부를 바꿀 수는 없습니다.
만약, 그처럼 특정 action (예를 들면, unspecified beheavior) 을
포함하는 것이 위원회의 의도였다면, output 어쩌구 저쩌구 하는 부분에서
힘들게 output 을 언급할 필요도 없이 단순히 그와 같은 행동에 의존할 수
없다고만 명시했을 것입니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
다음 두 문장을 이해할 수 없었습니다.
> output(출력)을 unspecified behavior에 의존한다는 뜻이 출력을 produce(생산)
> 한다는 뜻이 아님이 분명합니다.
무슨 말인지 이해하지 못했습니다. 죄송하지만, 풀어서 설명좀 부탁드립니다.
-- 덧붙이는 글 --
글을 쓰고보니 전웅님께서 글을 올려셨군요.
저도 저 주장을 보고
저도 저 주장을 보고 참 당황했습니다.
솔직히 개인적인 생각을 적자면, 지금 modestcode 님이 어떤 기술적 내용에
대해서 올바르게 이해하기 위해, 혹은 다른 사람의 글을 올바르게 이해하기
위해, 혹은 최소한 제가 쓴 글의 기술적 오류를 정당하게 지적하기 위해
이 논의를 지리하게 끌고 있다고 생각하지 않습니다.
또한, 표준이며 관련 문서가 열심히 인용되고 있지만, modestcode 님이 이
기회를 통해 체계적으로 표준을 공부하고 계신 것이라 생각하지도
않습니다 - 이 논의가 끝나고 과연 표준을 펴보시기라도 할지 궁금합니다.
논의 초기에는 의심, 지금은 거의 확신 수준이지만, modestcode 님의
유일한 목적은 제 "잘못"을 찾는 것입니다. 한 부분에 대해 시도하다가
그게 되지 않으면 다시 다른 부분, 다시 다른 부분을 수차례 반복하고
있습니다. 애초에 문제가 되었던 부분은 이미 마무리가 되었음에도 제가
글 쓰며 인용했던 부분, 사용했던 표현 하나하나에 딴지거리만 찾고 있다는
생각이 강하게 들 뿐입니다.
지금까지는 modestcode 님의 주장이 잘못되었음을 보이기 위해 관련 내용을
인용하고 설명하며 이해를 도우려 했으나 (그나마 그렇게 하지 않으면 이
논의를 지리하게 끄는 것 자체가 부당하다고 생각했습니다), 더 이상 의미
가 없다는 생각에 modestcode 님이 스스로 문제 삼고 있는 부분을 제대로
이해한 후에 그와 같은 주장을 하고 계신지 묻기 위한 질문으로 답변을
대신하려 합니다.
개인적으로 (올린 글이 많진 않지만) 이곳에 글을 쓰며 뺏기는 시간이 적지
않아 이 논의를 마무리하고 더 이상 글쓰기를 하지 않으려 했으나 쉽게
끝나지 않는군요.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
> 행동의 차이를
>
> 행동의 차이를 만들든 안 만들든 간에, 출력의 차이를 만들지 않는 unspecified behavior를
> 포함하고 있는 프로그램이 s.c. program이라고 했을 때도,
> unspecified behavior를 포함하지 않는 s.c. program이 unspecified behavior를 포함하고
> 5.1.2.3에 따라 행동하는 correct program과 차이가 좁혀 지지 않습니다.
> correct program은 기본적으로 unspecified behavior를 포함하고 있으니까요.
>
unspecified behavior 를 포함하지 않는 s.c. program 도 correct program
입니다. correct program 을 설명하는 곳에서 correct program 이
unspecified behavior 를 반드시 포함해야 한다고 요구하는 부분은
없습니다. s.c. program 과 마찬가지로 단지 unspecified behavior 를
"포함할 수" 있는 것입니다 - 해당 부분을 자세히 보시면 "unspecified
behavior 를 포함할 수 있음" 을 의미하는 것이지, "unspecified behavior
를 포함해야 함" 을 의미하는 것이 아님을 확인하실 수 있습니다.
추가로 제가 이전에 각 program 의 특성을 정리해 놓은 부분을 참고하시기
바랍니다 - 이 역시 제가 오래전 위원회 멤버와 메일로 논의를 주고 받을
때 정리했던 것을 이해가 쉽도록 옮겨놓은 것입니다. s.c. program 은
correct 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
반드시 포함해야
반드시 포함해야 한다고 요구하는 부분은 확실히 없습니다.
그러나 그 외 의미도 확실하지 않습니다.
그러니 단지 포함하고는 확실하기 때문에 전 그렇게 해석했습니다.
좋습니다. 표준화 위원회에서 더 의미를 분명히 하기를 기대합니다.
> 반드시 포함해야
>
> 반드시 포함해야 한다고 요구하는 부분은 확실히 없습니다.
> 그러나 그 외 의미도 확실하지 않습니다.
> 그러니 단지 포함하고는 확실하기 때문에 전 그렇게 해석했습니다.
> 좋습니다. 표준화 위원회에서 더 의미를 분명히 하기를 기대합니다.
>
correct program 은 표준에서 conformance category 역할을 하는 개념도
아닙니다. 현재로서도 충분히 분명한 수준의 의미를 굳이 외면하고 계신
것뿐이며 앞으로 의미가 더 분명해 질 이유도 가능성도 없습니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
페이지
댓글 달기