1 안내문

C언어는 입출력, 메모리 관리, 문자열 처리와 같은 일상적 처리를 수행하는 장치들을 이미 완성된 도구로 제공하지는 않는다. 대신에, 이 도구들은 표준 라이브러리에 정의되어 있기 때문에, (이것들을 사용하여) 당신의 프로그램을 컴파일하고 링크할 수 있는 것이다.

이 문서에 기술되어 있는 GNU C의 라이브러리들은 ANSI C 뿐만 아니라 POSIX 또는 다른 유닉스 운영체제 및 GNU 시스템이 지정하는 여타 언어들에서도 적용되는 모든 라이브러리 함수들을 정의한다.

이 안내서의 목적은 GNU 라이브러리의 도구들을 사용하는 방법을 알려주는 데에 있다. 우리는 특히 다른 시스템에서는 아마도 사용할 수 없는 함수들이 가지는 특성들을 언급하였다. 다만, 이 안내서의 규정들이 엄격하게는 적용되지 않을 것이다.

1.1 시작하기

이 안내서는 적어도 당신이 C 프로그래밍 언어나 기본적인 프로그래밍의 개념에 어느 정도 익숙하다는 것을 가정하고 씌어졌다. 특히 "전통적인" ANSI 이전의 C언어 통용어보다는 ANSI 표준 C언어에 친숙하다고 생각하였다.

GNU C 라이브러리는 몇몇 헤더파일을 갖고 있는데, 각 헤더파일은 관련함수들을 정의하고 선언한다; 이 정보는 당신의 프로그램이 처리될 때 C 컴파일러가 사용하게 된다. 예컨대, 헤더파일 'stdio.h'는 입출력을 수행하는 함수들을 선언하고, 헤더파일 "string.h'는 문자열 처리 도구들을 선언한다. 이 안내서의 편성은 헤더파일을 분류한 것과 똑같이 나누어져 있다.

이 안내서를 처음으로 읽을 때에는 모든 안내문과 설명들을 몽땅 읽는 게 좋다. GNU C의 라이브러리에는 많은 함수들이 있지만, 당신이 그 모든 것을 모두 정확하게 다 기억할 수는 없을 것이다. 그러므로, 라이브러리가 제공하는 각종 도구들에 널리 친숙해지고 난 다음에, 실제로 프로그램을 잘 때에 라이브러리 함수를 쓰는 법과 그 함수들에 대한 안내서의 특정 정보들을 빨리 찾아내는 것이 중요하다.

1.2 표준규정과 호환성

여기서는 GNU C라이브러리가 기초하고 있는 다양한 규정들과 소스에 관해서 논의하자. 이 소스들은 ANSI C와 POSIX 표준규정 및 V 시스템, 그리고 버클리 유닉스 장치들을 포함한다.

이 안내서의 첫 번째 주제는 당신이 어떻게 GNU 라이브러리의 도구를 효과적으로 사용할 것인가에 관한 것이다. 그러나 만약 당신이 이미 작성한 프로그램을 이들 표준과 일치시키고 싶어하거나 GNU보다는 운영체제의 활용 문제에 관심을 갖는다면, 이 안내서는 라이브러리 사용법을 아는 데 도움이 될 것이다.

부록 B [Library Summary]를 보면, 라이브러리가 제공하는 함수나 부호들의 알파벳순서 리스트가 있다. 여기에서 각 함수와 부호들이 어떤 표준도구에서 파생된 것인지를 알 수 있다.

 

1.2.1 ANSI 씨

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언어들과 함께 사용하는 충고들은 하겠지만 모든 것을 완전히 다 설명할 수는 없겠지?

 

1.2.2 POSIX ( 이식 가능한 운영체제와의 호환성 ; The Portable Operating System Interface )

