File position after fopen(file,"a+")?
Michael Bryan
the file position after doing an fopen(file,"a+")? The documentation
I have available is vague, and someone here noticed inconsistent
behaviour across platforms. Given the following program segment:
fp = fopen("temp", "a+");
printf ( "ftell=%d\n", ftell(fp) );
On a Sun, the value is the size of the file (i.e., it is positioned to
the end of the file.) Under HP-UX, the value is always 0. In both
cases, writes properly go to the end of the file. I can understand
either behavior, since "a+" is update/append, which allows reading,
and writes always go to the end of the file. On the Sun, it appears
to "expect" a write, and on the HP, it appears to "expect" a read.
(In simple non-tech terms... :-)
Is this operation supposed to be standard, and hence one of these
systems has a bug? Or is this generally implementation defined?
--
Michael Bryan mic...@resonex.com
This offer law where prohibited by void.
John F. Woods
> fp = fopen("temp", "a+");
> printf ( "ftell=%d\n", ftell(fp) );
The standard says "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. In some implementations, opening a binary file with append mode
('b' as the second or third character in the above list of mode argument
values) may initially position the file position indicator for the stream
beyond the last data written, because of null character padding."
No more does it say, hence either behavior you describe is OK.
Norman Diamond
>According to the description of the standard C library, what is
>the file position after doing an fopen(file,"a+")?
Curiously, it does not appear to be defined. Even fopen(file,"a") seems
not to define the initial file position. Of course, the position will be
defined after the first write, because there's no choice about where the
written data have to go, but the initial position could be anywhere.
For comparison, fopen(file,"w") and fopen(file,"w+") leave no choice for
the file position (I think), since they truncate and/or open a new file
with zero length.
However, fopen(file,"r") and fopen(file,"r+") also don't seem to define
the initial file position. I think this is rather unexpected and could
lead to disasters.
I hope there is or will be an interpretation ruling on "r[+]" at least, and
possibly also for "a[+]". Meanwhile, although implementations are allowed
to define (document) their choices if they wish, they are not even required
to do that much.
--
Norman Diamond dia...@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"C is the Fortran of the 90's." "Wrong. C is the Fortran of the 70's."
Andy Feibus
> On a Sun, the value is the size of the file (i.e., it is positioned to
> the end of the file.) Under HP-UX, the value is always 0. In both
> cases, writes properly go to the end of the file.
>
> systems has a bug? Or is this generally implementation defined?
is to ALWAYS set the file pointer to the start of the file, I'd
say it was either a bug on the Sun (or non-compliance with POSIX.1;
is the Sun running a rev prior to 4.1.1; SunOS was not POSIX compliant
before that rev).
Hope this helps,
Andy Feibus
a...@amfent.gwinnett.com
Fred Zlotnick
>Since fopen is based on open(2), and the POSIX.1 definition for open
POSIX.1 does indeed impose the latter requirement, but makes no requirement
that fopen() be based on open(). Even if an implementation of fopen()
does invoke open(), there is nothing in either the C or POSIX.1 standard
that forbids it from then doing an lseek() or fseek() to the end of
the file (or wherever) before returning. The file offset after an
fopen(..., "a+") is unspecified.
However, Andy's point gives a good quality-of-implementation argument
for why the file offset ought to be 0. This aspect of the SunOS
implementation, while POSIX.1-compliant, is (IMHO) a poor choice.
----
Fred Zlotnick | "A standard is a treaty between the
fr...@mindcraft.com | customer and the implementor."
...!{uupsi,ames}!mindcrf!fred | Henry Spencer
#include <std/disclaimer> |
Walter Murray
> According to the description of the standard C library, what is
> the file position after doing an fopen(file,"a+")?
When a file is opened with append mode, "It is implementation-defined
whether the file position indicator is initially positioned at the
beginning or the end of the file." ANSI 4.9.3.
Walter
------
Norman Diamond
>In article <RJ5aeB...@amfent.Gwinnett.COM> a...@amfent.Gwinnett.COM (Andy Feibus) writes:
>[POSIX-related correction and answer deleted]
There exists a newsgroup comp.std.unix. Perhaps an additional newsgroup is
needed, comp.std.posix, though I thought comp.std.unix concerned POSIX OS.
Anyway, if the question was asking about POSIX OS requirements, it should be
in one of those newsgroups. If it was asking about C language requirements
(a less strict standard), then it was in the right place, but then these two
answers were not quite relevant.
For this particular question, the answer happened to be the same:
no particular file position is required by either standard.
If anyone wants to propose creation of comp.std.posix, you've got my vote.
[Personal opinion only.]
Sean Eric Fagan
>There exists a newsgroup comp.std.unix. Perhaps an additional newsgroup is
>needed, comp.std.posix, though I thought comp.std.unix concerned POSIX OS.
I can say, with all authority, that comp.std.unix is about unix standards.
Just about *any* standard. I take programming questions, debates (although I
try to keep the flames down to a minimum 8-)). I prefer to direct C-related
questions here or to comp.lang.c; system-specific questions I try to direct
elsewhere. (I haven't gotten any complaints... if you are someone who does
have a complaint, please feel free to tell me. I'm open to suggestions...)
The posting that goes out once every 100 or so posts says that the group is
for discussion about all sorts of "unix standards," "particularly of IEEE
P1003, or POSIX." But other things are discussed. (I don't like postings
there related to an individual system, such as '386-specific, or Sun
specific, etc., and that's about it.)
This has been an unpaid solicitation 8-).
--
Sean Eric Fagan | "One form to rule them all, one form to find them, one
s...@kithrup.COM | form to bring them all and in the darkness rewrite the
-----------------+ hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Jim Cathey
>Curiously, it does not appear to be defined. Even fopen(file,"a") seems
>not to define the initial file position. Of course, the position will be
>defined after the first write, because there's no choice about where the
>written data have to go, but the initial position could be anywhere.
Actually, for Unix implementations it might not be what you think.
Multiple processes may have the file open in "a" mode. What this flag
means is that _all_ writes will go onto the end of the file, regardless
of the fseek() position. You cannot seek into the middle of a file for
writing. Because two (or more) unrelated processes are writing to the
file, their knowledge of the file position is transient, at best.
Appending is handled by the OS, on these machines. So, regardless
of what ftell() is after fopen(), it isn't necessarily right anyway.
On a single-tasking machine, the initial ftell() might well be
correct (and stable).
I know that Unix isn't ANSI, but they were seen nodding to each other
in passing at the meetings.
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (ji...@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
"PC's --- the junk bonds of the computer industry"
Norman Diamond
>In article <1992Jan9.0...@news.jit.dec.com> dia...@jit533.enet@tkou01.enet.dec.com (Norman Diamond) writes:
>>Curiously, it does not appear to be defined.
As someone else pointed out, it is implementation-defined. And it is defined
by the standard for the cases of "r" and "r+" (as well as "w" and "w+" which
I mentioned before). ANSI 4.9.3, page 127 lines 4 to 8.
I wonder why no one posted a correction (gentle or otherwise) to my post....
>On a single-tasking machine, the initial ftell() might well be
>correct (and stable).
ftell() has to be correct and stable regardless of the number of tasks.
However, if a non-strictly-conforming program takes advantage of implementation
extensions, then the ANSI C standard has no jurisdiction at all, regarding
ftell() or the integer "+" operator or anything else.
>I know that Unix isn't ANSI, but they were seen nodding to each other
>in passing at the meetings.
Some non-ANSI implementations of C under UNIX OS are rather famous.
ANSI-conforming implementations of C under UNIX OS are also possible.
OS isn't language and language isn't OS.
Walter Murray
> However, fopen(file,"r") and fopen(file,"r+") also don't seem to define
> the initial file position. I think this is rather unexpected and could
> lead to disasters.
I think this is covered in the first paragraph of ANSI 4.9.3.
If the file can support positioning requests, opening it sets the
file position indicator to the beginning, except for append
mode, in which case positioning at the end is also valid.
Walter Murray
-------------
Norman Diamond
>In comp.std.c, dia...@jit533.jit.dec.com (Norman Diamond) writes:
>>However, fopen(file,"r") and fopen(file,"r+") also don't seem to define
>>the initial file position.
Yes, I had missed that particular sentence in 4.9.3.
I think my error was posted around new year's. Mr. Murray's posting was
dated Jan. 9th, arrived here Jan. 23rd, and had a reference line mentioning
someone else's posting of Jan. 8th (not quoted in the article). There might
well be other errors and delayed corrections in the pipeline somewhere....