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.  As an example:

#include <stdio.h>

int main()
{
        FILE *fp = tmpfile();
        int i, n;
        if (!fp)
        {
                perror("temporary file");
                exit(1);
        }
        for (i = 0; i < 256; i++)
                putc(i, fp);
        rewind(fp);
        for (i = 0; i < 256; i++)
        {
                n = getc(fp);
                if (i != n)
                        printf("expecting %.2X, got %.2X\n", i, n);
        }
        fclose(fp);
}

It should just exit without messages if it was OK; under DJGPP v2.01 it
produces messages for every character after 0D (CR), and the file is
terminated on reading 1A.

(Incidentally, Borland C v4.02 has the correct behaviour; I haven't tested it 
with any other DOS compilers.)

After opening a tmpfile(), call

setmode(fileno(tmpfilehandle))=O_BINARY;

That 'workaround' is not portable - UNIX supports
neither O_BINARY nor setmode (it needs neither, of
course).

*** src/libc/ansi/stdio/tmpfile.c~      Sun Jun 04 02:47:02 1995
--- src/libc/ansi/stdio/tmpfile.c       Thu May 22 15:24:30 1997
***************
*** 21,27 ****
    if (!n_t_r)
      return 0;
  
!   f = fopen(temp_name, (_fmode & O_TEXT) ? "wt+" : "wb+");
    if (f)
    {
      f->_flag |= _IORMONCL;
--- 21,27 ----
    if (!n_t_r)
      return 0;
  
!   f = fopen(temp_name, "wb+");
    if (f)
    {
      f->_flag |= _IORMONCL;