This is the mail archive of the
mailing list for the glibc project.
Re: Expected behavior?
- From: Juan Piernas Canovas <juan dot piernascanovas at pnl dot gov>
- To: libc-alpha at sourceware dot org
- Date: Tue, 30 Oct 2007 12:37:44 -0700
- Subject: Re: Expected behavior?
- References: <46D8C12C.firstname.lastname@example.org>
Taking up this email that I sent almost two months ago, I have found out
that there is a "bug" in my code. The bug is that I use "w+" to write to
the second file (which is the output file of my program). Since "w+"
(and "w") truncates the file, if several processes open the file at the
same time, a process can delete the information previously written by
another process. I tried several open modes without success, and I
probably left that option without noticing.
But, and here is the funny part, if I want the program to work properly,
the output file must exist and must be opened with "r+". This is
counterintuitive because I just want to write to the file, I do not want
to read it. As I have said, "w" and "w+" truncate the file and they are
not valid options for my program. But "a" and "a+" are not valid options
either. The problem is now that "fseek" does not work with these "fopen"
modes. How is it supposed that I must know that? I have not seen any
information about this problem either in the manual pages or info
entries of fseek and fopen. Moreover, fseek does not fail and returns 0.
I know that, with "a" and "a+", output is written at the end of the file
but, frankly, I assumed that this was the default behavior that you
could change with fseek. Obviously, I was wrong.
I think that a clarification about this issue in the documentation of
fseek would be appreciated.
Juan Piernas Canovas wrote:
Before submitting a bug, I would like to know if the following is an
expected behavior. I have written a small program (attached) which
basically multiplies a set of doubles stored in an input file by a
scalar, and saves the resulting doubles in an output file. As
arguments, the user has to specify an offset and a size. The offset is
the starting point in both the input and output files, and the size
says how many bytes to read from the input file, and write to the
output file. Obviously, if the output file is empty and the offset is
not equal 0, we will be creating a sparse file.
I have also attached a script which runs the program twice by creating
two processes at the same time. Both processes use the same input and
output files, and receive the same scalar and size values, but
different offsets. With the give parameters, the processes read and
write different "disjoint" portions of the input and output files.
Note that the output file will be a sparse one because the processes
leave "holes" in the file. The script also checks whether the content
of the output file is correct or not.
The problem that I'm having is that the output file is not created
correctly, and I am pretty sure that the problem is in the fwrite
function. The first doubles (in an indefinite amount) written by
sometimes the first process, sometimes the second, and sometimes both
processes, are always 0.0, what seems to mean that there is a hole
where there should not be. That occurs randomly.
Please, note that we are talking about independent processes which
must not share any information about the file (such as the file pointer).
Does anyone have any clue about what is happening?
BTW, I do not have any problem if I use the "low-level" open, read,
write and close functions. And I have got the problem in three
different Linux distributions (SLES 10.2-sp1, RHEL 4, Fedora Core 6)
with different glibc versions.
Thanks in advance,
PS. I can send the input file if needed, but it does not contains
anything special, just random numbers.