Mail Archives: djgpp/1997/10/06/07:58:00
Thomas Demmer wrote:
> I just stumbled across a little flaw in tmpfile(). It opens
> the file according to the current setting of _fmode either
> int text or binary mode. IMHO this should at least be mentioned
> in the docs ;-)
No, it should be corrected. I raised this as a bug (it's contrary
to the ANSI C specification) as bug number 143 (look in the bug
tracking system on www.delorie.com, and added a patch. It was
accepted that this was a bug and a violation of the ANSI spec.,
but I've seen no sign of an updated library.
I don't know the mechanism for releasing new versions of the
library - perhaps I'm expected to put my recompiled version on
the web?
I reproduce the bug report here:
----------------------------------------------------------------------
When Created: 03/24/1997 10:01:23
In version: 2.01
By whom: crough45 AT amc DOT de
Abstract: ANSI function 'tmpfile' opens file in wrong mode
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.)
Workaround added on 05/17/1997 11:53:18
By whom: rburtonw AT nyx DOT net
After opening a tmpfile(), call
setmode(fileno(tmpfilehandle))=O_BINARY;
Note added on 05/22/1997 09:05:47
By whom: crough45 AT amc DOT de
That 'workaround' is not portable - UNIX supports
neither O_BINARY nor setmode (it needs neither, of
course).
Solution added on 05/26/1997 10:59:20
By whom: crough45 AT amc DOT de
*** 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;
- Raw text -