꿈을 코딩하는 프로그래머.

*인터넷 뒤지며 얻은 정보를 개인 적으로 종합, 정리 하였음.

- 라인 피드 (LF : Line Feed, 0x0a) : 캐럿을 다음 줄(현재 위치에서 바로 아래)로 이동 시킨다.

- 캐리지 리턴 (CR : Carriage Return ) : 캐럿을 줄의 맨 앞으로 이동 시킨다.

즉 모두 '줄 바꿈'과 관련이 있는 문자다.

줄 바꿈에 대한 정의는 시스템(OS), 언어 마다 다르다.

- 유닉스/리눅스 : LF만으로 줄 바꿈을 정의 한다.

- 윈도우/DOS : CRLF 조합으로 줄 바꿈을 정의 한다.

- C언어 : 유닉스 태생으로 LF만으로 줄 바꿈을 정의 한다.

위와 같이 유닉스/리눅스 시스템과 윈도우/DOS 시스템의 줄 바꿈에 대한 정의에 차이가 있다.

프린터나 타자기?와 같은 장비에선 LF로 캐럿의 위치를 현재 위치에서 바로 아래로 이동 하며 CR을 통해 줄의 맨 앞으로

이동 시키는 CR/LF (LF/CR과 다르다)의 조합을 통해서 줄 바꿈이 이루어 지는데

윈도우와 DOS는 이를 그대로 따라 가고 있다.(시스템 입장에서 보면 불편 한듯?)

따라서 윈도우의 파일을 그대로 리눅스로 옮기면 문자열 맨 끝에 '\r\n'이 붙게 되며

이를 리눅스 프로그램에서 그대로 사용시 문제가 발생할 소지가 있다.

윈도우와  DOS의 경우 C의 줄바꿈에 대한 정의와 차이가 있다.

즉 윈도우와 DOS에서 작성된 C프로그램이 줄바꿈을 '\n'으로 입력하면 하거나 읽어들이면

실제 파일에 '\r\n'으로 기록 되거나 읽히게 된다.

이러한 차이를 없애기 위해 fopen 함수 호출시 두번째 인자로 'b'(바이너리 모드)를 주지 않게 되면 C 라이브러리에서

'\n'을 '\r\n'으로 인식 하게 된다. 그러나 이 경우 두개의 '\r\n' 문자를 하나의 '\n' 문자로 인식 하기 때문에

파일 크기를 다루는 상황 등에서 문제가 발생할 수 있다.

이전 리눅스 파일 시스템에서 File의 최대 크기는 2147483647byte 즉 2GB(1.99)였다.

이는 2^31 -1의 값이다. 즉

int32형에서 표현 가능한 최대 양수이다.

OS상에서 File의 주소, Offset 관련 Data가 int32형으로 표현 되어 있었기에 제한이 있었던 것 같다.

마찬가지로 fopen, fwrite등의 함수로 2GB넘는 파일에 접근이 불가능 하다. 내부적응로 int32가 박혀 있을 것 같다.

그래서 라이브러리에서는 2GB 이상의 파일을 다룰 수 있도록 fopen64, fwrite64등의 함수를 제공 하고 있다.

그렇다면 기존의 파일은 어떻게 하나? 일일히 바꾸기 힘들기에 다음 옵션을 사용 할 수 있다.

컴파일 옵션에 -D_FILE_OFFSET_BITS=64 을 입력 하면 file 관련 함수, 변수들이 자동으로 32->64 bit용으로 변경이 

된다고 한다.

** 16.02.07 추가

fseek 함수와 ftell 함수는 위의 컴파일 옵션으로 해결이 안된다.

이 함수들은 자체적으로 fseeko 와 ftello 함수로 변경 해주어야 한다.

BSD(Berkeley Software Distribution)는 1977년 미국 캘리포니아 대학교 버클리(University of California, Berkeley)에서 개발한 유닉스 계열의 컴퓨터 운영 체제이다.

출처 : 위키 백과