GNU 라이브러리는 일반적인 컴퓨터 환경을 위한 운영체제 호환성으로 알려져 있는 IEEE POSIX와도 서로 통용된다. POSIX는 대체로 유닉스 운영체제의 수많은 버전들에서 유래된 말이다. POSIX 표준에 의해 규정된 라이브러리 도구들은 ANSI C에 의해 규정된 것들보다는 더 확장되어 있다; POSIX는 새로운 함수들을 포함할 뿐만 아니라 ANSI C의 함수들에 새로운 특성을 추가해 놓고 있다. 일반적으로, POSIX의 함수들은 다양한 운영체제에서 사용되는 고급 프로그램 언어들을 지원한다기보다는 특정한 운영체제의 환경을 지원하기 위하여 저급언어들을 제공하는데 초점을 둔다. GNU C라이브러리는 흔히 "POSIX.1"이라 불리는 POSIX 체제 적용 호환 프로그램, 즉, IEEE Std 1003.1-1990에 규정된 모든 함수들을 완성하였다. 여기에서 ANSI C의 도구들을 최초로 확장한 내용은

첫째, 파일 체제 호환(9장 참조)
둘째, 특정 장치 터미널 통제 함수(12장)
셋째, 프로세스 통제 함수(23장)등이다.

GNU 라이브러리는 IEEE Std 1003.2-1992의 몇몇 도구들과 POSIX shell, 그리고 표준 유틸리티들도 완성해 놓았다. 이들은 정규적인 표현들을 다루는 유틸리티뿐만 아니라 다른 형태로 적용되는 도구들까지 포함하고 있다. (16장)

 

1.2.3 버클리 유닉스

GNU C라이브러리는 몇몇 유닉스 버전의 도구들을 정의하고 있다. 특히 유닉스 체제의 BSD의 버전4.2, 4.3, 4.4 (버클리 유닉스라 알려져 있는), 그리고 SunOS (유닉스 체제 V함수모음을 포함하는 4.2 BSD의 파생본)이 그것이다. 이러한 체제들은 ANSI와 POSIX의 대부분의 함수들을 지원하고 있으며, BSD 버전 4.4와 새로운 SunOS 배포본은 사실상 이 모든 것을 제공한다고 보아 무방할 것이다.

BSD 도구들이 포함하는 것.
(1) 부호 링크 ( 9.4절 )
(2) 선별 함수 ( 8.6절 )
(3) BSD 기호 함수 ( 21.9절 )
(4) 소켓 ( 11장 참조 )

1.2.4 SVID ( V체제 호환성 설명 )

SVID는 AT&T 유닉스체제와 V 운영체제를 설명하는 문서다. 그것은 POSIX 표준을 어느 정도 확장한 것이다.(1.2.2 참조)

GNU C 라이브러리는 이러한 도구들을 담고 있는 V 유닉스 체제 및 또다른 유닉스 체제들( SunOS와 같은)을 무리 없이 사용하기 위해서, ANSI 또는 POSIX 표준규정들에 의해 요구되는 함수들을 정의하고 있다. 그러나, SVID가 필요로는 하지만 불명확하고 사용빈도가 낮은 함수들은 많이 제외시켰다. (사실, V 유닉스 체제 그 자체는 그것들을 모두 제공하지는 않는다.)

1.3 라이브러리 사용하기

여기서는 GNU C의 라이브러리를 사용하는 데서 일어나는 실제적인 문제들을 설명하고자 한다.

1.3.1 헤더 파일

C 프로그램에서 사용하는 라이브러리는 이 두 가지로 구성된다;

첫째, 형태와 매크로를 정의하고 변수와 함수들을 선언해 놓은 헤더파일.
둘째, 변수의 정의나 함수를 담고 있는 실제의 라이브러리나 보관소.

