Why is stdprn not defined under Windows?

[CBFalconer]

Sometimes, and this is one of those times, when you mention Mark
McIntyre in a post, I think of the opening scene in Citizen Kane.
Kane is old and in his death bed in his mansion. As he dies, he
drops a snow globe which crashes on the floor, and somebody
overhears his last word, "Rosebud". The rest of the movie is about
some guy trying to find out what "Rosebud" means and he never does.
Except, instead of Kane it's you, and instead of "Rosebud" it's
"McIntyre".

Any resemblence between Dan and Orson Welles is purely
coincidental.

 

[Dan Pop]

Could you point me to the definition of "file" in 7.19? If the word
appears in italics anywhere, I missed it.

The word "file" does not appear in italics (in my opinion it should),
but the standard makes several statements about files.

[...]

It means that the standard refers to physical devices as files to
simplify the wording.

It means that the standard refers to physical devices as files.
That's all.

This doesn't make physical devices files, though. Not even in the
context of the C standard.

Yes it does. Why do you insist on imposing a system-specific meaning
of the word "file", when the standard use the term in a perfectly
consistent manner that does not depend on how the "file" is
implemented?

Because there is wording in the standard clearly assuming file semantics,
and I have already posted samples. Physical devices do not necessarily
satisfy these semantics, so it makes no sense to consider them files,
despite what the standard says.

The *correct* way of looking at it is that fopen and friends provide
a file-like interface to (physical) devices. However, the full semantics
of the streams, as described by the C standard, apply *only* when they
are connected to files.

This is way it makes no sense to mix up files and devices together, even
if the interface is the same.

Dan

 

[Dan Pop]

I refer to physical devices which are associated with streams
as files to simplify the wording too.
When I say that physical devices such as your watchdog, are files,
I don't mean that they're files the way that you think of files,
I only mean files as in what the standard refers to as files.

Are you sure? How about 7.19.2p2 and 7.19.2p3 ?

Dan

 

[Keith Thompson]

Are you sure? How about 7.19.2p2 and 7.19.2p3 ?

What about them?

For those who don't have a copy of the standard handy:

7.19.2p1:

Input and output, whether to or from physical devices such as
terminals and tape drives, or whether to or from files supported
on structured storage devices, are mapped into logical data
_streams_,
[...]

7.19.2p2:

Data read in from a text stream will necessarily compare equal to
the data that were earlier written out to that stream only if:
[...]

7.19.2p3:

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.
[...]

