Hi all,
In a discussion with Tak-Shing Chan the question came up whether the
as-if rule can cover I/O functions. Basically, he maintains it can, and
I think it doesn't.
Consider two programs:
/*** a.c ***/
#include <stdio.h>
int main(void)
{
fopen("somefile","rb");
return 0;
}
/*** b.c ***/
in main(void)
{
return 0;
}
Would it be legal for a compiler (through optimization), to emit the
same code for program a.c and b.c ?
I'd welcome a reference from the standard.
Best regards,
Sidney
Nov 14 '05
145  6125 
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl... Wojtek Lerch wrote:
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl...
I think it is more likely that the Standard's authors either overlooked,
or chose to ignore, this issue rather than that they made the conscious
choice of allowing conforming implementations to optimize away an
fopen() statement. The latter would have been silly in the extreme.
Why do you think it's such a big deal?
Believe me, I only think it's a big deal in a very relative way. I'm not
going to lose sleep over it.
However, I do feel that standards (and their wording) is important to
get right; people will /use/ these words and take the strictest possible
view while interpreting them (comp.lang.c is a prime example).
Prime, yes, but not a _good_ example. ;) http://groups.google.com/groups?thre...0bell-labs.com
--
Peter
Wojtek Lerch wrote: "Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl...
Wojtek Lerch wrote:
And what exactly do you mean by "optimize away"?
"optimize away" === perform a transformation from a representation where
actual code would be emitted to perform the fopen() call, to a form
where it will not be emitted.
I don't think the C standard requires that any actual code must be emitted
to perform function calls. I do understand what you mean in a context of a
traditional compiler where fopen() is an external function; but if you
propose adding a new requirement to the C standard, it should be described
in terms that make sense in any conceivable implementation, including
interpreters and compilers that have an inline definition of fopen(). If a
compiler transforms the inlined code of fopen() and fclose() to a form where
very little of it is left, where exactly do you propose to draw the line
between "not optimized out" and "optimized out"?
I didn't mean to mandate a classic "jump to subroutine" or something
like that; the notion I try to convey is that the OS specific part
should not be optimized away if it cannot be proven it has no side
effects. However, this hinges more on the definition of side effects
than on anything else.
On any implementation where fopen() is defined as a macro or an inline
function,
there's a good
chance that significant portions of it are often optimized away.
Well, if you define "significant" as "big". I, on the other hand, would
prefer the traditional definition of "significant", and I would hope
that a compiler does not optimize away any significant portions.
And what if the compiler can prove that none are significant?
My point is that for something like fopen(), the compiler can never be
able to prove this, unless it is given extra assumptions.
The C standard (erroneously, I think) provides those extra assumptions
by giving a list of cases it calls "side effects". If none of these
cases is relevant, the compiler may optimize at will.
By this rule, and given a strict interpretation of the rules, it is
permissible for a C compiler to optimize away fopen() here:
#include <stdio.h>
int main(void)
{
fopen("somefile", "rb");
return 0;
}
.... Following Mr. Pop's argument, it would even be permissible to
optimize this away if the fopen() would have a side effect (in the
traditional, non-C sense of the word) such as altering a file attribute.
My point is more that the C standard should not be readable in a way
that would condone this.
Admittedly, the 'volatile function' suggestion I gave is not a good
solution, as you point out. I think the root cause of the problem is in
the way the standard (incompletely) lists possible side effects.
Do you think it would be possible to specify that in a
meaningful way, without referring to details of any particular OS, and
without introducing a requirement that an OS must be a distinct part of any conforming implementation?
I would think that a wording can be found that satisfies all, yes.
If not, I think it would at least be possible to do better than the
current 5.1.2.3 #2, which I think is just plain silly; it is easy to
give an example that isn't covered but should be covered (see above).
Yes. The fact that a function must be assumed to have side effects (and
cannot, therefore, be safely optimized away) could be indicated in the
standard.
I don't think it would make sense for the standard to say that the
implementor must *assume* that the fopen() function has side effects,
without saying what side effects are required. Since it's the implementor's
job to write the compiler, the OS, the filesystem, and the library code for
fopen(), he knows whether fopen() has any side effects or not.
You are right, the volatile function idea is not good.
In the cases
when he can prove that there are no side effects, why should he not let his
compiler optimize the call away?
Indeed. However, I have a hard time seeing how a compiler could prove
that fopen() is side-effect free without the Standard lending a hand, as
it does now, with its flawed attempt to define a side effect.
If the same implementation also claims conformance to some other document,
for instance POSIX, then the other document's requirements may be different.
In particular, POSIX requires files to have some attributes that the C
standard never mentions, and describes how various standard C functions
should affect those attributes. But if an implementation doesn't claim
conformance to POSIX, the C standard has no business of dictating how its
fopen() should affect file attributes, even it's an implementation for an OS
that also has a different, POSIX-conforming C implementation.
Ok, but what part in POSIX specifically mandates that fopen() must not
be optimized away? It would have to specifically mention that the notion
of a file, as understood by its C compiler, is to be augmented by
considering file attributes to be covered by the phrase "modifying a
file". Basically, POSIX would need to override the C standard in this
respect. Personally, I'd advocate that function could be declared 'volatile', to
indicate precisely this.
You mean, to try to convince the compiler that the function has side effects
even if the compiler can prove by looking at the function's code that it has
none? Why?
Forget I said this ... :-)
Best regards,
Sidney
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bv**********@news.tudelft.nl... Wojtek Lerch wrote: "Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl...Wojtek Lerch wrote:
.... I didn't mean to mandate a classic "jump to subroutine" or something
like that; the notion I try to convey is that the OS specific part
should not be optimized away if it cannot be proven it has no side
effects. However, this hinges more on the definition of side effects
than on anything else.
The C standard doesn't know the concept of the "OS specific part". It's all
just "the implementation". If the OS knows that something can be optimized
away, the implementation knows that it can be optimized away. How much of
that knowledge is made available to the compiler, on an implementation that
has a compiler, is an implementation detail that the C standard shouldn't be
concerned about.
If you don't like the term "side effects", perhaps we could call it
"required behaviour". The C standard requires that implementations behave
in a way that the C standard describes as required behaviour. Since the C
standard doesn't talk about file attributes, it neither requires nor forbids
fopen() to modify any attributes that files may have on some
implementations. On an implementation that does have file attributes, it's
up to the implementation to define how fopen() affects them, and to make
sure that it indeed affects them that way. I really can't understand why
you think it's silly that the C standard chooses not to mention that on an
implementation that defines how fopen() affects file attributes, fopen()
must affect them the way the implementation defines it. I think it would be
silly if it did.
.... And what if the compiler can prove that none are significant?
My point is that for something like fopen(), the compiler can never be
able to prove this, unless it is given extra assumptions.
You keep making the distinction between the compiler and the rest of the
implementation. That distinction does not exist in the C standard. The
compiler, in an implementation that has a compiler, is free to know as much
about the rest of the implementation as its authors want it to, and
therefore doesn't need to make any extra assumptions. If a call to fopen()
isn't required to produce any significant effects in some detectable
situations, the implementor is free to write a compiler that detects those
situations and optimizes those calls away. I really don't understand why
you think that allowing this freedom to the implementor is a bad idea.
The C standard (erroneously, I think) provides those extra assumptions
by giving a list of cases it calls "side effects". If none of these
cases is relevant, the compiler may optimize at will.
Sure, but it's not *required* to optimize. If an implementor wants to have
a filesystem that guarantees that any successful call to fopen() changes
some attributes of a file, then even though the C standard doesn't refer to
those attribute changes as "side effects" and doesn't require them, he's
free to make his implementation behave that way. Of course, that means that
he'll have to make sure that his compiler doesn't optimize away the part of
fopen() that makes his implementation behave that way. Otherwise, the
implementation would break its own promise that calling fopen() changes the
attributes. But I don't think it makes sense to complain that the C
standard doesn't say that implementations are required to keep their own
promises.
By this rule, and given a strict interpretation of the rules, it is
permissible for a C compiler to optimize away fopen() here:
#include <stdio.h>
int main(void)
{
fopen("somefile", "rb");
return 0;
}
... Following Mr. Pop's argument, it would even be permissible to
optimize this away if the fopen() would have a side effect (in the
traditional, non-C sense of the word) such as altering a file attribute.
Of course, provided that the implementation doesn't claim conformance to a
document that requires altering a file attribute. The C standard is not
such a document.
My point is more that the C standard should not be readable in a way
that would condone this.
One more time: why not? What kind of problems are created by condoning it?
And where exactly do you want to draw the line?
On a typical POSIX system, writing data to a file causes the file's
attributes to be modified, and also causes the data to be transmitted
through some hardware and stored on some physical media. Do you think that
the C standard should consider both those things to be "side effects" and
forbid implementations to optimize them away? Even if the file is deleted
before its contents make it to the physical disk? If not, what kind of
wording would you use to describe the difference in general terms, in a way
suitable for a language standard?
Do you think it would be possible to specify that in a
meaningful way, without referring to details of any particular OS, and
without introducing a requirement that an OS must be a distinct part of
any conforming implementation?
I would think that a wording can be found that satisfies all, yes.
I'm really curious what you think such wording might look like.
If not, I think it would at least be possible to do better than the
current 5.1.2.3 #2, which I think is just plain silly; it is easy to
give an example that isn't covered but should be covered (see above).
You keep complaining and calling it silly, but I still haven't seen an
explanation of why you think the standard should cover it. When I asked you
why you think it's such a big deal, your answer was that it wasn't really
such a big deal to you, personally. That's not very convincing.
.... In the cases
when he can prove that there are no side effects, why should he not let
his compiler optimize the call away?
Indeed. However, I have a hard time seeing how a compiler could prove
that fopen() is side-effect free without the Standard lending a hand, as
it does now, with its flawed attempt to define a side effect.
What kind of problems does it create?
.... If the same implementation also claims conformance to some other
document, for instance POSIX, then the other document's requirements may be
different. In particular, POSIX requires files to have some attributes that the C
standard never mentions, and describes how various standard C functions
should affect those attributes. But if an implementation doesn't claim
conformance to POSIX, the C standard has no business of dictating how
its fopen() should affect file attributes, even it's an implementation for
an OS that also has a different, POSIX-conforming C implementation.
Ok, but what part in POSIX specifically mandates that fopen() must not
be optimized away? It would have to specifically mention that the notion
of a file, as understood by its C compiler, is to be augmented by
considering file attributes to be covered by the phrase "modifying a
file". Basically, POSIX would need to override the C standard in this
respect.
No, POSIX has no authority to change the C standard's definition of
"modifying a file". But POSIX can, and does, add its own requirements to
the semantics of fopen(). In particular, this is what POSIX says about how
fopen() modifies the POSIX file attributes:
If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, and the file did not
previously exist, upon successful completion, the fopen() function shall
mark for update the st_atime, st_ctime, and st_mtime fields of the file and
the st_ctime and st_mtime fields of the parent directory.
If mode is w, wb, w+, wb+, or w+b, and the file did previously exist, upon
successful completion, fopen() shall mark for update the st_ctime and
st_mtime fields of the file. The fopen() function shall allocate a file
descriptor as open() does.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
[...] >So anything that can be modified by an external process is not a file?
Or an implementation that allows such modifications is non-conforming.
Most multi-user implementations allow one process (whatever that might
mean) to modify a file while another process reads it. I hardly think
that it was the intent that any such implementation is non-conforming,
or that any such file is not a file, or that such an important rule
would be expressed in a section that explicitly refers only to text
streams.
Well, here are the guarantees for binary streams:
3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary
stream shall compare equal to the data that were earlier written
^^^^^
out to that stream, under the same implementation. Such a stream
may, however, have an implementation-defined number of null
characters appended to the end of the stream.
As you probably know, it's not the actual implementations that dictate
how to interpret the C standard. The specifications of both text and
binary streams clearly reflect the same intent: with certain explicitly
mentioned exceptions, a program is supposed to be able to read back
what it wrote to a file. And there are plenty of multi-user
implementations that satisfy this condition, even if the Unix-based ones
don't.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Wojtek Lerch wrote: "Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bv**********@news.tudelft.nl...
Wojtek Lerch wrote:
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl...
Wojtek Lerch wrote:
...
I didn't mean to mandate a classic "jump to subroutine" or something
like that; the notion I try to convey is that the OS specific part
should not be optimized away if it cannot be proven it has no side
effects. However, this hinges more on the definition of side effects
than on anything else.
The C standard doesn't know the concept of the "OS specific part". It's all
just "the implementation". If the OS knows that something can be optimized
away, the implementation knows that it can be optimized away. How much of
that knowledge is made available to the compiler, on an implementation that
has a compiler, is an implementation detail that the C standard shouldn't be
concerned about.
I do agree with you that this is how it should be. However, with Dan
Pop, I am unfortunately unable to find a justification for this entirely
reasonable position in the standard itself.
If you don't like the term "side effects", perhaps we could call it
"required behaviour".
Let's not, shall we, it is confusing enough as it is, with the C
standard defining side effects as a subset of things that are normally
understood as side effects.
I have no problem whatsoever with the term 'side effects', but I do have
a problem with the definition given of it in the standard.
The C standard requires that implementations behave
in a way that the C standard describes as required behaviour.
If I substitute back "side effects" here for "required behavior", I get
something that doesn't make sense to me.
Since the C
standard doesn't talk about file attributes, it neither requires nor forbids
fopen() to modify any attributes that files may have on some
implementations.
True.
On an implementation that does have file attributes, it's
up to the implementation to define how fopen() affects them, and to make
sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
I really can't understand why
you think it's silly that the C standard chooses not to mention that on an
implementation that defines how fopen() affects file attributes, fopen()
must affect them the way the implementation defines it. I think it would be
silly if it did.
Ok, well, we disagree on this.
And what if the compiler can prove that none are significant?
My point is that for something like fopen(), the compiler can never be
able to prove this, unless it is given extra assumptions.
You keep making the distinction between the compiler and the rest of the
implementation. That distinction does not exist in the C standard. The
compiler, in an implementation that has a compiler, is free to know as much
about the rest of the implementation as its authors want it to, and
therefore doesn't need to make any extra assumptions. If a call to fopen()
isn't required to produce any significant effects in some detectable
situations, the implementor is free to write a compiler that detects those
situations and optimizes those calls away. I really don't understand why
you think that allowing this freedom to the implementor is a bad idea.
I'm all for implementor freedom, as long as decent semantic guarantees
are made. I do not see anything in the standard that takes away the
freedom of the implementor to optimize an fopen away.
The C standard (erroneously, I think) provides those extra assumptions
by giving a list of cases it calls "side effects". If none of these
cases is relevant, the compiler may optimize at will.
Sure, but it's not *required* to optimize.
Yes, but it *may*. My point is that the standard should explicitly
forbid this for calls that have side effects (in the normal, not
c-standard sense).
If an implementor wants to have
a filesystem that guarantees that any successful call to fopen() changes
some attributes of a file, then even though the C standard doesn't refer to
those attribute changes as "side effects" and doesn't require them, he's
free to make his implementation behave that way.
Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the standard to
justify this. I think that is bad.
Of course, that means that
he'll have to make sure that his compiler doesn't optimize away the part of
fopen() that makes his implementation behave that way. Otherwise, the
implementation would break its own promise that calling fopen() changes the
attributes. But I don't think it makes sense to complain that the C
standard doesn't say that implementations are required to keep their own
promises.
I miss your point, here, I'm afraid.
By this rule, and given a strict interpretation of the rules, it is
permissible for a C compiler to optimize away fopen() here:
#include <stdio.h>
int main(void)
{
fopen("somefile", "rb");
return 0;
}
... Following Mr. Pop's argument, it would even be permissible to
optimize this away if the fopen() would have a side effect (in the
traditional, non-C sense of the word) such as altering a file attribute.
Of course, provided that the implementation doesn't claim conformance to a
document that requires altering a file attribute. The C standard is not
such a document.
I agree with you 100% on this, but I don't find a reference to the
possibility of externally defined by an entity outside of the c
standard, in the c standard.
My point is more that the C standard should not be readable in a way
that would condone this.
One more time: why not? What kind of problems are created by condoning it?
It permits to optimize an fopen() away even if the fopen() would have a
side effect (in the traditional, non-C sense of the word) such as
altering a file attribute.
And where exactly do you want to draw the line?
On a typical POSIX system, writing data to a file causes the file's
attributes to be modified, and also causes the data to be transmitted
through some hardware and stored on some physical media. Do you think that
the C standard should consider both those things to be "side effects" and
forbid implementations to optimize them away? Even if the file is deleted
before its contents make it to the physical disk? If not, what kind of
wording would you use to describe the difference in general terms, in a way
suitable for a language standard?
I cannot offer a wording, but that doesn't mean that people more clever
than I am couldn't think of one.
IMHO, the current wording is not ok.
>Do you think it would be possible to specify that in a
>meaningful way, without referring to details of any particular OS, and
>without introducing a requirement that an OS must be a distinct part of
any conforming implementation?
I would think that a wording can be found that satisfies all, yes.
I'm really curious what you think such wording might look like.
Me too.
If not, I think it would at least be possible to do better than the
current 5.1.2.3 #2, which I think is just plain silly; it is easy to
give an example that isn't covered but should be covered (see above).
You keep complaining and calling it silly, but I still haven't seen an
explanation of why you think the standard should cover it.
Well excuse me, but then you haven't read very well. The reason is that
it is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation may
optimize away an fopen(), even if the plaform has last-touch attributes
or something similar.
When I asked you
why you think it's such a big deal, your answer was that it wasn't really
such a big deal to you, personally. That's not very convincing.
Well, what can I say.
In the cases
when he can prove that there are no side effects, why should he not let his compiler optimize the call away?
Indeed. However, I have a hard time seeing how a compiler could prove
that fopen() is side-effect free without the Standard lending a hand, as
it does now, with its flawed attempt to define a side effect.
What kind of problems does it create?
In practice: none. In theory: see above and before.
[...]
Ok, but what part in POSIX specifically mandates that fopen() must not
be optimized away? It would have to specifically mention that the notion
of a file, as understood by its C compiler, is to be augmented by
considering file attributes to be covered by the phrase "modifying a
file". Basically, POSIX would need to override the C standard in this
respect.
No, POSIX has no authority to change the C standard's definition of
"modifying a file". But POSIX can, and does, add its own requirements to
the semantics of fopen(). In particular, this is what POSIX says about how
fopen() modifies the POSIX file attributes:
If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, and the file did not
previously exist, upon successful completion, the fopen() function shall
mark for update the st_atime, st_ctime, and st_mtime fields of the file and
the st_ctime and st_mtime fields of the parent directory.
If mode is w, wb, w+, wb+, or w+b, and the file did previously exist, upon
successful completion, fopen() shall mark for update the st_ctime and
st_mtime fields of the file. The fopen() function shall allocate a file
descriptor as open() does.
Hmmm, I was looking for fopen("somefile", "rb").... No mention of that?
Best regards,
Sidney Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
[...] >So anything that can be modified by an external process is not a file?
Or an implementation that allows such modifications is non-conforming.
Most multi-user implementations allow one process (whatever that might
mean) to modify a file while another process reads it. I hardly think
that it was the intent that any such implementation is non-conforming,
or that any such file is not a file, or that such an important rule
would be expressed in a section that explicitly refers only to text
streams.
Well, here are the guarantees for binary streams:
3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary
stream shall compare equal to the data that were earlier written
^^^^^
out to that stream, under the same implementation. Such a stream
may, however, have an implementation-defined number of null
characters appended to the end of the stream.
As you probably know, it's not the actual implementations that dictate
how to interpret the C standard. The specifications of both text and
binary streams clearly reflect the same intent: with certain explicitly
mentioned exceptions, a program is supposed to be able to read back
what it wrote to a file. And there are plenty of multi-user
implementations that satisfy this condition, even if the Unix-based ones
don't.
Assume an implementation that allows two C programs to run
concurrently. Assume that both programs access the same disk file,
one writing to it, the other reading from it. Assume that coherence
is maintained somehow (e.g., that the second program will never see a
partial write performed by the first). As far as I can tell, such an
implementation would not violate the guarantees for binary streams.
The "data that were earlier written out to that stream" were not
necessarily written by the current program.
(If the writing process isn't a C program, and doesn't access the disk
file though a "stream", things get a bit more confusing.)
The standard doesn't say anything about parallel processes, but it
doesn't specifically exclude them. The quoted paragraph could be read
either way; I'm deliberately trying to read it in a way that doesn't
exclude reasonable real-world implementations.
Perhaps what the standard *should* say is that data in external files
is "volatile", or that it's implementation-defined whether such data
is "volatile". I'm not necessarily using the word "volatile" in the
exact sense defined by the standard; the general idea is that the
contents of a file may change due to circumstances beyond the control
of the current program.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Keith Thompson wrote: The standard doesn't say anything about parallel processes, but it
doesn't specifically exclude them. The quoted paragraph could be read
either way; I'm deliberately trying to read it in a way that doesn't
exclude reasonable real-world implementations.
The actions of other processes/tasks lies outside the scope
of the standard. It describes the effect of a program "in
isolation". Also, a strictly conforming program has only
one thread of execution. (That isn't explicit either, but
it is inherent in the specification.)
Perhaps what the standard *should* say is that data in external files
is "volatile", or that it's implementation-defined whether such data
is "volatile". I'm not necessarily using the word "volatile" in the
exact sense defined by the standard; the general idea is that the
contents of a file may change due to circumstances beyond the control
of the current program.
No, we don't want to try to describe such environmental
complexities, especially since the only purpose would be
to exclude them.
I don't think any C implementer has misunderstood any of
this.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
>Da*****@cern.ch (Dan Pop) writes:
>> In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
>[...]
>> >So anything that can be modified by an external process is not a file?
>>
>> Or an implementation that allows such modifications is non-conforming.
>
>Most multi-user implementations allow one process (whatever that might
>mean) to modify a file while another process reads it. I hardly think
>that it was the intent that any such implementation is non-conforming,
>or that any such file is not a file, or that such an important rule
>would be expressed in a section that explicitly refers only to text
>streams.
Well, here are the guarantees for binary streams:
3 A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary
stream shall compare equal to the data that were earlier written
^^^^^
out to that stream, under the same implementation. Such a stream
may, however, have an implementation-defined number of null
characters appended to the end of the stream.
As you probably know, it's not the actual implementations that dictate
how to interpret the C standard. The specifications of both text and
binary streams clearly reflect the same intent: with certain explicitly
mentioned exceptions, a program is supposed to be able to read back
what it wrote to a file. And there are plenty of multi-user
implementations that satisfy this condition, even if the Unix-based ones
don't.
Assume an implementation that allows two C programs to run
concurrently. Assume that both programs access the same disk file,
one writing to it, the other reading from it. Assume that coherence
is maintained somehow (e.g., that the second program will never see a
partial write performed by the first). As far as I can tell, such an
implementation would not violate the guarantees for binary streams.
The "data that were earlier written out to that stream" were not
necessarily written by the current program.
You're confusing "stream" and "file". A stream exists only in the
context of the program creating it. It is created by an fopen()
function call and destroyed by a corresponding fclose() function call,
or as part of program termination. Depending on the way it was created,
a stream may or may not alter the contents of the associated file. What
the semantics of a stream explicitly exclude is having two streams
connected to the same file in write mode, at the same time, whether the
two streams belong to the same program or not (note that you don't need
a multitasking/multithreading environment in order to have a conformance
problem here: if the same program can simultaneously open the same file
in write mode twice, the same problem can arise). The issue can be
trivially handled by the implementor, using the file locking primitives
of the underlying OS.
Your scenario is perfectly possible, but it has exactly zilch to do
with our discussion, since the same file is accessed by two *different*
streams. The program opening the stream in read mode can get anything
at all without having the implementation's conformance affected in any
way. It is the program that opened it in read/write mode that has some
guarantees, and these guarantees are not affected by the existence of
the other program that accesses the file in read-only mode.
(If the writing process isn't a C program, and doesn't access the disk
file though a "stream", things get a bit more confusing.)
The standard doesn't say anything about parallel processes, but it
doesn't specifically exclude them. The quoted paragraph could be read
either way; I'm deliberately trying to read it in a way that doesn't
exclude reasonable real-world implementations.
The quoted paragraph talks about streams, not about files, so you're
misreading it.
Perhaps what the standard *should* say is that data in external files
is "volatile", or that it's implementation-defined whether such data
is "volatile". I'm not necessarily using the word "volatile" in the
exact sense defined by the standard; the general idea is that the
contents of a file may change due to circumstances beyond the control
of the current program.
The standard says what it says and there are plenty of implementations
that conform to its requirements. Submit a DR if you think that it
should say something else, so that typical Unix implementations would
have a fighting chance to conform. Right now, they are hopelessly broken.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Douglas A. Gwyn" <DA****@null.net> writes: Keith Thompson wrote: The standard doesn't say anything about parallel processes, but it
doesn't specifically exclude them. The quoted paragraph could be read
either way; I'm deliberately trying to read it in a way that doesn't
exclude reasonable real-world implementations.
The actions of other processes/tasks lies outside the scope
of the standard. It describes the effect of a program "in
isolation". Also, a strictly conforming program has only
one thread of execution. (That isn't explicit either, but
it is inherent in the specification.)
Perhaps what the standard *should* say is that data in external files
is "volatile", or that it's implementation-defined whether such data
is "volatile". I'm not necessarily using the word "volatile" in the
exact sense defined by the standard; the general idea is that the
contents of a file may change due to circumstances beyond the control
of the current program.
No, we don't want to try to describe such environmental
complexities, especially since the only purpose would be
to exclude them.
I don't think any C implementer has misunderstood any of
this.
Then perhaps it's a good thing I'm not a C implementer. 8-)}
Suppose I have two C programs, Foo and Bar. Foo opens an existing
file and reads some data from it. Bar opens the same file and updates
it. Foo then seeks and re-reads the data (that would be identical to
the initial data if Bar hadn't intervened), and gets something
different from what it saw the first time. Is the implementation
non-conforming, or are the programs just acting outside the scope of
the standard? Does the standard forbid this behavior or does it
merely ignore it?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
"Douglas A. Gwyn" wrote: Keith Thompson wrote:
.... snip ... Perhaps what the standard *should* say is that data in external
files is "volatile", or that it's implementation-defined whether
such data is "volatile". I'm not necessarily using the word
"volatile" in the exact sense defined by the standard; the
general idea is that the contents of a file may change due to
circumstances beyond the control of the current program.
No, we don't want to try to describe such environmental
complexities, especially since the only purpose would be
to exclude them.
I don't think any C implementer has misunderstood any of
this.
ISTM that the situation, barring any use of seeks, splits into
three cases, all easily implemented.
a. The program writes, and then reads back, its own file. The
standard insists that it read back what it wrote.
b. The program writes, and then abandons, the file. What further
use is made of that is outside the provenance of the standard.
c. The program reads a file provided from somewhere else. All
that is strictly necessary is that repeated reads produce the same
result. Even this is not strictly necessary, since there is no
requirement for rewind to work.
The case involving seeks is neatly covered by the lack of
insistence that seeks work. All the other cases are covered by
the fact that almost any OS can provide exclusive access to any
given file.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>... Wojtek Lerch wrote:
.... On an implementation that does have file attributes, it's
up to the implementation to define how fopen() affects them, and to make
sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
It's not a requirement of the standard; it's outside the scope of the
standard. It's simply a matter of proper assignment of responsibility.
.... Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the standard to
justify this. I think that is bad.
The implementor can also point to the standard and say "it doesn't say
I can't kill you - therefore, I can kill you". Is that problem within
the scope of the standard, or is it more properly a matter for the
legal code to address?
.... Of course, provided that the implementation doesn't claim conformance to a
document that requires altering a file attribute. The C standard is not
such a document.
I agree with you 100% on this, but I don't find a reference to the
possibility of externally defined by an entity outside of the c
standard, in the c standard.
Except in the most indirect possble ways, the C standard also fails to
mention that a C program could cause data to be read from a modem. If
an implementation translated a program in such a way that, when
executed, it caused data to be read from a modem, it would be a
non-conforming implementation?
.... It permits to optimize an fopen() away even if the fopen() would have a
side effect (in the traditional, non-C sense of the word) such as
altering a file attribute.
So? That's a problem with the implementation's failure to comform to
platform requirements, not a problem with the C standard. You keep complaining and calling it silly, but I still haven't seen an
explanation of why you think the standard should cover it.
Well excuse me, but then you haven't read very well. The reason is that
it is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation may
optimize away an fopen(), even if the plaform has last-touch attributes
or something similar.
Yes, but you haven't explained why you think that's the C standard's
responsibility. It seems to me that it's a platform-specific problem;
for instance, on POSIX platforms, it's the responsibility of the POSIX
standard.
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>... Wojtek Lerch wrote: "Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bv**********@news.tudelft.nl...Wojtek Lerch wrote:
"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:bu**********@news.tudelft.nl...
.... I have no problem whatsoever with the term 'side effects', but I do
have a problem with the definition given of it in the standard.
But you don't seem to be willing to suggest a better definition, or
even to explain what you think is wrong with the existing one without
using terms that have no meaning in the C standard, like the "OS
specific part" of a function call, or "side effects in the tradidional
sense".
.... > On an implementation that does have file attributes, it's
> up to the implementation to define how fopen() affects them, and
to make > sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
There is none. The C standard doesn't care. That's the point. Is it
really that difficult?
If an implementation wants to say that it has file attributes and to
promise that every successfull call to fopen() modifies them, it's its
choice whether to make that promise or not. If it does make that
promise, it's reasonable to expect that it actually behaves that way.
If it then sometimes optimizes a fopen() call away, that's a
discrepancy between what the implementation has promised and how it
behaves. You don't need a quote from the C standard to complain to
the implementor about the discrepancy. The discrepancy is all you
need to justify a complaint, even if it doesn't break the
implementation's conformance to the C standard.
.... I'm all for implementor freedom, as long as decent semantic
guarantees are made. I do not see anything in the standard that takes away the
freedom of the implementor to optimize an fopen away.
I don't suppose you would be willing to explain how you imagine the C
standard should define "decent semantic guarantees", would you?...
>>The C standard (erroneously, I think) provides those extra
assumptions >>by giving a list of cases it calls "side effects". If none of
these >>cases is relevant, the compiler may optimize at will.
> Sure, but it's not *required* to optimize.
Yes, but it *may*. My point is that the standard should explicitly
forbid this for calls that have side effects (in the normal, not
c-standard sense).
Sorry, but what exactly do you mean by "calls that have side effects"?
If the implementation optimizes a call away, then it doesn't have
side effects. Unless the standard requires that call to have some
specific side effects, how exactly is the implementor supposed to know
that the call *should have* some side effects, according to you?
> If an implementor wants to have
> a filesystem that guarantees that any successful call to fopen()
changes > some attributes of a file, then even though the C standard
doesn't refer to > those attribute changes as "side effects" and doesn't require
them, he's > free to make his implementation behave that way.
Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the
standard to justify this. I think that is bad.
What do you mean by "ignore the side effects"? If he optimizes fopen()
away, there are no side effects left to ignore. Do you mean he can
choose to ignore *his own promise* that fopen() always modifies file
attributes? And that the current wording of the C standard can somehow
help him justify breaking the promise? I don't think that would make a
lot of sense. Just because the C standard doesn't require that
implementors make that promise in the first place, that's no
justification to make it but then break it.
.... >>... Following Mr. Pop's argument, it would even be permissible
to >>optimize this away if the fopen() would have a side effect (in
the >>traditional, non-C sense of the word) such as altering a file
attribute. >
> Of course, provided that the implementation doesn't claim
conformance to
a > document that requires altering a file attribute. The C
standard is not > such a document.
I agree with you 100% on this, but I don't find a reference to the
possibility of externally defined by an entity outside of the c
standard, in the c standard.
Sorry, you lost me here. The possibility of what?
>>My point is more that the C standard should not be readable in
a way >>that would condone this.
>
> One more time: why not? What kind of problems are created by
condoning it?
It permits to optimize an fopen() away even if the fopen() would
have a side effect (in the traditional, non-C sense of the word) such as
altering a file attribute.
If running the unoptimized code of fopen() had a side effect of
causing a disk drive to move its head and read some data, do you
believe that the C standard should forbid optimizing that side effect
away, too? Should the C standard forbid filesystems to cache data?
.... I cannot offer a wording, but that doesn't mean that people more
clever than I am couldn't think of one.
No, but I think you'll have a hard time trying to convince them that
they need to.
IMHO, the current wording is not ok.
Yeah, I've heard you...
.... > You keep complaining and calling it silly, but I still haven't
seen an > explanation of why you think the standard should cover it.
Well excuse me, but then you haven't read very well. The reason is
that it is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation
may optimize away an fopen(), even if the plaform has last-touch
attributes or something similar.
What's a "platform"?
How can you know that it has last-touch attributes if not all calls to
fopen() are guaranteed to change the attributes?
If the implementation doesn't claim that every successful call to
fopen() modifies file attributes, why is the optimization a bad thing?
.... > No, POSIX has no authority to change the C standard's definition
of > "modifying a file". But POSIX can, and does, add its own
requirements
to > the semantics of fopen(). In particular, this is what POSIX
says about
how > fopen() modifies the POSIX file attributes:
>
> If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, [...]
> If mode is w, wb, w+, wb+, or w+b, [...]
Hmmm, I was looking for fopen("somefile", "rb").... No mention of
that?
Funny, isn't it? It seems that POSIX doesn't mind if a compiler
optimizes your fopen() call away, either...
James Kuyper wrote: Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>...
Wojtek Lerch wrote:
...
On an implementation that does have file attributes, it's
up to the implementation to define how fopen() affects them, and to make
sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
It's not a requirement of the standard; it's outside the scope of the
standard. It's simply a matter of proper assignment of responsibility.
That's fine by me. In the same vein, I think the standard has no
business defining side effects by enumeration (including file
modification, and excluding reading).
...
Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the standard to
justify this. I think that is bad.
The implementor can also point to the standard and say "it doesn't say
I can't kill you - therefore, I can kill you". Is that problem within
the scope of the standard, or is it more properly a matter for the
legal code to address?
I think your analogy is faulty. As far as C is concerned, the standard
/is/ the law. In this law, an attempt is made to define side effects
that is (when read literally) is incomplete. That's all there is to it,
as far as I am concerned.
...
Of course, provided that the implementation doesn't claim conformance to a
document that requires altering a file attribute. The C standard is not
such a document.
I agree with you 100% on this, but I don't find a reference to the
possibility of externally defined by an entity outside of the c
standard, in the c standard.
Except in the most indirect possble ways, the C standard also fails to
mention that a C program could cause data to be read from a modem. If
an implementation translated a program in such a way that, when
executed, it caused data to be read from a modem, it would be a
non-conforming implementation?
I sincerely think you mis-understand my position. I don't particularly
/mind/ the C standard being vague on some issues that are very hard to
define in a water-tight fashion (although, if possible, it should be
done); "side-effects" are a prime example. However, instead of being a
bit vague on the concept of side effects (as it is, for example, with
respect to files) the standard is quite specific (but, alas, incomplete
from a practical point of view) with regard to what is considered a side
effect and what not.
It permits to optimize an fopen() away even if the fopen() would have a
side effect (in the traditional, non-C sense of the word) such as
altering a file attribute.
So? That's a problem with the implementation's failure to comform to
platform requirements, not a problem with the C standard.
That's one way of looking at it. But I would appreciate a hint in the
standard that some side-effects can be imposed on library routines by
the operating environment, in additions to the short-list given in the
standards. With a few words to that effect, I'd be satisfied.
You keep complaining and calling it silly, but I still haven't seen an
explanation of why you think the standard should cover it.
Well excuse me, but then you haven't read very well. The reason is that
it is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation may
optimize away an fopen(), even if the plaform has last-touch attributes
or something similar.
Yes, but you haven't explained why you think that's the C standard's
responsibility. It seems to me that it's a platform-specific problem;
for instance, on POSIX platforms, it's the responsibility of the POSIX
standard.
That would be fine by me. A couple of words with regard to this
separation of responsibilities in the standard couldn't hurt, though.
Best regards,
Sidney
Wojtek Lerch wrote: Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>...
I have no problem whatsoever with the term 'side effects', but I do
have a problem with the definition given of it in the standard.
But you don't seem to be willing to suggest a better definition,
"Unable" would be a better word. I think I cannot provide something you
couldn't shoot holes in.
Having said that, suppose we were having this discussion in a universe
where the C standard didn't provide a definition, and upon your prompt
I would provide to you this definition:
"Accessing a volatile object, modifying an object, modifying a file, or
calling a function that does any of those operations are all side
effects, which are changes in the state of the execution environment."
.... would you accept this?
or even to explain what you think is wrong with the existing one without
using terms that have no meaning in the C standard, like the "OS
specific part" of a function call, or "side effects in the tradidional
sense".
Well, I think it is impossible to talk about what's wrong with the
standard in this respect without reference to such notions; it's a bit
of a bootstrapping problem.
On an implementation that does have file attributes, it's
>up to the implementation to define how fopen() affects them, and
to make sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
There is none. The C standard doesn't care. That's the point. Is it
really that difficult?
Not at all. It's just that I would have appreciated a disclaimer stating
something like this:
"The execution environment may impose semantics / side effects in
addition to (but not contradicting) the semantics and side effects as
defined in this standard, for the following I/O related functions: ..."
Is that so much to ask?
If an implementation wants to say that it has file attributes and to
promise that every successfull call to fopen() modifies them, it's its
choice whether to make that promise or not. If it does make that
promise, it's reasonable to expect that it actually behaves that way.
If it then sometimes optimizes a fopen() call away, that's a
discrepancy between what the implementation has promised and how it
behaves. You don't need a quote from the C standard to complain to
the implementor about the discrepancy. The discrepancy is all you
need to justify a complaint, even if it doesn't break the
implementation's conformance to the C standard.
Again, fine by me. I'd appreciate a little note that implementations may
define additional semantics on top of the C standard.
I'm all for implementor freedom, as long as decent semantic guaranteesare made. I do not see anything in the standard that takes away the
freedom of the implementor to optimize an fopen away.
I don't suppose you would be willing to explain how you imagine the C
standard should define "decent semantic guarantees", would you?...
No, because I cannot give something that is good enough to withstand
critique. However, I have given one example where currently the C
standard doesn't provide decent semantic guarantees, in my opinion.
Yes, but it *may*. My point is that the standard should explicitly
forbid this for calls that have side effects (in the normal, not
c-standard sense).
Sorry, but what exactly do you mean by "calls that have side effects"?
That is answerable. A call has a side effect if there is a detectable
effect in the outside world of the call having been made, i.e., there is
a detectable difference between the effects on the execution environment
of a run of the program and a run of a derived program that is equal to
the original, except that this one call did not take place.
Something along those lines, at least.
If the implementation optimizes a call away, then it doesn't have
side effects.
Which definition of "side effect" are you using here?
Unless the standard requires that call to have some
specific side effects, how exactly is the implementor supposed to know
that the call *should have* some side effects, according to you?
He couldn't, and doesn't have to. What is important is that he knows
from the standard that the call *may* have a side effect.
Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the standard to justify this. I think that is bad.
What do you mean by "ignore the side effects"? If he optimizes fopen()
away, there are no side effects left to ignore. Do you mean he can
choose to ignore *his own promise* that fopen() always modifies file
attributes? And that the current wording of the C standard can somehow
help him justify breaking the promise? I don't think that would make a
lot of sense. Just because the C standard doesn't require that
implementors make that promise in the first place, that's no
justification to make it but then break it.
The C standard makes no provisions for "external" promises as it is.
The standard tries quite hard to provide a situation where compliancy of
an implementation can be judged based on the text of the standard alone,
i.e., it is (or attempts to be) self-contained.
I would argue that this fails (where else) with its handling of the
concept of side effects. These cannot be properly defined without
references to "outside the C box", I think; so then you're left with a
number of options. My preference would be to be "intentionally vague"
rather than an (IMHO) misguided attempt to provide a definition.
Of course I've said the same thing in different words a dozen times now.
Please note that I'm perfectly happy to accept that some things are
defined outside the C scope (e.g. in POSIX), but the C standard should
write a couple of lines about that and its relation to such things,
that's all I ask.
I agree with you 100% on this, but I don't find a reference to the
possibility of externally defined by an entity outside of the c
standard, in the c standard.
Sorry, you lost me here. The possibility of what?
I was writing gibberish there, I'm sorry. What I intended to say was:
"I don't find a reference to the possibility of applicable external
definitions by an entity outside of the c standard, in the c standard."
If running the unoptimized code of fopen() had a side effect of
causing a disk drive to move its head and read some data, do you
believe that the C standard should forbid optimizing that side effect
away, too? Should the C standard forbid filesystems to cache data?
No. You are hitting on precisely the reason why it is so hard to define
"side effects" in the way that one would like. But you and I have an
intuitive idea. I'd prefer a sound definition, but on the other hand I
prefer a somewhat vague notion over a faulty definition.
I cannot offer a wording, but that doesn't mean that people more clever than I am couldn't think of one.
No, but I think you'll have a hard time trying to convince them that
they need to.
That's true :-)
IMHO, the current wording is not ok.
Yeah, I've heard you...
Well, that's something.
Well excuse me, but then you haven't read very well. The reason is thatit is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation may
optimize away an fopen(), even if the plaform has last-touch attributes or something similar.
What's a "platform"?
I presume your question is designed to convey the idea that the C
standard doesn't have the notion of a platform, as currently written?
That explains the difficulties with defining side effects, then.
How can you know that it has last-touch attributes if not all calls to
fopen() are guaranteed to change the attributes?
If the implementation doesn't claim that every successful call to
fopen() modifies file attributes, why is the optimization a bad thing?
I agree with you that it isn't.
>No, POSIX has no authority to change the C standard's definition of>"modifying a file". But POSIX can, and does, add its own requirements to>the semantics of fopen(). In particular, this is what POSIX says about how>fopen() modifies the POSIX file attributes:
>
>If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, [...]
>If mode is w, wb, w+, wb+, or w+b, [...]
Hmmm, I was looking for fopen("somefile", "rb").... No mention of
that?
Funny, isn't it? It seems that POSIX doesn't mind if a compiler
optimizes your fopen() call away, either...
That's funny, indeed. What has POSIX to say of the access timestamp?
Best regards,
Sidney
Keith Thompson wrote: Suppose I have two C programs, Foo and Bar. Foo opens an existing
file and reads some data from it. Bar opens the same file and updates
it. Foo then seeks and re-reads the data (that would be identical to
the initial data if Bar hadn't intervened), and gets something
different from what it saw the first time. Is the implementation
non-conforming, or are the programs just acting outside the scope of
the standard? Does the standard forbid this behavior or does it
merely ignore it?
The implementation is not nonconforming on that account.
There *is* no "second program" in the model covered by the
C standard.
CBFalconer wrote: The case involving seeks is neatly covered by the lack of
insistence that seeks work. All the other cases are covered by
the fact that almost any OS can provide exclusive access to any
given file.
But we don't require that the implementation ensure exclusive access.
In <40***************@null.net> "Douglas A. Gwyn" <DA****@null.net> writes: Keith Thompson wrote: Suppose I have two C programs, Foo and Bar. Foo opens an existing
file and reads some data from it. Bar opens the same file and updates
it. Foo then seeks and re-reads the data (that would be identical to
the initial data if Bar hadn't intervened), and gets something
different from what it saw the first time. Is the implementation
non-conforming, or are the programs just acting outside the scope of
the standard? Does the standard forbid this behavior or does it
merely ignore it?
The implementation is not nonconforming on that account.
There *is* no "second program" in the model covered by the
C standard.
Which means that, a conforming C implementation must behave *as if* there
is no second program, hence the semantics of streams.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>... James Kuyper wrote: Sidney Cadot <si****@jigsaw.nl> wrote in message news:<bv**********@news.tudelft.nl>...
Wojtek Lerch wrote:
...
On an implementation that does have file attributes, it's
up to the implementation to define how fopen() affects them, and to make
sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that.
It's not a requirement of the standard; it's outside the scope of the
standard. It's simply a matter of proper assignment of responsibility.
That's fine by me. In the same vein, I think the standard has no
business defining side effects by enumeration (including file
modification, and excluding reading).
...
Sure, and he will in practice. My point is that the implementor may
choose to ignore the side effects, and can now point to the standard to
justify this. I think that is bad.
The implementor can also point to the standard and say "it doesn't say
I can't kill you - therefore, I can kill you". Is that problem within
the scope of the standard, or is it more properly a matter for the
legal code to address?
I think your analogy is faulty. As far as C is concerned, the standard
/is/ the law. In this law, an attempt is made to define side effects
that is (when read literally) is incomplete. That's all there is to it,
as far as I am concerned.
No, the C standard is not all of the law that applies to a C program.
If you use a C program to embezzle money, the C standard isn't the
relevant law you've broken. If you've written a C compiler that
secretly steals the user's credit card information, it isn't the C
standand that says you've done something wrong. And if an
implementation promises that file attributes will be updated by
successfull calls to fopen(), then it isn't the C standard that is
violated if that implementation optimizes away the fopen() calls. It's
that implementation's own promises that are being broken.
Dan Pop wrote: Which means that, a conforming C implementation must behave *as if* there
is no second program, hence the semantics of streams.
No.
James Kuyper wrote: No, the C standard is not all of the law that applies to a C program.
If you use a C program to embezzle money, the C standard isn't the
relevant law you've broken. If you've written a C compiler that
secretly steals the user's credit card information, it isn't the C
standand that says you've done something wrong. And if an
implementation promises that file attributes will be updated by
successfull calls to fopen(), then it isn't the C standard that is
violated if that implementation optimizes away the fopen() calls. It's
that implementation's own promises that are being broken.
If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
--
pete
Sidney Cadot wrote: Wojtek Lerch wrote: Sidney Cadot <si****@jigsaw.nl> wrote in message
news:<bv**********@news.tudelft.nl>...
....>>On an implementation that does have file attributes, it's
>>up to the implementation to define how fopen() affects them, and
to make sure that it indeed affects them that way.
After the "and": I'd like to see a standard quote supporting that. There is none. The C standard doesn't care. That's the point. Is it
really that difficult?
Not at all. It's just that I would have appreciated a disclaimer stating
something like this:
"The execution environment may impose semantics / side effects in
addition to (but not contradicting) the semantics and side effects as
defined in this standard, for the following I/O related functions: ..."
Is that so much to ask?
The standard has a tendency to avoid saying things that are obvious.
Implementations may do whatever they want, as long as they meet all the
requirements defined in the standard. In particular, implementations
are free to give promises to their users that go beyond what the C
standard requires. If a compiler is sold in a box that claims to
contain 97% recycled paper but in reality only contains 95%, isn't it
quite obvious that that little lie doesn't affect the compiler's
conformance to the C standard?
....Yes, but it *may*. My point is that the standard should explicitly
forbid this for calls that have side effects (in the normal, not
c-standard sense).
Sorry, but what exactly do you mean by "calls that have side effects"?
That is answerable. A call has a side effect if there is a detectable
effect in the outside world of the call having been made, i.e., there is
a detectable difference between the effects on the execution environment
of a run of the program and a run of a derived program that is equal to
the original, except that this one call did not take place.
That's a circular definition. If an implementation optimizes the call
away, there's no detectable difference, and therefore it was OK to
optimize it away.
On the other hand, if another implementation doesn't optimize it away,
the derived program takes up less space in the execution environment --
isn't that a detectable difference?
If the implementation optimizes a call away, then it doesn't have
side effects.
Which definition of "side effect" are you using here?
Any definition you can think of. Since the call has been optimized
away, it can't have any effects whatsoever.
Unless the standard requires that call to have some
specific side effects, how exactly is the implementor supposed to know
that the call *should have* some side effects, according to you?
He couldn't, and doesn't have to. What is important is that he knows
from the standard that the call *may* have a side effect.
You seem to have it backwards. The implementor *implements* the call.
He writes the code. The standard tells him what the call must do and
what it mustn't do, and then he decides how to write code that does all
the required things but doesn't do any of the forbidden things. If the
standard says that the call may but may not have side effects (by
whatever definition of "side effects"), the implementor is free to
choose whether to write code that produces such side effects or code
that can be optimized away.
.... The standard tries quite hard to provide a situation where compliancy of
an implementation can be judged based on the text of the standard alone,
i.e., it is (or attempts to be) self-contained.
Yes. That's the purpose of having a standard.
I would argue that this fails (where else) with its handling of the
concept of side effects. These cannot be properly defined without
references to "outside the C box", I think; so then you're left with a
number of options. My preference would be to be "intentionally vague"
rather than an (IMHO) misguided attempt to provide a definition.
The authors of the standard described a concept they wanted to use in
the text, and decided to name it "side effects". They excluded things
like file attributes from their definition because they didn't want
implementation conformance to the C standard to depend on how
implementations define and handle file attributes.
If you ask whether the C standard requires fopen() to change file
attributes, the answer is a clear no. You might not like that answer;
but it doesn't make much sense to say that instead the standard should
say, "no, except when the implementation says yes and maybe perhaps in
some other circumstances that we can't think of right now". Just like
it wouldn't make sense for the C standard to say that if the box
specifies how much recycled paper it contains, or if the country it's
sold in requires all boxes to contain a certain minimum of recycled
paper, then it must indeed contain at least that much.
Of course I've said the same thing in different words a dozen times now.
Please note that I'm perfectly happy to accept that some things are
defined outside the C scope (e.g. in POSIX), but the C standard should
write a couple of lines about that and its relation to such things,
that's all I ask.
Isn't it good enough that those other things explain their relation to
C?
.... If running the unoptimized code of fopen() had a side effect of
causing a disk drive to move its head and read some data, do you
believe that the C standard should forbid optimizing that side effect
away, too? Should the C standard forbid filesystems to cache data?
No. You are hitting on precisely the reason why it is so hard to define
"side effects" in the way that one would like. But you and I have an
intuitive idea. I'd prefer a sound definition, but on the other hand I
prefer a somewhat vague notion over a faulty definition.
I don't know about you, but my intuitive idea is that it depends on the
context. For instance, when I'm talking about medicine (or even about
POSIX), I don't necessarily try to apply the C standard's definition
when someone says "side effects". But when I'm reading the C standard,
my intuition tells me that I should interpret it exactly the way the
definition says. If the result didn't seem to make sense, then I could
suspect that something were wrong either with the definition or with how
the term is used. But my intuituion tells me that everything is OK.
.... Well excuse me, but then you haven't read very well. The reason is
thatit is currently possible to interpret the standard as Mr. Pop does,
basically, as in: there are circumstances where an implementation may
optimize away an fopen(), even if the plaform has last-touch
attributes or something similar.
What's a "platform"?
I presume your question is designed to convey the idea that the C
standard doesn't have the notion of a platform, as currently written?
Correct. There is not a single occurence of the word "platform" in the
C standard.
.... Funny, isn't it? It seems that POSIX doesn't mind if a compiler
optimizes your fopen() call away, either...
That's funny, indeed. What has POSIX to say of the access timestamp?
"The fgetc() function may mark the st_atime field of the file associated
with stream for update. The st_atime field shall be marked for update by
the first successful execution of fgetc(), fgets(), fgetwc(), fgetws(),
fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream
that returns data not supplied by a prior call to ungetc() or ungetwc()."
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes: James Kuyper wrote:
No, the C standard is not all of the law that applies to a C program.
If you use a C program to embezzle money, the C standard isn't the
relevant law you've broken. If you've written a C compiler that
secretly steals the user's credit card information, it isn't the C
standand that says you've done something wrong. And if an
implementation promises that file attributes will be updated by
successfull calls to fopen(), then it isn't the C standard that is
violated if that implementation optimizes away the fopen() calls. It's
that implementation's own promises that are being broken.
If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
No, your stdin, stdout and stdout must be open, but any attempt to get
input from the first one or send output to the last two ones may fail.
Of course, no fopen() call need succeed. With this implementation, no
C program can produce any output and you can optimise each correct C
program to the equivalent of:
int main() { while(1); }
because the standard doesn't specify how long it takes to a program to
complete its execution.
Your translator will only have to implement translation phases 1 to 4
(only to the extent necessary for properly handling any active #error
directive), after that you can display "hello world" (just in case
the program needed a diagnostic during translation phase 7) and then
generate the code for the optimised version shown above.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <tJ********************@comcast.com> "Douglas A. Gwyn" <DA****@null.net> writes: Dan Pop wrote: Which means that, a conforming C implementation must behave *as if* there
is no second program, hence the semantics of streams.
No.
Chapter and verse.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
pete <pf*****@mindspring.com> wrote in message news:<40***********@mindspring.com>... James Kuyper wrote:
No, the C standard is not all of the law that applies to a C program.
If you use a C program to embezzle money, the C standard isn't the
relevant law you've broken. If you've written a C compiler that
secretly steals the user's credit card information, it isn't the C
standand that says you've done something wrong. And if an
implementation promises that file attributes will be updated by
successfull calls to fopen(), then it isn't the C standard that is
violated if that implementation optimizes away the fopen() calls. It's
that implementation's own promises that are being broken.
If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
Of course, so long as you implement the required semantics of the
program. There's nothing in the standard that prohibits the use of a
wet-ware implementation. As a matter of QoI, you'd want to have some
suitable storage medium, such as paper, to implement files.
pete wrote: If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
No, for a hosted conforming implementation the standard
I/O streams must be open at program startup. However,
they are allowed to fail upon use, provided they report
that in the specified way.
Dan Pop wrote: No, your stdin, stdout and stdout must be open, but any attempt to get
input from the first one or send output to the last two ones may fail.
Of course, no fopen() call need succeed. With this implementation, no
C program can produce any output and you can optimise each correct C
program to the equivalent of:
int main() { while(1); }
because the standard doesn't specify how long it takes to a program to
complete its execution.
A conforming implementation is obliged to perform the
actions specified for the abstract C machine, although
if no side efects are visible in the environment then
there might be no way to *test* whether it conforms.
I think an infinite execution time for a finite-time
program is qualitatively wrong, although again one
could never be sure by external testing.
Note that nonconformance could be detected with
programs that aren't strictly conforming, e.g. writing
to device register or screen pixel.
In <eK********************@comcast.com> "Douglas A. Gwyn" <DA****@null.net> writes: Dan Pop wrote: No, your stdin, stdout and stdout must be open, but any attempt to get
input from the first one or send output to the last two ones may fail.
Of course, no fopen() call need succeed. With this implementation, no
C program can produce any output and you can optimise each correct C
program to the equivalent of:
int main() { while(1); }
because the standard doesn't specify how long it takes to a program to
complete its execution.
A conforming implementation is obliged to perform the
actions specified for the abstract C machine,
Nonsense! In this case, no optimisation would be possible. Fortunately,
the standard proves you wrong:
3 In the abstract machine, all expressions are evaluated as
specified by the semantics. An actual implementation need not
^^^^^^^^
evaluate part of an expression if it can deduce that its value is
not used and that no needed side effects are produced (including
any caused by calling a function or accessing a volatile object).
although
if no side efects are visible in the environment then
there might be no way to *test* whether it conforms.
According to the as-if rule, it conforms.
I think an infinite execution time for a finite-time
program is qualitatively wrong, although again one
could never be sure by external testing.
There is no way to tell whether the program will terminate in 1 million
years or never. And the standard allows a finite-time program to
terminate in 1e6 years.
Note that nonconformance could be detected with
programs that aren't strictly conforming, e.g. writing
to device register or screen pixel.
Nope: such programs invoke undefined behaviour, so they cannot be used
in testing the conformance. Even if this weren't the case, the action
in question could be performed 1e6 years after the program startup...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: Nope: such programs invoke undefined behaviour, so they cannot be used
in testing the conformance. Even if this weren't the case, the action
in question could be performed 1e6 years after the program startup...
Your "logic" leads to the conclusion that conformance
testing is impossible. Fortunately, you are wrong.
Douglas A. Gwyn wrote:
pete wrote: If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
No, for a hosted conforming implementation the standard
I/O streams must be open at program startup. However,
they are allowed to fail upon use, provided they report
that in the specified way.
Suppose that all my streams are open on program startup,
but that they all close upon first attempted access.
You wind up with a program run that has no output
and takes no input.
--
pete
James Kuyper wrote:
pete <pf*****@mindspring.com> wrote in message news:<40***********@mindspring.com>... James Kuyper wrote:
No, the C standard is not all of the law that applies to a C program.
If you use a C program to embezzle money, the C standard isn't the
relevant law you've broken. If you've written a C compiler that
secretly steals the user's credit card information, it isn't the C
standand that says you've done something wrong. And if an
implementation promises that file attributes will be updated by
successfull calls to fopen(), then it isn't the C standard that is
violated if that implementation optimizes away the fopen() calls. It's
that implementation's own promises that are being broken.
If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
Of course, so long as you implement the required semantics of the
program. There's nothing in the standard that prohibits the use of a
wet-ware implementation. As a matter of QoI, you'd want to have some
suitable storage medium, such as paper, to implement files.
If all my streams are closed, then I can't use any files.
--
pete
In <FY********************@comcast.com> "Douglas A. Gwyn" <DA****@null.net> writes: Dan Pop wrote: Nope: such programs invoke undefined behaviour, so they cannot be used
in testing the conformance. Even if this weren't the case, the action
in question could be performed 1e6 years after the program startup...
Your "logic" leads to the conclusion that conformance
testing is impossible. Fortunately, you are wrong.
Nope, that's merely the conclusion you have drawn and, fortunately, you
are wrong.
I was merely pointing out that, for the implementation I was describing,
conformance testing is impossible. I can give you another such example:
a translator that doesn't produce any output for the first 1e6 years.
There is no logical way to infer, from these examples, that conformance
testing is impossible for each and every implementation.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes: Douglas A. Gwyn wrote:
pete wrote: > If I can read a C program
> and pronounce all of the required diagnostics for translation,
> and then when it's time to run the program
> if I claim that all my streams are closed,
> can I be a conforming implementation ?
No, for a hosted conforming implementation the standard
I/O streams must be open at program startup. However,
they are allowed to fail upon use, provided they report
that in the specified way.
Suppose that all my streams are open on program startup,
but that they all close upon first attempted access.
That is not allowed by the semantics of a streams. A stream can only
be closed by an fclose() call or as part of program termination.
You wind up with a program run that has no output
and takes no input.
As I have already explained you, this is perfectly possible even if the
streams are open: no I/O request to an open stream is guaranteed to
succeed.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote:
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Douglas A. Gwyn wrote:
pete wrote:
> If I can read a C program
> and pronounce all of the required diagnostics for translation,
> and then when it's time to run the program
> if I claim that all my streams are closed,
> can I be a conforming implementation ?
No, for a hosted conforming implementation the standard
I/O streams must be open at program startup. However,
they are allowed to fail upon use, provided they report
that in the specified way.
Suppose that all my streams are open on program startup,
but that they all close upon first attempted access.
That is not allowed by the semantics of a streams. A stream can only
be closed by an fclose() call or as part of program termination.
You wind up with a program run that has no output
and takes no input.
As I have already explained you,
this is perfectly possible even if the
streams are open: no I/O request to an open stream is guaranteed to
succeed.
I had confused stream failure with closure.
That there is no requirement that a conforming implementation
must deal with input and output files for a running program,
is what I was interested in.
I think that a running program must return a status to the
operating system on termination, if the system expects one,
but I don't think that it has to do anything else.
--
pete
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes: I think that a running program must return a status to the
operating system on termination, if the system expects one,
And even this may happen after an arbitrarily long amount of time: the
standard doesn't place any upper limit on the running time of the
following program:
int main() { return 0; }
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Douglas A. Gwyn" <DA****@null.net> wrote in message news:<FY********************@comcast.com>... Dan Pop wrote: Nope: such programs invoke undefined behaviour, so they cannot be used
in testing the conformance. Even if this weren't the case, the action
in question could be performed 1e6 years after the program startup...
Your "logic" leads to the conclusion that conformance
testing is impossible. Fortunately, you are wrong.
Testing implementation conformance by reasonable measures of
conformance is quite feasible. Testing conformance to according to the
C standard's measures of conformance is much more difficult, because
it gives implementors too many "outs".
pete <pf*****@mindspring.com> wrote in message news:<40***********@mindspring.com>... James Kuyper wrote:
pete <pf*****@mindspring.com> wrote in message news:<40***********@mindspring.com>... James Kuyper wrote:
> No, the C standard is not all of the law that applies to a C program.
> If you use a C program to embezzle money, the C standard isn't the
> relevant law you've broken. If you've written a C compiler that
> secretly steals the user's credit card information, it isn't the C
> standand that says you've done something wrong. And if an
> implementation promises that file attributes will be updated by
> successfull calls to fopen(), then it isn't the C standard that is
> violated if that implementation optimizes away the fopen() calls. It's
> that implementation's own promises that are being broken.
If I can read a C program
and pronounce all of the required diagnostics for translation,
and then when it's time to run the program
if I claim that all my streams are closed,
can I be a conforming implementation ?
Of course, so long as you implement the required semantics of the
program. There's nothing in the standard that prohibits the use of a
wet-ware implementation. As a matter of QoI, you'd want to have some
suitable storage medium, such as paper, to implement files.
If all my streams are closed, then I can't use any files.
Streams aren't closed or opened, files are opened. Opening a file
associates it with a stream (7.19.3p1).
My best guess is that you actually mean something that I would
describe differently: a conforming implementation can have every
single I/O function call fail, as long as it uses the prescribed
methods of reporting that failure. Hardware problems can happen any
time you run the program; that doesn't make it non-conforming.
I just realized that I have no idea what the connection is between
this hypothetical wet-ware implementation of C, and the original
question about file attribute setting. Would you care to explain the
connection? If a wet-ware implementation of C promises that successful
fopen() calls will result in the setting of appropriate file
attributes, and then "optimizes" the fopen() calls away, so that it
doesn't actually happen, then it's the wet-ware implementation's own
promises that are being broken. It's not anything that is, or should
be, in scope for the C standard. That's exactly the same thing that
can be said about a more conventional implementation of C.
Whether the files all start out closed is irrelevant. Whether the
files can be successfully opened is a different issue, but also
irrelevant. What happens if they are successfully opened is relevant,
but still not in-scope for the C standard.
James Kuyper wrote: I just realized that I have no idea what the connection is between
this hypothetical wet-ware implementation of C, and the original
question about file attribute setting.
The standard describes a conforming implementation
in terms of it's behavior during the translation and
execution of a C program.
I had confused stream closing, with any situation
which might cause a return value of EOF.
But what I was getting at, was what Dan Pop is saying
in other strands of this thread, that because streams are unreliable,
a conforming implementation need only
be able to produce the correct diagnostics during translation.
A conforming implementation need not produce any output
nor accept any input during the execution of a program.
--
pete
Douglas A. Gwyn wrote:
Dan Pop wrote: Nope: such programs invoke undefined behaviour,
so they cannot be used in testing the conformance.
Even if this weren't the case, the action
in question could be performed 1e6 years after
the program startup...
Your "logic" leads to the conclusion that conformance
testing is impossible. Fortunately, you are wrong.
I believe that the claim, "Excedes ANSI Specifications",
is already in use. I always interpreted it to mean that the
compiler did not self destruct after translating one program.
And now if I may change change the topic to some old business:
Is it legitimate for a function like puts,
to return at the first sign of EOF, like this:
int puts(const char *s)
{
while (*s != '\0') {
if (putchar(*s) == EOF) {
return EOF;
}
++s;
}
return putchar('\n');
}
or must it keep hammering away, regardless of EOF, like this:
int puts(const char *s)
{
int eof = 0;
while (*s != '\0') {
if (putchar(*s) == EOF) {
eof = 1;
}
++s;
}
return putchar('\n') == EOF || eof != 0 ? EOF : 1;
}
?
--
pete
pete wrote:
.... snip ...
And now if I may change change the topic to some old business:
Is it legitimate for a function like puts,
to return at the first sign of EOF, like this:
int puts(const char *s)
{
while (*s != '\0') {
if (putchar(*s) == EOF) {
return EOF;
}
++s;
}
return putchar('\n');
}
or must it keep hammering away, regardless of EOF, like this:
int puts(const char *s)
{
int eof = 0;
while (*s != '\0') {
if (putchar(*s) == EOF) {
eof = 1;
}
++s;
}
return putchar('\n') == EOF || eof != 0 ? EOF : 1;
}
I would recommend the immediate return. Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Tristan Miller wrote: Greetings.
In article <bu*********@news.tudelft.nl>, Sidney Cadot wrote:
Consider two programs:
/*** a.c ***/
#include <stdio.h>
int main(void)
{
fopen("somefile","rb");
return 0;
}
/*** b.c ***/
in main(void)
{
return 0;
}
Would it be legal for a compiler (through optimization), to emit the
same code for program a.c and b.c ?
I'd welcome a reference from the standard.
I don't know what the standard says, but from an implementation point of
view it might make sense not to optimize the fopen() away. Many file
systems maintain a "last accessed" timestamp for files; therefore, the
seemingly useless fopen() does indeed modify the environment.
Well when I write a program, I expect the compiler to transpose what I
asked him to do, if it could optimize his transcription to make his
internal stuff easier or to run things faster, thats not my concern, as
in ur example its none of the compilers business to predict from what I
am expecting from it.
Well let me take a completely meaningless example, because there are lot
of good ways to do the same.
Suppose I run the program with the above fopen variant:
assuming that I run it on a unix flavored OS per example:
while true;do ./fopen_variant;done
On the other hand I would like to check how many current processes has a
descriptor assciated to the "somefile" using lsof for example.I may not
have the same results, if the as-if rule is applied here!!
I shall say that the as-if rule should be applied only to those vars or
routines that deals strictly with internals of the same program. For
example routines that deals with shared memory could not be involved!!
regards,
magesh
Regards,
Tristan
Barry Margolin wrote:
(snip regarding side effects of fopen()) But it may only be updated if you actually read something from the file;
the act of opening the file in read mode might not update it (consider a
file on an NFS server -- there's nothing in NFS that corresponds to
open() or close(), the server only sees the directory lookup and the
read/write operations).
There is an additional effect with NFS that I believe is system
dependent, and that is whether the last access time is updated
from the client clock or the server clock.
Of course, the C standard doesn't say anything about that, either.
-- glen
pete wrote: A conforming implementation need not produce any output
nor accept any input during the execution of a program.
Strictly speaking, it needs to make the attempt or else
it hasn't implemented the semantics as specified. But
so much of file behavior is environment-dependent that
sanity in that department becomes more a "quality of
implementation" issue; i.e., the marketplace decides
whether an implementation can get away with constant
I/O failure. Odds are that no hosted implementation
would succeed without being able to perform I/O using
the most common kinds of file on a platform. There are
even implementations of C for embedded system that
manage to support file I/O one way or another (e.g.,
over the debugger console port).
CBFalconer wrote:
pete wrote:
Is it legitimate for a function like puts,
to return at the first sign of EOF
or must it keep hammering away, regardless of EOF
I would recommend the immediate return. Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.
Thank you.
--
pete
"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com... pete wrote: ... snip ...
And now if I may change change the topic to some old business:
Is it legitimate for a function like puts,
to return at the first sign of EOF, like this:
int puts(const char *s)
{
while (*s != '\0') {
if (putchar(*s) == EOF) {
return EOF;
}
++s;
}
return putchar('\n');
}
or must it keep hammering away, regardless of EOF, like this:
int puts(const char *s)
{
int eof = 0;
while (*s != '\0') {
if (putchar(*s) == EOF) {
eof = 1;
}
++s;
}
return putchar('\n') == EOF || eof != 0 ? EOF : 1;
}
I would recommend the immediate return.
So would I.
Once the EOF has been
received something has gone wrong,
[Assuming UCHAR_MAX <= INT_MAX.]
and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.
What 'error status' will be disturbed? Neither puts nor putchar can reset
the end-of-file or error indicator.
I'd argue the early return purely on the basis that that puts should
(IMHO)return EOF immediately an error is reported by fputc.
--
Peter
Peter Nilsson wrote: "CBFalconer" <cb********@yahoo.com> wrote in message
... snip ...
Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.
What 'error status' will be disturbed? Neither puts nor putchar
can reset the end-of-file or error indicator.
But a subsequent error may be the result of the initial error.
There are no specifications about this AFAIK, and it is up to the
i/o system designer.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote:
Peter Nilsson wrote: "CBFalconer" <cb********@yahoo.com> wrote in message
... snip ...
Once the EOF has been
received something has gone wrong, and the string will not be
properly output. Any further 'hammering' may disturb the error
status, which in turn will prevent proper diagnostics.
What 'error status' will be disturbed? Neither puts nor putchar
can reset the end-of-file or error indicator.
But a subsequent error may be the result of the initial error.
There are no specifications about this AFAIK, and it is up to the
i/o system designer.
There's a scene on The Simpsons where Bart joins the
Junior Campers and faints. Ned tells one of the kids to give
Bart mouth to mouth. At first contact, Bart wakes up screaming
and the kid says "Should I keep doing it?"
Stopping makes sense to me, but I don't see in the standard
what implies that the puts function can stop
before it gets to the end of the string.
However, if returning at the first hint of EOF, were the wrong thing
to do, I'm sure somebody else would have said something by now.
--
pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ville Vainio |
last post by:
I don't know if you have seen this before, but here goes:
http://text.userlinux.com/white_paper.html
There is a jab at Python, though, mentioning that Ruby is more
"refined".
--
Ville...
|
by: Marco Bubke |
last post by:
Hi
I have read some mail on the dev mailing list about PEP 318 and find the new
Syntax really ugly.
def foo(x, y): pass
I call this foo(1, 2), this isn't really intuitive to me!
Also I...
|
by: Jase |
last post by:
For some reason all of a sudden "£" signs are displaying as "?" when the
field is displayed.
The display code is:
<%=rs.Fields("WagesText")%>
This was working fine before, so I have no idea...
|
by: Curious Angel |
last post by:
I have a resume in PDF format and I want anyone who LEFT-OR-RIGHT clicks the link to
force the file to be saved, and in any event _not_ opened.
Since the PDF will be in his cache in any event, I...
|
by: Daniel |
last post by:
how to make sure a xsl document has valid xsl syntax? i tried loading it
into an xml document but that doesnt show syntax errors inside attributes
such as "foo/bar" vs "bar\foo"
|
by: Petr Jakes |
last post by:
Hi,
I am trying to set-up communication to the coin change-giver from my
Linux box using the Python code. The change giver uses MDB (Multi Drop
Bus) serial protocol to communicate with the...
|
by: Paminu |
last post by:
In math this expression:
(a < b) && (b < c)
would be described as:
a < b < c
But why is it that in C these two expressions evaluate to something
different for the same values of a, b and...
|
by: ZSP747 |
last post by:
Now,I prepare to write a English-Chinese dictionary.
So I want find a function or library can convert the words from one
form to another,such as "boys"->"boy","became->become","went"->"go"....
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