( C언어에서는, 선언은 오로지 함수나 변수가 존재한다는 정보를 제공하거나, 그 형태를 규정할 뿐임을 기억하라. 함수를 선언하려면, 함수의 형태에 관한 정보도 주어져야 한다. 선언을 하는 목적은 컴파일러가 선언된 변수나 함수를 정확하게 처리하도록 하는 데에 있다. 한편, 정의는 변수에 메모리를 할당하거나 함수가 무슨 일을 해야 하는지를 실제적으로 말해주는 것이다. )

GNU C의 라이브러리를 사용하기 위해서는, 당신은 당신의 프로그램 소스파일이 적합한 헤더파일을 포함시키고 있는지를 분명하게 알아야 한다. 왜냐하면, 컴파일러는 이러한 유용한 도구들의 선언을 갖고 있고 그것들을 정확하게 참조하여 처리를 수행하기 때문이다. 당신의 프로그램이 일단 컴파일되면, 링커는 저장된 파일에서 제공되는 실제적인 정의를 참조하면서 일을 수행한다. 헤더파일은 '#include'라는 전처리기 지시어에 의해 프로그램 소스파일로 포함되어진다. c언어는 이 지시어를 두개의 형태로 제공한다.

#include "header"

는 당신 스스로가 작성한 헤더파일을 포함시킬 때 사용하는 유형이다; 이것은 당신의 프로그램중의 다른 부분에서 불러다 쓸 정의나 선언을 담고 있다.

이와는 달리, #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언어들에서는 전통적으로 허용되지 않는 경우였다. 엄밀히 말하자면 헤더파일이 선언한 함수를 사용하는 경우에도 헤더파일을 포함하지 않을 수도 있다; 이 안내서가 설명하는 데에 따라 당신 스스로가 그 함수를 명시적으로 선언해도 좋다. 그렇지만, 항상 헤더파일을 사용하는 편이 유리할 것이다. 왜냐하면, 헤더파일은 특정한 방법으로 사용할 수밖에 없는 형태와 매크로를 정의하고 있으며, 또한 어떤 함수들을 대신할 수 있는 보다 유효한 매크로들을 정의하고 있기 때문이다.

 

1.3.2 함수의 매크로 정의

이 안내서에서 어떤 것을 함수로 기술하고자 할 때, 그것은 매크로 정의로 될 수가 있다. 이 점은 프로그램의 실행에는 아무런 지장이 없다.__ 매크로 정의는 함수와 똑같은 역할을 한다. 특히 라이브러리 함수에 상응하는 매크로는 함수를 호출할 때와 같은 방식으로 규정들을 꼭 한번씩만 검토한다. 매크로를 정의하는 주된 이유는 종종 매크로가 함수를 호출하는 것보다 훨씬 더 빠른 처리를 하기 때문이다. 라이브러리 함수가 매크로로 정의된다고 하드라도 그 함수의 주소는 구해진다. 이는 구문 상으로 볼 때, 그 함수의 이름이 매크로를 호출하는 데 필요한 왼쪽 구문보다 뒤에 위치하기 때문이다.

당신은 때로는 --아마도 프로그램의 디버깅을 쉽게 하기 위하여--함수의 매크로 정의를 사용하지 않으려 할 것이다. 이렇게 하는데는 두 가지의 방법이 있다;

당신은 함수의 이름을 괄호로 묶어서 사용하는 방법으로 매크로 정의를 피할 수 있다. 이렇게 하면, 함수의 이름이 매크로를 호출하는 문장 상에 나타나지 않을 수 있다.

당신은 '#undef'라는 전처리기 지시어를 사용함으로써 전체 소스 상에 있는 어떠한 매크로 정의든지 취소할 수 있다. 만일 부가적으로 그 기능이 명시적으로 서술되지만 않는다면. 예를 들어, 헤더파일 'stdlib.h'가 외부정수 (int)를 갖는 abs라는 명칭의 함수를 선언한다고 가정하자; 또한 abs를 매크로 정의로 한다고 가정하자. 그러면,

#include <stdlib.h>
int f (int *i) { return (abs (++*i)); }

