On Nov 24, 2004, at 6:22 AM, Aleksandar Donev wrote:
>
> > I spent some time debugging a code to eventually find out that a string
> > IO buffer overflowed (as in WRITE(string,format)) and thing were
> > overwritten without an IO runtime error being generated by the
> > compiler.
> > I just wanted to check what the guarantees if any we actually have on
> > the compiler checking for writing past the end of the buffer:
Richard E Maine <[log in to unmask]> replied:
> None. The set of error conditions is processor-dependent....
This is one of the reasons I've advocated for END= and the corresponding
IOSTAT value (IOSTAT_END in F03) for WRITE statements. In the days of
tapes, and disk files with pre-specified maximum extents, WRITE with END=
was useful to detect end-of-reel and end-of-allocated-space conditions.
Of course, it was an extension. Being so, X3J3 never standardized it,
perhaps because of the resistance to standardizing existing practice.
In the current era, the end-of-file condition could be specified to occur
during writing when there is not sufficient space to write the output.
This could mean end-of-reel if the processor supports direct-to-tape I/O,
full disk for disk files, or attempting to write beyond the end of an
internal file (exactly analogous to trying to read beyond the end of one,
which the standard currently requires the processor to detect). Except for
output to an internal file, the processor shouldn't specify what "no more
space" means. Indeed, the operating system may not tell its clients that
the reason a write failed is that there is not sufficient space.
Similarly, the processor could be required to detect an end-of-record
condition that occurs during writing to an internal file (but not otherwise).
--
Van Snyder | What fraction of Americans believe
[log in to unmask] | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.
|