C ++ 표준이 파일을 처리하는 방식을 찾는 이유는 무엇입니까?

C ++는 streamoff형식을 사용하여 (파일) 스트림 내의 오프셋을 나타내며 [stream.types]에 다음과 같이 정의됩니다.

using streamoff = implementation-defined ;

type streamoff는 운영 체제에 가능한 최대 파일 크기를 나타내기에 충분한 크기의 서명 된 기본 정수 유형 중 하나와 동의어입니다. 287)

287) 일반적으로 길다.

이것은 long32 비트 너비 의을 사용하는 것과는 반대로 큰 파일 내에서 탐색 할 수 있기 때문에 의미 가 있습니다.

[filebuf.virtuals]는 basic_filebuf파일 내에서 찾는 기능을 다음과 같이 정의 합니다.

pos_type seekoff(off_type off, ios_base::seekdir way, ios_base::openmode which = ios_base::in | ios_base::out) override;

off_type는 streamoff[iostreams.limits.pos]를 참조하십시오. 그러나 표준은 함수의 효과를 설명하기 위해 계속됩니다. 나는 마지막 문장에 짜증이 나서 다음을 호출해야합니다 fseek.

효과 : width표시 하자 a_codecvt.encoding(). 경우 is_open() == false, 또는 off != 0 && width <= 0, 그 위치 결정 작업이 실패. 그렇지 않은 경우 way != basic_ios::cur또는 또는 off != 0마지막 작업이 출력 된 경우 출력 시퀀스를 업데이트하고 언 시프트 시퀀스를 작성하십시오. 다음으로 새로운 위치를 찾으십시오 : if width > 0, call fseek(file, width * off, whence), 그렇지 않으면 call fseek(file, 0, whence).

fseeklong매개 변수를 승인합니다 . 경우 off_type와 streamoff같이 정의된다 long long(표준에 의해 제안),이에 다운 변환으로 이어질 수 long호출 할 때 fseek(file, width * off, whence)(버그를 진단 할 가능성이 하드로 이어지는). 이것은 처음에 streamoff유형 을 소개하는 전체 이론적 근거에 의문을 제기합니다 .

이것이 표준에 의도적이거나 결함입니까?

이것에서 C ++ 스트림간에 불일치가 있고 fseek런타임 버그로 이어질 것이라는 결론은 부정확 하다고 생각합니다 . 상황은 다음과 같습니다.

1. 여기서 시스템은 long64 비트 인 streamoff것으로 정의되는 long, 상기 seekoff기능은 원용 fseek.

2. 시스템 여기서 long32 비트이지만 OS 지원 64 비트 파일 오프셋이다 streamoff으로 정의 long long하고 seekoff하나라는 함수를 호출 fseeko하거나 fseeko64하는 64 비트 오프셋을 받아 들인다.

다음은 seekoffLinux 시스템 정의의 스 니펫입니다 .

#ifdef _GLIBCXX_USE_LFS
    if (!fseeko64(_M_file, __off, __whence))
      __ret = std::streampos(ftello64(_M_file));
#else
    if (!fseek(_M_file, __off, __whence))
      __ret = std::streampos(std::ftell(_M_file));
#endif

LFS는 대용량 파일 지원을 나타냅니다 .

결론 : 표준은 호출 streamoff요구 사항과 명백히 상충 되는 정의가 제안되지만 라이브러리 설계자 는 OS가 지원하는 모든 범위의 오프셋을 허용하는 변형을 호출해야한다는 것을 이해 합니다.seekofffseekfseek