이 경우에는 매크로로도 함수로도 참조될 수 있게 된다. 다른 한편, 다음의 각 경우에는 매크로로는 참조되지 않으며 다만 함수로서 참조될 뿐이다.

#include <stdlib.h>
int g (int *i) { return ((abs)(++*i)); }
#undef abs
int h (int *i) { return (abs (++*i)); }

매크로가 함수와 중복되어 정의되더라도 그것은 실제적인 함수 호출과 똑같은 방식으로 작동하기 때문에, 언제나 이러한 방법을 채택할 필요는 조금도 없다. 사실상, 매크로 정의를 제거하게되면 프로그램의 실행이 더욱 느려질 것이다.

 

1.3.3 예약된 명칭들

ANSI C의 표준에서 유래된 모든 라이브러리 형태, 매크로, 변수 및 함수의 명칭들은 모두 무조건적으로 예약되어 있다; 당신의 프로그램이 이 명칭들을 다시 정의할 필요가 없다. 만약 당신이 그것들을 선언한 헤더파일을 당신의 프로그램에 분명하게 포함시키기만 한다면, 다른 모든 라이브러리 명칭들도 예약되는 것이다. 이렇게 하는데는 몇 가지 이유가 있다.

예컨대, 당신이 만일 표준규정과는 완전히 다른 이름을 붙여서 멋대로 함수를 사용하게 되면, 다른 사람들이 당신의 소스코드를 읽다가 큰 혼란에 빠질 것이다. 이런 사태를 막기 위해서 당신은 프로그램을 이해하기 쉽도록 짜야되며 모듈화하고 알 수 있게 하여야 한다.

또한 사용자가 우연하게도 다른 라이브러리 함수에서 호출된 함수를 다시 정의하게 될 가능성도 막아야 한다. 만약 중복되는 정의가 허용된다면, 다른 함수들은 제대로 작동할 수 없을 것이다.

컴파일러는 사용자가 함수를 다시 정의하지 않더라도 그것들이 호출될 때 어떻게 처리해야 하는지를 알고 있다. 예컨대 variadic arguments나 non-local exits를 다루는 것과 같은 몇몇 라이브러리 도구들은 C 컴파일러의 상당히 많은 부분의 결합을 요구하게 되는데, 이 때 컴파일러는 그 언어에서 이미 만들어져 있는 도구들을 다루는 편이 수월할 것이다.

이 안내서에 적혀있는 명칭들뿐만 아니라, 예약된 명칭들은 하나 짜리 밑줄('_')로 시작되는 모든 외부 동일규정들(전역 변수와 함수)들을 포함한다. 또한 두개 짜리 밑줄로 시작되거나 하나 짜리 밑줄로 시작하되 대문자가 따라붙는 동일규정들은 전부 예약된 명칭이다. 이렇게 해야만 라이브러리나 헤더파일들이 함수, 변수, 매크로 등을 정의할 수 있게되고, 그것들이 사용자 프로그램의 다른 명칭들과 충돌됨이 없이 내부적 목적에 활용될 수 있다.

다른 어떤 종류의 동일규정 명칭들은 미래에서의 C언어의 확장을 기대하며 예약되어 있다. 이러한 명칭들은 당장은 당신의 프로그램에서 사용되어도 문제가 없지만, 장래에 C언어의 표준규정들이 버전업 되면 문제를 일으킬 소지가 있으므로 가급적 이 명칭들의 사용을 피하는 게 좋겠다.

영어대문자 'E'로 시작되어서 뒤에 구두점(.)이나 대문자가 따라붙는 명칭

후일에 에러코드의 명칭으로 사용될 것이 예상된다. 2장 [에러보고] 참조

'is'나 'to'로 시작해서 소문자가 따라붙는 명칭

문자처리나 변환 함수로 사용될 것들이다. 4장 [문자의 처리] 참조

'LC_'로 시작해서 뒤에 대문자가 따라붙는 명칭