(Those who do have a copy of the standard can confirm that the parts I
left out aren't directly related to the point.)

I'll use the phrase "disk files" to refer to files supported on
structured storage devices. Assume that "/dev/null" is the name of a
device (not a disk file) that discards all input and produces no
output, and that the device can be accessed by passing the string
"/dev/null" to fopen().

Paragraphs 2 and 3 talk about the behavior of streams, not of files;
they make no distinction between devices and disk files. Since a
stream clearly can be associated either with a device or with a disk
file, paragraphs 2 and 3 seem to be asserting that, for example, data
written to /dev/null can be read back from /dev/null, regardless of
whether /dev/null is a "file" or not.

Dan, I don't see how paragraphs 2 and 3 help your argument.

It also appears that either those paragraphs need to be modified to
allow for special devices, or implementations that support such
special devices are non-conforming. I'll bring that up in comp.std.c
unless someone convinces me that my reasoning is flawed.

 

[pete]

Consider a hard disk.

A hard disk is a structured storage device
which can suppport files.

 

[pete]

A hard disk is a structured storage device
which can suppport files.

When you can access the device by associating a stream with it,
then it's a file. When you associate a stream with a file on the disk,
then in that context the disk is only a structured storage device
supporting a file.

 

[pete]

When you can access the device by associating a stream with it,
then it's a file. When you associate a stream with a file on the disk,
then in that context the disk is only a structured storage device
supporting a file.

While I would say that
anything on the other end of a stream from the computer is a file,
a file is still a file after it is disassociated from a stream.
If a structured storage device can be accessed as a file,
then the device itself becomes one of the files
that is supported on the structured storage device.

 

[pete]

While I would say that
anything on the other end of a stream from the computer is a file,
a file is still a file after it is disassociated from a stream.
If a structured storage device can be accessed as a file,
then the device itself becomes one of the files
that is supported on the structured storage device.

Actually the structured storage device
is not one of the files supported by the structured storage device,
but rather is a file which is a physical device.

 

[Mark McIntyre]

Sometimes, and this is one of those times,
when you mention Mark McIntyre in a post,

oh, is he still mentionig me? Probably being rude again.

(snip highly amusing Citizen Kane reference).

 

[pete]

After explicitly acknowledging that this isn't so in the previous
paragraph, the standard goes on making this simplification, for obvious
reason. No matter how you look at it, a physical device is a physical
device, not a file, even if the execution environment provide a file-like
interface to it.

Consider a hard disk. Is it a file under Linux,
because you can access it
as a file, using a name like "/dev/hda",
but not under Windows, because
there is no corresponding file name you could pass to fopen()?
It's the very same physical device,
it's just that different execution environments
provide different interfaces to it.
AFAICT, the definition of a file is
not implementation-defined, so is the hard disk a file or not?

The answer to the question
"Is this device a file?"
is the same as the answer to
"Can a C program associate a stream with this device?"

If the second question can be answered with a simple "yes",
then so can the first question.
If the answer to the second question is more complicated,
then so is the answer to the first question.

I have construed from the standard's usage of the word file
that a file is anything that a C program can associate with a stream.

 

[pete]

Dan Pop wrote:

Because there is wording in the standard clearly assuming
file semantics, and I have already posted samples.
Physical devices do not necessarily
satisfy these semantics, so it makes no sense to consider them files,
despite what the standard says.

"Does this device have file semantics?"
means the same thing as
"Is this device a file?"

There's a catch-22 there.
If you accept that
a file is anything that a C program can associate with a stream,
then the ability to be associated with a stream by a C program,
fulfills the entire scope of what it means
for a device to have file semantics.

 

[Dan Pop]

Are you sure? How about 7.19.2p2 and 7.19.2p3 ?

What about them?

For those who don't have a copy of the standard handy:

7.19.2p1:

Input and output, whether to or from physical devices such as
terminals and tape drives, or whether to or from files supported
on structured storage devices, are mapped into logical data
_streams_,
[...]

7.19.2p2:

Data read in from a text stream will necessarily compare equal to
the data that were earlier written out to that stream only if:
[...]

7.19.2p3:

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.
[...]

(Those who do have a copy of the standard can confirm that the parts I
left out aren't directly related to the point.)

I'll use the phrase "disk files" to refer to files supported on
structured storage devices. Assume that "/dev/null" is the name of a
device (not a disk file) that discards all input and produces no
output, and that the device can be accessed by passing the string
"/dev/null" to fopen().

Paragraphs 2 and 3 talk about the behavior of streams, not of files;
they make no distinction between devices and disk files. Since a
stream clearly can be associated either with a device or with a disk
file, paragraphs 2 and 3 seem to be asserting that, for example, data
written to /dev/null can be read back from /dev/null, regardless of
whether /dev/null is a "file" or not.

/dev/zero is an even nicer example, because you can write N bytes to
it, rewind the stream and then read N bytes back from it. Unless the
bytes you wrote were all zeroes, the two sets of bytes won't compare
equal.

Dan, I don't see how paragraphs 2 and 3 help your argument.

Try harder. These paragraphs *clearly* show that the C standard uses the
normal semantics for the term "file" and deliberately ignores the
possibility (explicitly admitted) of having device names successfully
passed to fopen().

Therefore, not anything that can be successfully passed to fopen() is a
file, *even* in the context of the C standard.

It also appears that either those paragraphs need to be modified to
allow for special devices, or implementations that support such
special devices are non-conforming.

Most implementations support terminals by associating a name with them:
/dev/tty in Unix, CON: in DOS and Windows. Since terminals don't have
file semantics, all these implementations are non-conforming OR your
interpretation of the standard (anything that can be successfully passed
to fopen is a file) is wrong.

I'll bring that up in comp.std.c
unless someone convinces me that my reasoning is flawed.

Try to rewrite *all* the parts of 7.19 necessary in order to make your
interpretation consistent with the actual text of the standard and you
may realise why the committee preferred to make appeal to the common
sense of the reader when taking the shortcuts it actually did.

Streams provide a uniform interface between the C program and the
execution environment. This doesn't mean that everything that happens to
be at the other end of a stream must belong to a single category and there
is little point in pretending that there is such a category and that its
name is "file". When the standard *apparently* does it, it is to keep the
actual wording as simple as possible.

Dan

 

[Keith Thompson]

/dev/zero is an even nicer example, because you can write N bytes to
it, rewind the stream and then read N bytes back from it. Unless the
bytes you wrote were all zeroes, the two sets of bytes won't compare
equal.
Right.


Try harder. These paragraphs *clearly* show that the C standard uses the
normal semantics for the term "file" and deliberately ignores the
possibility (explicitly admitted) of having device names successfully
passed to fopen().

Paragraphs 2 and 3 don't even use the word "file". Even if, as you
seem to assert, devices and files are disjoint concepts, a "stream"
can be associated with either a file or a device. Paragraphs 2 and 3
apply to both files and devices.

I argue that anything you can open with fopen(), whether it's a file,
a device, or something else, is a "stream". Do you disagree? If so,
why does the standard introduce the term "stream"?

[...]

Try to rewrite *all* the parts of 7.19 necessary in order to make your
interpretation consistent with the actual text of the standard and you
may realise why the committee preferred to make appeal to the common
sense of the reader when taking the shortcuts it actually did.

I'd be happy with any consistent interpretation of all of 7.19. If
there is no such interpretation, that would be a flaw in the standard;
I'm happy to point out such a flaw, but I'm not necessarily going to
take the time to suggest a fix.

 

[Dan Pop]

Paragraphs 2 and 3 don't even use the word "file".

OTOH, if you assert that anything that is at the remote end of a stream
is a file, paragraphs 2 and 3 don't make any sense. They make sense
*only* when the stream is connected to a file (using the normal semantics
of the term and not your silly definition).

Even if, as you
seem to assert, devices and files are disjoint concepts, a "stream"
can be associated with either a file or a device. Paragraphs 2 and 3
apply to both files and devices. ^^^^^^^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the real oversight or shortcut, whatever you want to call it.
Try to fix it in a consistent manner and see how many changes are needed
in the standard.

It is *obvious* to anyone that these paragraphs apply only when the
stream is connected to a file. Therefore, a device cannot be a file.

I argue that anything you can open with fopen(), whether it's a file,
a device, or something else, is a "stream". Do you disagree?

I do. The stream is the interface to that thing, not the thing itself.
Big difference!

If so, why does the standard introduce the term "stream"?

To provide a uniform method of exchanging data between the C program and
the execution environment.

I'd be happy with any consistent interpretation of all of 7.19. If
there is no such interpretation, that would be a flaw in the standard;

It should be obvious, by now, that there is no such interpretation.
OTOH, the intent of 7.19 is perfectly clear to anyone willing to
understand it. We have only a disagreement on a terminology issue that
does not prevent understanding the intent of 7.19.

I'm happy to point out such a flaw, but I'm not necessarily going to
take the time to suggest a fix.

If I were a committee member, I'd say: if you can't provide anything
better, don't bother.

We both know that there are plenty of places in the standard where the
actual intent cannot be unequivocally inferred from the text of the
standard. 7.19 can safely wait until these are fixed.

Dan

 

[pete]

pete wrote:

I have construed from the standard's usage of the word file
that a file is anything that a C program can associate with a stream.

But, according to the latest discussion on comp.std.c, that's not it.

 

[Keith Thompson]

But, according to the latest discussion on comp.std.c, that's not it.

I'm not aware that the discussion in comp.std.c has reached a
conclusion, other than (perhaps) that the standard is inconsistent.

 

[pete]

I'm not aware that the discussion in comp.std.c has reached a
conclusion, other than (perhaps) that the standard is inconsistent.

I tend to weigh Douglas A. Gwyn's opinions heavily.
My understanding was that he disagreed with me.

I am comfortable not knowing what a file is.
I may have misconstrued this as well, but I also learned that
you don't have to know what a file is, to know C.
If you were to ask me what "associate" means,
as in "associate with a stream", I would have to say that
I don't exactly know, but that didn't stop me from using that word
in this thread a few times,
where I genuinely intended it to mean whatever it really means.

If files really were what I wanted to say that they were, then
that would help to simplify my concept of what a C program is.
I think that all of the operations in a translation unit
would then pertain to only five subjects:
objects,
values,
functions,
streams,
and files,
but I can replace "files" with
"files and other things that can associate streams" conceptually OK.