우리 모두 알다시피 테스트는 프로그램의 정확성을 검증하지 못한다. I/O가 연관되어 있을 때는 더욱 그렇다. 스트림 입력은 들어오는 문자를 읽고 적절한 변수 타입의 값으로 전달한다(예를 들어 i1을 설정할 때 int 타입으로 전달한다). 이때 값의 일부가 될 수 없는 첫 번째 문자(int 값 i1의 경우 ".")에서 멈춘다. 이후에 또 다른 int를 읽으면 빈 문자열을 int 값으로 해석할 수 없으므로 실패한다. 그러나 위 코드는 그렇지 않다. 대신 점이 할당된 옆의 문자를 읽는다. i2에 대한 입력을 파싱할 때 먼저 int 값에 속하지 않는 문자를 얻기 전에 o1의 분수 부분을 찾은 다음 o2의 정수 부분을 찾는다.

불행하게도 실제로 문법 규칙 위반이 예외는 아니다. .3을 int로 파싱하면 0이 된다(다음 입력은 실패할 것이다). -5를 unsigned로 파싱하면 4294967291이 된다(unsigned가 32비트 long일 때). 축소(Narrowing) 원칙은 분명히 (이전 버전과의 호환성을 위해서라면) I/O 스트림으로의 길을 찾지 못했을 것이다.

어쨌든 애플리케이션의 I/O 부분은 상당히 주의해야 한다. 숫자는 공백으로 올바르게 구분하고 작성한 타입과 동일한 타입으로 읽어야 한다. 파일 형식이 다를 수 있는 분기가 출력에 포함되어 있으면 입력 코드가 상당히 복잡해지고 모호할 수도 있다.

우리가 언급하고자 하는 두 가지 형태의 I/O가 있다. 바로 바이너리 I/O와 C 스타일 I/O다. 관심 있는 독자는 A.2.7절과 A.2.8절에 각각 나와 있다. 필요할 때 나중에 읽어도 된다.