지역적인 범위의 매크로 명칭으로 사용될 것들이다.

'f'나 'l'이 붙어있는 수학함수(13장[수학] 참조)

각각 실수나 double형 인수를 작동시키는 함수들의 명칭으로 사용될 것들이다.

'SIG'로 시작해서 뒤에 대문자가 따라붙는 명칭

부호 명칭으로 사용될 것들이다. 21.2 [표준 부호] 참조

'SIG_'로 시작해서 뒤에 대문자가 따라붙는 명칭

부호의 작동에 사용될 명칭들이다. 21.3.1 [기본적인 부호 처리] 참조

'str','mem'이나 'wcs'로 시작해서 소문자가 따라붙는 명칭

문자열이나 배열의 함수로 사용될 명칭들이다. 5장 [문자열과 배열의 처리] 참조

'_t'로 끝나는 명칭

형태를 규정하는 명칭(? 형명칭)으로 사용될 것이다.

아울러, 어떤 헤더파일들은 실제로 정의되어 있는 명칭들의 범위를 넘어서는 명칭들도 예약하고 있기도 한다. 따라서, 당신이 특정한 헤더파일을 프로그램에 포함시킨다면 이러한 제한에 대해 너무 근심하지 않아도 된다.

헤더파일 'dirent.h'는 'd_'로 시작하는 명칭들을 예약하고 있다.
헤더파일 'fcnti.h'는 'l_','F_','O_'및 'S_'로 시작하는 명칭들을 예약하고 있다.
헤더파일 'grp.h'는 'gr_'로 시작하는 명칭들을 예약하고 있다.
헤더파일 'limits.h'는 '_MAX'가 따라붙는 명칭을,
헤더파일 'pwd.h'는 'pw_'로 시작하는 명칭을,
헤더파일 'signal.h'는 'sa_'와 'SA_'로 시작하는 명칭을,
헤더파일 'sys/stat.h'는 'st_'와 'S_'로 시작하는 명칭을,
헤더파일 'sys/times.h'는 'tms_'로 시작하는 명칭을,
헤더파일 'termios.h'는 'c_','V','I','O'및 'TC'로 시작하는 명칭들을 예약하고 있다. 또한 'B'로 시작하되 구두점(.)이 뒤따르는 명칭들도 예약하고 있다.

 

1.3.4 Feature Test Macros

당신이 소스파일을 컴파일할 때 당신이 선언한 테스트매크로의 특징대로 제어되어져 당신은 정확한 프로그램의 형상을 얻을 수 있다.

만약 소스프로그램을 컴파일할 때 'gcc -ansi'를 사용하면 오직 ANSI 라이브러리만으로 된 프로그램을 얻을 수 있고, 그렇지 않더라고 하나, 혹은 더 많은 매크로를 사용해서 부가적인 프로그램의 특징을 명시적으로 요청할 수 있다. 이 책 안에 있는 " GNU CC Command Options "란 부분을 보면 GCC 옵션에 대한 더 많은 정보를 얻을 수 있다.

여러분의 소스코드 파일에 '#define'이라는 전처리 지시어를 사용해서 이 매크로를 정의할 수 있다. 이 전처리 지시어는 오직 주석 문을 제외하고 #include나, 어떤 것보다 먼저 와야만 한다. 또한 GCC에 옵션'-D'를 사용할 수 있지만 그것은 당신이 독립적인 방법으로( a selfcontained way ) 그들 자신의 의미를 지시하는 소스 파일들을 만들고자 할 때는 좋다.

__POSIX__SOURCE

만일 당신이 이 매크로를 사용하면 모든 ANSI C는 물론 표준(IEEE Standard 1003.1)POSIX.1의 함수들이 이용되어진다.

__POSIX__C__SOURCE

