From: Christopher Croughton <crough45 AT amc DOT de>
Message-Id: <97Mar18.102239gmt+0100.16645@internet01.amc.de>
Subject: ANSI function 'tmpfile' is not binary
To: djgpp AT delorie DOT com
Date: Tue, 18 Mar 1997 10:23:16 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Function 'tmpfile' in the DJGPP library distribution seems to open
the file in a way contrary to that stated in the ANSI C specification.
In X3.159.1989 it states:

  The tmpfile function creates a temporary binary file that will 
  automatically be removed when it is closed or at program termination.
  ... The file is opened for update with "wb+" mode.

(Para. 7.9.4.3, ellipsis mine.)

Is there a later version of the ANSI/ISO specification which changes
this behaviour?

The source in djlsr201.zip, however, has:

  f = fopen(temp_name, (_fmode & O_TEXT) ? "wt+" : "wb+");

Which (since _fmode defaults to text) opens it by default in text mode.
While this doesn't make any difference on Unix, on MSDOS it has a drastic
effect - all CRs (0x0D) are deleted and the file is terminated by a ^Z 
(0x1A).

This will (and does) break ANSI-conforming programs which use a temporary 
file in unpredictable ways - such files are commonly used to store binary 
data such as pointers and file offsets, which are very likely to contain 
bytes with those values.

I don't have the GCC distribution sources to hand, but it seems possible 
that this has been inherited from the standard GCC library and has just 
never shown up on Unix...

It's easy to test what difference it makes - just open the tmpfile,
write all the characters from 0 to 255 using putc/fputc, rewind and
read them back...

Chris