C언어는 입출력, 메모리 관리, 문자열 처리와 같은 일상적 처리를 수행하는 장치들을 이미 완성된 도구로 제공하지는 않는다. 대신에, 이 도구들은 표준 라이브러리에 정의되어 있기 때문에, (이것들을 사용하여) 당신의 프로그램을 컴파일하고 링크할 수 있는 것이다.
이 문서에 기술되어 있는 GNU C의 라이브러리들은 ANSI C 뿐만 아니라 POSIX 또는 다른 유닉스 운영체제 및 GNU 시스템이 지정하는 여타 언어들에서도 적용되는 모든 라이브러리 함수들을 정의한다.
이 안내서의 목적은 GNU 라이브러리의 도구들을 사용하는 방법을 알려주는 데에 있다. 우리는 특히 다른 시스템에서는 아마도 사용할 수 없는 함수들이 가지는 특성들을 언급하였다. 다만, 이 안내서의 규정들이 엄격하게는 적용되지 않을 것이다.
이 안내서는 적어도 당신이 C 프로그래밍 언어나 기본적인 프로그래밍의 개념에 어느 정도 익숙하다는 것을 가정하고 씌어졌다. 특히 "전통적인" ANSI 이전의 C언어 통용어보다는 ANSI 표준 C언어에 친숙하다고 생각하였다.
GNU C 라이브러리는 몇몇 헤더파일을 갖고 있는데, 각 헤더파일은 관련함수들을 정의하고 선언한다; 이 정보는 당신의 프로그램이 처리될 때 C 컴파일러가 사용하게 된다. 예컨대, 헤더파일 'stdio.h'는 입출력을 수행하는 함수들을 선언하고, 헤더파일 "string.h'는 문자열 처리 도구들을 선언한다. 이 안내서의 편성은 헤더파일을 분류한 것과 똑같이 나누어져 있다.
이 안내서를 처음으로 읽을 때에는 모든 안내문과 설명들을 몽땅 읽는 게 좋다. GNU C의 라이브러리에는 많은 함수들이 있지만, 당신이 그 모든 것을 모두 정확하게 다 기억할 수는 없을 것이다. 그러므로, 라이브러리가 제공하는 각종 도구들에 널리 친숙해지고 난 다음에, 실제로 프로그램을 잘 때에 라이브러리 함수를 쓰는 법과 그 함수들에 대한 안내서의 특정 정보들을 빨리 찾아내는 것이 중요하다.
여기서는 GNU C라이브러리가 기초하고 있는 다양한 규정들과 소스에 관해서 논의하자. 이 소스들은 ANSI C와 POSIX 표준규정 및 V 시스템, 그리고 버클리 유닉스 장치들을 포함한다.
이 안내서의 첫 번째 주제는 당신이 어떻게 GNU 라이브러리의 도구를 효과적으로 사용할 것인가에 관한 것이다. 그러나 만약 당신이 이미 작성한 프로그램을 이들 표준과 일치시키고 싶어하거나 GNU보다는 운영체제의 활용 문제에 관심을 갖는다면, 이 안내서는 라이브러리 사용법을 아는 데 도움이 될 것이다.
부록 B [Library Summary]를 보면, 라이브러리가 제공하는 함수나 부호들의 알파벳순서 리스트가 있다. 여기에서 각 함수와 부호들이 어떤 표준도구에서 파생된 것인지를 알 수 있다.
GNU 씨 라이브러리는 미국 국가표준위원회(ANSI)에서 채택된 C언어 표준과 서로 통용된다. GNU 라이브러리가 작성한 헤더파일들과 라이브러리 도구들은 ANSI 표준 C언어에 의해 규정된 것들을 포함하면서 더 발전시켜 놓은 것이다.
만약 당신이 ANSI C언어만을 엄격하게 고수하겠다면, 프로그램 컴파일할 때에 '-ansi' 옵션을 사용하라. 이렇게 하면, 컴파일러가 알아듣고서 ANSI C 이외의 특성들을 제거해 줄 것이다. 1.3.4절 [Feature Test Macros] 참조
ANSI C언어는 라이브러리 도구에 의해서 정의될 수 있는 명칭에 한계를 두고 있지만, GNU는 이를 확장하여 한계를 넘어서고 있으므로, ANSI의 특성만을 살려주는 라이브러리 제한 옵션은 중요한 것이 된다. 1.3.3절 [Reserved Names] 을 참조할 것.
이 안내서에서는 GNU와 ANSI C의 차이점에 대한 완벽한 설명은 하지 않겠다. 물론 다른 C언어들과 함께 사용하는 충고들은 하겠지만 모든 것을 완전히 다 설명할 수는 없겠지?
GNU 라이브러리는 일반적인 컴퓨터 환경을 위한 운영체제 호환성으로 알려져 있는 IEEE POSIX와도 서로 통용된다. POSIX는 대체로 유닉스 운영체제의 수많은 버전들에서 유래된 말이다. POSIX 표준에 의해 규정된 라이브러리 도구들은 ANSI C에 의해 규정된 것들보다는 더 확장되어 있다; POSIX는 새로운 함수들을 포함할 뿐만 아니라 ANSI C의 함수들에 새로운 특성을 추가해 놓고 있다. 일반적으로, POSIX의 함수들은 다양한 운영체제에서 사용되는 고급 프로그램 언어들을 지원한다기보다는 특정한 운영체제의 환경을 지원하기 위하여 저급언어들을 제공하는데 초점을 둔다. GNU C라이브러리는 흔히 "POSIX.1"이라 불리는 POSIX 체제 적용 호환 프로그램, 즉, IEEE Std 1003.1-1990에 규정된 모든 함수들을 완성하였다. 여기에서 ANSI C의 도구들을 최초로 확장한 내용은
GNU 라이브러리는 IEEE Std 1003.2-1992의 몇몇 도구들과 POSIX shell, 그리고 표준 유틸리티들도 완성해 놓았다. 이들은 정규적인 표현들을 다루는 유틸리티뿐만 아니라 다른 형태로 적용되는 도구들까지 포함하고 있다. (16장)
GNU C라이브러리는 몇몇 유닉스 버전의 도구들을 정의하고 있다. 특히 유닉스 체제의 BSD의 버전4.2, 4.3, 4.4 (버클리 유닉스라 알려져 있는), 그리고 SunOS (유닉스 체제 V함수모음을 포함하는 4.2 BSD의 파생본)이 그것이다. 이러한 체제들은 ANSI와 POSIX의 대부분의 함수들을 지원하고 있으며, BSD 버전 4.4와 새로운 SunOS 배포본은 사실상 이 모든 것을 제공한다고 보아 무방할 것이다.
SVID는 AT&T 유닉스체제와 V 운영체제를 설명하는 문서다. 그것은 POSIX 표준을 어느 정도 확장한 것이다.(1.2.2 참조)
GNU C 라이브러리는 이러한 도구들을 담고 있는 V 유닉스 체제 및 또다른 유닉스 체제들( SunOS와 같은)을 무리 없이 사용하기 위해서, ANSI 또는 POSIX 표준규정들에 의해 요구되는 함수들을 정의하고 있다. 그러나, SVID가 필요로는 하지만 불명확하고 사용빈도가 낮은 함수들은 많이 제외시켰다. (사실, V 유닉스 체제 그 자체는 그것들을 모두 제공하지는 않는다.)
여기서는 GNU C의 라이브러리를 사용하는 데서 일어나는 실제적인 문제들을 설명하고자 한다.
C 프로그램에서 사용하는 라이브러리는 이 두 가지로 구성된다;
( C언어에서는, 선언은 오로지 함수나 변수가 존재한다는 정보를 제공하거나, 그 형태를 규정할 뿐임을 기억하라. 함수를 선언하려면, 함수의 형태에 관한 정보도 주어져야 한다. 선언을 하는 목적은 컴파일러가 선언된 변수나 함수를 정확하게 처리하도록 하는 데에 있다. 한편, 정의는 변수에 메모리를 할당하거나 함수가 무슨 일을 해야 하는지를 실제적으로 말해주는 것이다. )
GNU C의 라이브러리를 사용하기 위해서는, 당신은 당신의 프로그램 소스파일이 적합한 헤더파일을 포함시키고 있는지를 분명하게 알아야 한다. 왜냐하면, 컴파일러는 이러한 유용한 도구들의 선언을 갖고 있고 그것들을 정확하게 참조하여 처리를 수행하기 때문이다. 당신의 프로그램이 일단 컴파일되면, 링커는 저장된 파일에서 제공되는 실제적인 정의를 참조하면서 일을 수행한다. 헤더파일은 '#include'라는 전처리기 지시어에 의해 프로그램 소스파일로 포함되어진다. c언어는 이 지시어를 두개의 형태로 제공한다.
는 당신 스스로가 작성한 헤더파일을 포함시킬 때 사용하는 유형이다; 이것은 당신의 프로그램중의 다른 부분에서 불러다 쓸 정의나 선언을 담고 있다.
이와는 달리, #include <file.h> 는 표준라이브러리를 위한 정의와 선언을 담고 있는 헤더파일 'file.h'를 사용하는 유형이다. 이 파일은 컴퓨터의 시스템 관리자에 의하여 지정된 위치에 정상적으로 인스톨되어 있어야만 한다. 당신이 C 라이브러리의 헤더파일을 사용하려면 반드시 이 두 번째의 유형을 사용해야 한다.
형태적으로, '#include'라는 지시어는 C 소스파일 내에서 다른 어떤 코드보다도 맨 앞에 위치해야 한다. 만약에 당신이 이 프로그램은 무엇을 하는 프로그램인지를 설명하는 주석 문을 먼저 적고서 (이것은 아주 훌륭한 습관이다) 소스파일의 작성을 시작하려 한다면, 주석문의 바로 다음에 '#include'라는 지시어를 써야 하고 그 뒤에 매크로 정의가 따라 오게 된다.(1.3.4절)
헤더파일의 사용과 '#include' 지시어에 관한 더 자세한 내용은 The GNU C Preprocessor Manual(전처리기 사용법)의 "헤더파일"부분을 참조하라.
GNU C는 몇 개의 헤더파일을 제공하는데, 각 헤더파일은 일련의 관련기능을 위한 형태와 매크로의 정의, 변수 및 함수의 선언들을 담고 있다. 이것은 당신이 이 헤더파일들을 당신의 프로그램에 사용할 수 있음을 의미하는 것이며, 그것은 당신이 사용하고자 하는 기능에 맞는 것이어야 한다.
어떤 라이브러리 헤더파일들은 다른 라이브러리 헤더파일들을 자동적으로 담고 있다. 그러나, 프로그래밍의 스타일 문제이긴 하지만, 당신은 이에 의존해서는 안 된다. 당신이 사용하고자하는 라이브러리 도구들이 포함된 헤더파일들을 명시적으로 모두 써 주는 편이 훨씬 좋은 것이다.
GNU C의 라이브러리 헤더파일들은, 해당 헤더파일이 의도하지 않은 상태로 여러 번 중복되어 쓰여도 전혀 문제가 없도록 만들어져 있다; 물론 특정 헤더파일의 두 번째 호출은 아무런 효과가 없겠지만. 마찬가지로, 당신의 프로그램이 여러 개의 헤더파일을 사용한다 하드라도, 그것들이 포함되는 순서는 신경 쓸 필요가 없다.
호환성 노트 : 표준 헤더파일들을 아무런 순서로 몇 번씩 포함시키더라도 어떤 ANSI C의 실행에서도 작동한다. 그러나, 이러한 방법은 이전의 많은 C언어들에서는 전통적으로 허용되지 않는 경우였다. 엄밀히 말하자면 헤더파일이 선언한 함수를 사용하는 경우에도 헤더파일을 포함하지 않을 수도 있다; 이 안내서가 설명하는 데에 따라 당신 스스로가 그 함수를 명시적으로 선언해도 좋다. 그렇지만, 항상 헤더파일을 사용하는 편이 유리할 것이다. 왜냐하면, 헤더파일은 특정한 방법으로 사용할 수밖에 없는 형태와 매크로를 정의하고 있으며, 또한 어떤 함수들을 대신할 수 있는 보다 유효한 매크로들을 정의하고 있기 때문이다.이 안내서에서 어떤 것을 함수로 기술하고자 할 때, 그것은 매크로 정의로 될 수가 있다. 이 점은 프로그램의 실행에는 아무런 지장이 없다.__ 매크로 정의는 함수와 똑같은 역할을 한다. 특히 라이브러리 함수에 상응하는 매크로는 함수를 호출할 때와 같은 방식으로 규정들을 꼭 한번씩만 검토한다. 매크로를 정의하는 주된 이유는 종종 매크로가 함수를 호출하는 것보다 훨씬 더 빠른 처리를 하기 때문이다. 라이브러리 함수가 매크로로 정의된다고 하드라도 그 함수의 주소는 구해진다. 이는 구문 상으로 볼 때, 그 함수의 이름이 매크로를 호출하는 데 필요한 왼쪽 구문보다 뒤에 위치하기 때문이다.
당신은 때로는 --아마도 프로그램의 디버깅을 쉽게 하기 위하여--함수의 매크로 정의를 사용하지 않으려 할 것이다. 이렇게 하는데는 두 가지의 방법이 있다;
당신은 함수의 이름을 괄호로 묶어서 사용하는 방법으로 매크로 정의를 피할 수 있다. 이렇게 하면, 함수의 이름이 매크로를 호출하는 문장 상에 나타나지 않을 수 있다.
당신은 '#undef'라는 전처리기 지시어를 사용함으로써 전체 소스 상에 있는 어떠한 매크로 정의든지 취소할 수 있다. 만일 부가적으로 그 기능이 명시적으로 서술되지만 않는다면. 예를 들어, 헤더파일 'stdlib.h'가 외부정수 (int)를 갖는 abs라는 명칭의 함수를 선언한다고 가정하자; 또한 abs를 매크로 정의로 한다고 가정하자. 그러면,
이 경우에는 매크로로도 함수로도 참조될 수 있게 된다. 다른 한편, 다음의 각 경우에는 매크로로는 참조되지 않으며 다만 함수로서 참조될 뿐이다.
매크로가 함수와 중복되어 정의되더라도 그것은 실제적인 함수 호출과 똑같은 방식으로 작동하기 때문에, 언제나 이러한 방법을 채택할 필요는 조금도 없다. 사실상, 매크로 정의를 제거하게되면 프로그램의 실행이 더욱 느려질 것이다.
ANSI C의 표준에서 유래된 모든 라이브러리 형태, 매크로, 변수 및 함수의 명칭들은 모두 무조건적으로 예약되어 있다; 당신의 프로그램이 이 명칭들을 다시 정의할 필요가 없다. 만약 당신이 그것들을 선언한 헤더파일을 당신의 프로그램에 분명하게 포함시키기만 한다면, 다른 모든 라이브러리 명칭들도 예약되는 것이다. 이렇게 하는데는 몇 가지 이유가 있다.
예컨대, 당신이 만일 표준규정과는 완전히 다른 이름을 붙여서 멋대로 함수를 사용하게 되면, 다른 사람들이 당신의 소스코드를 읽다가 큰 혼란에 빠질 것이다. 이런 사태를 막기 위해서 당신은 프로그램을 이해하기 쉽도록 짜야되며 모듈화하고 알 수 있게 하여야 한다.
또한 사용자가 우연하게도 다른 라이브러리 함수에서 호출된 함수를 다시 정의하게 될 가능성도 막아야 한다. 만약 중복되는 정의가 허용된다면, 다른 함수들은 제대로 작동할 수 없을 것이다.
컴파일러는 사용자가 함수를 다시 정의하지 않더라도 그것들이 호출될 때 어떻게 처리해야 하는지를 알고 있다. 예컨대 variadic arguments나 non-local exits를 다루는 것과 같은 몇몇 라이브러리 도구들은 C 컴파일러의 상당히 많은 부분의 결합을 요구하게 되는데, 이 때 컴파일러는 그 언어에서 이미 만들어져 있는 도구들을 다루는 편이 수월할 것이다.
이 안내서에 적혀있는 명칭들뿐만 아니라, 예약된 명칭들은 하나 짜리 밑줄('_')로 시작되는 모든 외부 동일규정들(전역 변수와 함수)들을 포함한다. 또한 두개 짜리 밑줄로 시작되거나 하나 짜리 밑줄로 시작하되 대문자가 따라붙는 동일규정들은 전부 예약된 명칭이다. 이렇게 해야만 라이브러리나 헤더파일들이 함수, 변수, 매크로 등을 정의할 수 있게되고, 그것들이 사용자 프로그램의 다른 명칭들과 충돌됨이 없이 내부적 목적에 활용될 수 있다.
다른 어떤 종류의 동일규정 명칭들은 미래에서의 C언어의 확장을 기대하며 예약되어 있다. 이러한 명칭들은 당장은 당신의 프로그램에서 사용되어도 문제가 없지만, 장래에 C언어의 표준규정들이 버전업 되면 문제를 일으킬 소지가 있으므로 가급적 이 명칭들의 사용을 피하는 게 좋겠다.
영어대문자 'E'로 시작되어서 뒤에 구두점(.)이나 대문자가 따라붙는 명칭
'is'나 'to'로 시작해서 소문자가 따라붙는 명칭
'LC_'로 시작해서 뒤에 대문자가 따라붙는 명칭
'f'나 'l'이 붙어있는 수학함수(13장[수학] 참조)
'SIG'로 시작해서 뒤에 대문자가 따라붙는 명칭
'SIG_'로 시작해서 뒤에 대문자가 따라붙는 명칭
'str','mem'이나 'wcs'로 시작해서 소문자가 따라붙는 명칭
'_t'로 끝나는 명칭
아울러, 어떤 헤더파일들은 실제로 정의되어 있는 명칭들의 범위를 넘어서는 명칭들도 예약하고 있기도 한다. 따라서, 당신이 특정한 헤더파일을 프로그램에 포함시킨다면 이러한 제한에 대해 너무 근심하지 않아도 된다.
당신이 소스파일을 컴파일할 때 당신이 선언한 테스트매크로의 특징대로 제어되어져 당신은 정확한 프로그램의 형상을 얻을 수 있다.
만약 소스프로그램을 컴파일할 때 'gcc -ansi'를 사용하면 오직 ANSI 라이브러리만으로 된 프로그램을 얻을 수 있고, 그렇지 않더라고 하나, 혹은 더 많은 매크로를 사용해서 부가적인 프로그램의 특징을 명시적으로 요청할 수 있다. 이 책 안에 있는 " GNU CC Command Options "란 부분을 보면 GCC 옵션에 대한 더 많은 정보를 얻을 수 있다.
여러분의 소스코드 파일에 '#define'이라는 전처리 지시어를 사용해서 이 매크로를 정의할 수 있다. 이 전처리 지시어는 오직 주석 문을 제외하고 #include나, 어떤 것보다 먼저 와야만 한다. 또한 GCC에 옵션'-D'를 사용할 수 있지만 그것은 당신이 독립적인 방법으로( a selfcontained way ) 그들 자신의 의미를 지시하는 소스 파일들을 만들고자 할 때는 좋다.
__POSIX__SOURCE
__POSIX__C__SOURCE
__BSD__SOURCE
__SVID__SOURCE
__GNU__SOURCE
이곳은 이 안내서에 있는 각장의 내용을 개략 한다.
제 2장 : [에러보고] 라이브러리에 의해 어떻게 에러가 발견되는지에 대한 설명.
제12장 : [Low-Level Terminal Interface]
제25.12 : [User Database] 그리고 25.13[Group Database]