만일 당신이 이 매크로를 1의 값과 함께 선언하면 표준(IEEE Standaed 003.1)POSIX.1의 함수들을 이용하여 만든다. 매크로를 2의 값과 함께 선언하면 표준 POSIX.1과 표준POSIX.2의 함수들이 이용되어진다. 또, 여기에는 ANSI C가 더해져 있다.

__BSD__SOURCE

만일 당신이 이 매크로를 정의하면 ANSI C, POSIX.1, POSIX.2 가 포함된 4.3 BSD UniX에서 함수를 끌어낸다. 4.3 BSD Unix 에서 온 어떤 것은 POSIX.1 표준에서 지정한 어떤 것 (일치되는 특징을 가진 것)과 충돌을 일으키는데 만일 이 매크로가 정의되면 4.3 BSD 정의가 POSIX의 정의에 앞서 인계된다.
4.3 BSD와 POSIX.1사이의 어떤 충돌이 원인이 되어 당신이 BSD와 호환되도록 컴파일된 프로그램을 링크할때 특별한 BSD 호환 라이브러리의 사용이 필요하다. 이것은 왜냐하면 어떤 함수들은 두 가지 상이한 방법으로 정의되어져 있기 때문이다. 그 두가지중 한가지는 일반적 C 라이브러리이고 또다른 하나는 호환 라이브러리이다. 당신의 프로그램을 _BSD_SOURCE로 정의하면 당신은 컴파일러나 링커에게 -lbsd-compat라고 옵션을 주어야만 하는데, 그것은 함수를 일반 c 라이브러리에서 찾기 전에 호환 라이브러리에서 찾도록 컴파일러나 링커에게 알려주기 위함이다.

__SVID__SOURCE

당신이 이 매크로를 정의하면 ANSI C, POSIX.1, POSIX.2의 요소가 포함된 SVID로부터 함수를 만일끌어온다.

__GNU__SOURCE

이 매크로는 ANSI C, POSIX.1, POSIX.2, BSD, SVID 그리고 GNU 확장부분까지 모든걸 포함한다. 이 경우 POSIX1 과 BSD의 충돌 때는 POSIX가 우선한다. 그런데 _GNU_SOURCE의 모든 효과는 얻고 싶은데 BSD가 POSIX에 우선하고 싶을 때는 아래와 같은 정의 구문을 사용하라.
#define _GNU_SOURCE
#define _BSD_SOURCE
#define _SVID_SOURCE
당신의 프로그램을 BSD 호환 라이브러리와 링크하려면 컴파일러나 링커에게 -lbsd-compat옵션을 주어야한다. 만약 이것을 잊어버리면 실행할 때에 매우 이상한 에러를 얻게될 것이다. 당신이 새로운 프로그램을 _GNU_SOURCE로 사용하려면 GCC에 -ansi옵션과 어느 특정한 매크로를 명시하지 않으면 _GNU_SOURCE와 같은 효과를 얻게 되는데, 우리는 당신에게 그 방법을 추천한다.
확장된 클래스를 요청하기 위해 테스트 매크로를 정의할 때, 부가적인 테스트 매크로를 사용하는 것은 무해한데, 그것은 부가적으로 사용된 매크로가 이미 선언된 매크로의 부분집합일 때이다. 예를 들어 만약 당신이 _POSIX_C_SOURCE라고 선언하고 다시 _POSIX_SOURCE라고 선언하면 아무런 효과가 발생되지 않는다. 이처럼 _GNU_SOURCE라고 선언하고 더하여서 _POSIX_SOURCE나 _POSIX_C_SOURCE, 혹은 _SVID_SOURCE라고 선언하는 것도 아무런 효과가 발생하지 않는다. 그렇지만 _BSD_SOURCE는 지원되는 다른 테스트 매크로의 부분집합이 아닌데, 그것은 POSIX에 우선되도록 정의되어져 있기 때문이다. 이 때문에 _BSD_SOURCE에 더해서 다른 테스트 매크로를 사용하는 것은 효과를 갖게되고 그것은 BSD가 충돌하는 POSIX보다 우선권을 갖는 것에 기인한다.

