Date:	Sun, 12 Dec 1999 19:34:54 -0500
Message-Id:	<199912130034.TAA03406@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	djgpp-workers AT delorie DOT com
Subject:	[pullmoll AT t-online DOT de: libc bug report]
Reply-To:	djgpp-workers AT delorie DOT com

------- Start of forwarded message -------
Date: Sun, 12 Dec 1999 13:36:02 +0100
From: pullmoll AT t-online DOT de (Juergen Buchmueller)
X-Accept-Language: en
To: dj AT delorie DOT com
Subject: libc bug report
Content-Type: text/plain; charset=iso-8859-1
X-Sender: 0228485758-0001 AT t-dialin DOT net

Hi,

I stumbled across a flaw in DJGPPs implementation of the fopen() libc
function - specificially the "a" append mode.

Here's a short quote from the ANSI specs.

> In 7.19.5.3p5 from the C99 draft standard:
> 
> "Opening a file with append mode (čač as the first character in the mode argument)
> causes all subsequent writes to the file to be forced to the then current end-of-file,
> regardless of intervening calls to the fseek function."

So this piece of code should work different from how it does now
with DJGPP:

#include <stdio.h>
int main(void)
{
  FILE *f;
  f = fopen("test","w");
  fputs("can't be overwritten\n",f);
  fclose(f);
  f = fopen("test","a+");
  fseek(f,0,SEEK_SET);
  fputs("but this call to fwrite() overwrites it\n",f);
  fclose(f);
  return 0;
}

If you let it run and 'cat test', you'll see the problem ;-/

On Linux gcc the mode "a" is implemented according to the specs, previous
contents of a file can't be overwritte.

I hope it'll be easy to fix it.

Regards,
Juergen

PS: I used the libc contained in djlsr202.zip
------- End of forwarded message -------

- Raw text -