1.4 안내서의 지도

이곳은 이 안내서에 있는 각장의 내용을 개략 한다.

제 1장 : 안내

제 2장 : [에러보고] 라이브러리에 의해 어떻게 에러가 발견되는지에 대한 설명.

제 3장 : [메모리 점유]

동적 메모리 점유를 위해 GNU라이브러리가 갖추고 있는 것을 설명. 만일 당신의 프로그램에서 얼마나 많은 메모리가 필요한지 알지 못한다면 당신은 그것을 동적으로 메모리를 점유하도록 만들 수 있지만 대신에 포인터로 그것을 다루게 된다.

제 4장 : [문자 처리]

문자분류 함수들( isspace와 같은 )에 대한 정보와 각 변환을 형성하기 위한 함수들에 대한 정보.

제5장 : [문자열과 배열 유틸리티]

문자열( 끝에 널 문자를 가진 배열 )과 일반적 바이트 배열을 카피하고 비교하는 등의 실행을 포함한 여러 함수들에 대한 설명.

제6장 : [입출력 개괄]

입출력의 도구들을 포괄적으로 살펴보고 파일이름처럼 기본적인 개념에 대한 정보 포함.

제7장 : [스트림의 입출력]

스트림( 또는 파일 )의 입출력묘사. 그것은 일반 C 라이브러리 함수의 `stdio.h'에 있다.

제8장 : [저수준 입출력]

파일기술자의 입출력 오퍼레이션에 대한 정보 함유. 파일 기술자는 운영체제 유닉스 계에 특유한 저수준 메커니즘이다.

제9장 : [파일시스템 인터페이스]

전체적 파일에 대한 명령어, 즉, 지우고 재 명명하고 새로운 디렉토리를 만드는 것과 같은 명령에 대한 서술. 이 장은 또한 그 자신과 파일 보호모드와 같은 파일 속성을 어떻게 다루는지에 대한 정보도 포함하고 있다.

제10장 : [Pipes and FIFOs]

간단한 프로세스간 통신 메커니즘에 대한 정보. Pipes는 두 연관된 프로세스( 부모와 자식사이와 같은 ) 사이의 통신을 허용하고 그 동안 FIFOs는 프로세스 사이에 공통된 하나의 파일시스템을 나누는 역할을 한다.

제11장 : [Sockets]

네트웍 상에서 통신하기 위해 다른 시스템 (machines)위에 프로세스들의 실행을 허용하는 것과 같은 더 복잡한 프로세스간 통신에 대해 설명. 이장은 또한 인터넷 호스트 주소지정과 시스템 네트웍 데이터베이스를 어떻게 사용하는지 설명하고 있다.

제12장 : [Low-Level Terminal Interface]

터미널 디바이스의 속성을 어떻게 변화시킬 수 있는지에 대한 설명. 예를 들어 만일 당신이, 사용자가 입력하는 문자의 echo를 원하지 않는다면 이 장을 읽어라.

제13장 : [수학]

수학관련 함수들에 대한 정보. 여기에는 난수 발생기와 정수의 나머지 함수, 실수에서 삼각함수와 지수함수와 같은 것들을 포함하고 있다. 미정의: 저수준 수학 함수들, 문자열로부터 수를 읽고 실수 값을 분석하는, 간단한 함수들을 설명.

제15장 : [탐색과 정렬]

배열을 탐색하고 정렬하기 위한 정보를 포함. 적당한 비교 함수를 줌으로써 어떤 종류의 배열에도 이 함수를 사용할 수 있다.

제16장 : [형식일치]

일반적 표현과 쉘 파일 이름 형식을 매치시키기 위한 함수, 그리고 쉘처럼 단어들을 확장하기 위한 함수.

제17장 : [날짜와 시간]

알람과 타이머를 세팅하는 함수처럼 달력의 시간과 CPU의 시간을 계산하기 위한 함수 설명.

제18장 : [확장된 문자]

일반적 문자 데이터 타입보다 확장된 문자 셋을 사용하는 문자와 문자열을 다루는 것에 대한 정보.

제19장 : [Locals]

어떻게 나라를 선택하거나, 라이브러리의 작용에 영향을 미치는 언어를 어떻게 선택할 것인지에 대한 설명. 예를 들면 지역적인건 화폐의 값과 문자열의 대조열에 영향을 미친다.

제20장 : [Non-Local Exits]

setjump와 longjump함수의 해설. 이 함수들은 다른 곳에서 하나의 함수로 goto 처럼 분기하기 위한 편의를 제공한다.

제21장 : [신호처리]

신호에 대한 모든 것을 설명한 장으로, 인도된 특별한 종류의 신호가 있을 때 그것을 부를 수 있는 핸들러를 어떻게 만들 것인가, 그리고 당신의 프로그램이 중요한 부분에 있을 동안 도착되는 신호를 어떻게 방지할 것인지에 대한 것들이 있다.

제22장 : [Process Startup]

당신의 프로그램을 커맨드라인 변수와 환경변수들로 어떻게 실행할 것인지 말한다.

제23장 : [Child Processes]

어떻게 새로운 프로세스들은 시작하고 프로그램을 실행할 것인지에 대한 정보를 준다.

제24장 : [Job Control]

프로세스 군을 다루기 위한 함수들을 설명. 이장은 쉘을 쓰려는(writing)데 관심이 있는 사람에게 유용하다.

제25.12 : [User Database] 그리고 25.13[Group Database]

어떻게 시스템 사용자와 그룹 데이터베이스를 억세스 할 것인지 설명.

제26장 : [System Information]

당신의 프로그램이 실행되고 있을 때 하드웨어와 소프트웨어에 대한 정보를 얻기 위한 함수들을 설명.

제27장 : [System Configuration]

다양한 운영체제의 제한조건에 대한 정보를 얻을 수 있는 방법에 대한 설명. 이 한계들의 대부분은 POSIX와 호환성을 위해 제공된다.

부록A : [Language Features]

C언어의 표준적인 부분을 위해 지원되는 라이브러리에 대한 정보와, sizeof 명령어와 NULL상수와 같은 것을 포함하고, 변수와 변수들을 어떻게 쓸것인지, 그리고 데이터 타입의 다른 특성과 범위를 설명. 당신이 코딩하는 곳에서 허용되는 간단한 디버깅 메커니즘도 있고, 테스트가 실패하면 나타나는 메시지들에 대한 진단도 있다.

부록B : [Liabrary Summary]

라이브러리 내에 있는 모든 함수와 변수, 그리고 매크로들에 대한 요약으로 간단한 데이터 타입들과 함수의 특성과 그리고 그것이 표준인지 아니면 어떤 시스템에서 사용되는 것인지를 설명했다.

부록C : [Maintenance]

당신의 시스템에 GNU C 라이브러리를 인스톨하는 법, 그리고 어떻게 발견된 버그에 대응하고 새로운 시스템에 라이브러리의 새로운 함수들과 포트를 더할 지에 대해 설명.
만일 당신이 이미 당신이 관심 있는 곳의 facility(함수, 변수 매크로)들의 이름을 이미 알고 있다면 부록B를 사전처럼 찾아볼 수 있다. 그리고 이곳은 당신이 좀더 세밀한 표현을 발견할 수 있는 곳이 되도록 구문과 포인터에 대한 요약을 했다. 이 부록은 예를 들어 당신이 함수들에게 주는 명령과 타입의 검증을 원한다면 특별히 유용한 것이 될 것이다. 그리고 함수, 변수 매크로들이 표준인지 아니면 각 시스템라이브러리에서 인계되는 것인지도 말하고 있다.
이 게시물을...