Why is stdprn not defined under Windows?

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:
[...]

The answer is available in the included text from the standard that is
still visible above: they are physical devices. If they were files,
you could destroy the output you have generated on your monitor with
a remove() function call and reread the user input as many times as you
wanted by closing and reopening the keyboard.

Why do you think the standard *explicitly* talks about two categories of
sources/destinations for I/O operations: physical devices and files
supported on *structured storage devices*?

Whether a device is considered a file is a question about the meaning
of the word "file". The standard doesn't provide an explicit
definition, but it does have wording that clearly implies that a
device can be a file.

In the following, I'll use underscores to denote italics.

C99 7.19.2 p1 says:

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_, whose properties are more uniform than their various
inputs and outputs.

This makes a clear distinction between physical devices and files on
structured storage devices, but it doesn't quite state that physical
devices are not files. The ambiguity is in the interpretation of the
phrase "files supported on structured storage devices"; does it imply
that *all* files are "supported on structured storage devices", or is
it merely talking about the subset of files that are "supported on
structured storage devices"? Since it doesn't refer to physical
devices as files, it's difficult to tell from this passage alone.

But C99 7.19.3 p1 says:

A stream is associated with an external file (which may be a
physical device) by _opening_ a file, which may involve _creating_
a new file.

That seems pretty clear to me.

The purpose of 7.19.3 p1 is to simplify the wording used in the rest of
section 7.19. We'll pretend from now on that I/O happens to files ONLY,
even if we have already acknowledged that this is not the case.

Feel free to believe that /dev/null is a file on Unix systems, but don't
tell it to other people

A couple of years ago I wrote a Linux device driver for a hardware
watchdog (a device that automatically reboots the system if activated and
then left alone for a certain time). A C program could fopen() it, which
would mean activate it, write to it, which would mean reset the watchdog
timer, and fclose it, which would mean deactivate the watchdog. Read
operations would always fail. Think (hard) about the above described
semantics and see how well they match those of files.

Dan

 

[Keith Thompson]

The purpose of 7.19.3 p1 is to simplify the wording used in the rest of
section 7.19. We'll pretend from now on that I/O happens to files ONLY,
even if we have already acknowledged that this is not the case.

Then your argument is with the standard, not with me.

 

[Dan Pop]

Then your argument is with the standard, not with me.

I have no argument with the standard, I merely explained the relationship
between 7.19.2 and 7.19.3.

Dan

 

[pete]

Dan Pop wrote:

A couple of years ago I wrote a Linux device driver for a hardware
watchdog (a device that automatically reboots the system
if activated and then left alone for a certain time).
A C program could fopen() it, which would mean activate it,
write to it, which would mean reset the watchdog
timer, and fclose it, which would mean deactivate the watchdog. Read
operations would always fail. Think (hard) about the above described
semantics and see how well they match those of files.

They match good.

N869
7.19.5.3 The fopen function
[#2] The fopen function opens the file whose name is the
string pointed to by filename, and associates a stream with
it.

 

[pete]

Ben Pfaff wrote:


E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

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

I disagree.
A physical device, such as a terminal, is an example of a file.

Be careful when dealing with semantics issues.
A physical device and a
file are two completely different things. A file is something else
than the physical storage device on which it resides.

Even if the OS provides a file-like interface to a physical device,
the physical device is still not a file.
A terminal is a lot more than the one,
two or three streams that may be
connected to it at program startup.

I'm under the impression, that when standard output
shows up on my PanaSync S70 monitor and that when I enter
standard input on my Lexmark model M keyboard,
that those two devices are files.
They are files, aren't they?

The answer is available in the included text from the standard that is
still visible above: they are physical devices. If they were files,
you could destroy the output you have generated on your monitor with
a remove() function call and reread the user input as many times as
you wanted by closing and reopening the keyboard.

remove() is capable of returning nonzero.
I don't think that there is a filename that you could use
to write code to remove() the file which is associated at startup
with the standard output stream.

What I'm getting from the standard
is that there are two kinds of files:
1 files which are physical devices
2 files which are supported on structured storage devices
and that the two kinds of files are very different.

A terminal would be an example of the first kind
and a disk file would be an example of the second kind.

 

[Dan Pop]

A couple of years ago I wrote a Linux device driver for a hardware
watchdog (a device that automatically reboots the system
if activated and then left alone for a certain time).
A C program could fopen() it, which would mean activate it,
write to it, which would mean reset the watchdog
timer, and fclose it, which would mean deactivate the watchdog. Read
operations would always fail. Think (hard) about the above described
semantics and see how well they match those of files.

They match good.

N869
7.19.5.3 The fopen function
[#2] The fopen function opens the file whose name is the
string pointed to by filename, and associates a stream with
it.

Please engage your brain: there is no connection between the text you
have included from my post and the text you've quoted from the standard.

If you believe that the semantics of /dev/watchdog, as described above,
match those of files, please explain why. Consider the following program:

#include <stdio.h>
#include <time.h>

int main()
{
FILE *fp = fopen("/dev/watchdog", "w");
time_t t = time(NULL);

while (difftime(time(NULL), t) < 600) ;
printf("hello world\n");
return 0;
}

Error checking deliberately omitted for simplicity. The watchdog cannot
be configured to wait for more than 255 seconds before rebooting the
system.

I can't see any undefined behaviour, so, if /dev/watchdog has the
semantics of a file, I would expect this program to display
"hello world\n" after wasting CPU cycles for 10 minutes.

Dan

 

[Dan Pop]

What I'm getting from the standard
is that there are two kinds of files:
1 files which are physical devices
2 files which are supported on structured storage devices
and that the two kinds of files are very different.

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?

Dan

 

[Gordon Burditt]

What I'm getting from the standard

is that there are two kinds of files:
1 files which are physical devices
2 files which are supported on structured storage devices
and that the two kinds of files are very different.

A terminal would be an example of the first kind
and a disk file would be an example of the second kind.

And how would you classify things that don't act like files
on structured storage devices and have no direct physical
reality?

Examples:

- pipes
- sockets (no network hardware required if the other end is on
the same system)
- Pseudo-terminals (ptys)

These don't act like files on structured storage devices (they are
not seekable, for example) but where's the physical hardware?

Gordon L. Burditt

 

[Keith Thompson]

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.

Nope.

Again, 7.19.2p1 says:

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_, whose properties are more uniform than their various
inputs and outputs.

This says that certain entities "supported on structured storage
devices" are files. It does not say that physical devices are not
files. (It arguably implies it, but only weakly. Personally, I think
the wording could stand some improvement.)

7.19.3p1 says:

A stream is associated with an external file (which may be a
physical device) by _opening_ a file, which may involve _creating_
a new file.

There is no statement or implication that this is a simplification.
It's simply a true statement. An external file may be a physical
device. It could hardly be clearer.

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?

We're discussing the meaning of "file" in the context of C.

No, the definition of "file" is not implementation-defined, but the
implementation of stdio certainly is. The question of whether a given
entity is a "file" is a matter of whether the stdio implementation
treats it as one. It's an abstraction.

If I call fopen("/dev/hda", "r"), and the call succeeds, I've opened a
file, specifically the one whose name is the string pointed to by
"/dev/hda". If I can't do that under Windows, then there's no "file"
(in the sense used in the C standard) associated with the hard disk.

 

[CBFalconer]

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?

A file is anything whatsoever that meets the language
specifications for functions that operate on files. This is much
hazier for C than for Pascal, where the characteristics of files
are carefully spelled out, and thus omit some abilities available
(at times) in C files, such as positioning. It is up to the
implementor to create code (in any language) and hardware to
perform such an interface.

Files provide the fundamental communication path between the
program and the outside world.

 

[pete]

A couple of years ago I wrote a Linux device driver for a hardware
watchdog (a device that automatically reboots the system
if activated and then left alone for a certain time).
A C program could fopen() it, which would mean activate it,
write to it, which would mean reset the watchdog
timer, and fclose it, which would mean deactivate the watchdog. Read
operations would always fail. Think (hard) about the above described
semantics and see how well they match those of files.

They match good.

N869
7.19.5.3 The fopen function
[#2] The fopen function opens the file whose name is the
string pointed to by filename, and associates a stream with
it.

Please engage your brain: there is no connection between the text you
have included from my post and the text
you've quoted from the standard.

If you believe that the semantics of /dev/watchdog,
as described above, match those of files, please explain why.

A file, is just what's at the other end of a stream from the computer.

Consider the following program:

#include <stdio.h>
#include <time.h>

int main()
{
FILE *fp = fopen("/dev/watchdog", "w");
time_t t = time(NULL);

while (difftime(time(NULL), t) < 600) ;
printf("hello world\n");
return 0;
}

Error checking deliberately omitted for simplicity.
The watchdog cannot
be configured to wait for more than 255 seconds before rebooting the
system.

I can't see any undefined behaviour,

The omitted error checking, is the whole program.
On my system, new.c prints "!fp"

/* BEGIN new.c */

#include <stdio.h>
#include <time.h>

int main()
{
FILE *fp = fopen("/dev/watchdog", "w");
time_t t = time(NULL);

if (!fp) {
puts("!fp");
} else {
while (difftime(time(NULL), t) < 600) ;
printf("hello world\n");
}
return 0;
}

/* END new.c */

 

[pete]

In <[email protected]>


The purpose of 7.19.3 p1
is to simplify the wording used in the rest of section 7.19.

17.9 is the part of the standard that tells you what a file is,
what a stream is, and how they relate to each other,
so the wording is a big deal.

Being a physical device,
is insufficient for disqualification from being a file.
That's what "may be a physical device" means.

 

[Dan Pop]

Files provide the fundamental communication path between the
program and the outside world.

You're confusing files and streams.

Dan

 

[Dan Pop]

Dan Pop wrote:

A couple of years ago I wrote a Linux device driver for a hardware
watchdog (a device that automatically reboots the system
if activated and then left alone for a certain time).
A C program could fopen() it, which would mean activate it,
write to it, which would mean reset the watchdog
timer, and fclose it, which would mean deactivate the watchdog. Read
operations would always fail. Think (hard) about the above described
semantics and see how well they match those of files.

They match good.

N869
7.19.5.3 The fopen function
[#2] The fopen function opens the file whose name is the
string pointed to by filename, and associates a stream with
it.

Please engage your brain: there is no connection between the text you
have included from my post and the text
you've quoted from the standard.

If you believe that the semantics of /dev/watchdog,
as described above, match those of files, please explain why.

A file, is just what's at the other end of a stream from the computer.

Consider the following program:

#include <stdio.h>
#include <time.h>

int main()
{
FILE *fp = fopen("/dev/watchdog", "w");
time_t t = time(NULL);

while (difftime(time(NULL), t) < 600) ;
printf("hello world\n");
return 0;
}

Error checking deliberately omitted for simplicity.
The watchdog cannot
be configured to wait for more than 255 seconds before rebooting the
system.

I can't see any undefined behaviour,

The omitted error checking, is the whole program.
On my system, new.c prints "!fp"

If you continue to behave like Mark McIntyre, I shall start treating you
as such. It is *obvious* that my example was meant for a system with
the proper watchdog hardware present and where *my* watchdog device
driver is installed. ALL you have proved is that your system doesn't
satisfy these criteria. What the hell makes you think that this is
relevant to my argument?!?

Dan

 

[Dan Pop]

17.9 is the part of the standard that tells you what a file is,
what a stream is, and how they relate to each other,
so the wording is a big deal.

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

Being a physical device,
is insufficient for disqualification from being a file.

Indeed, if the physical device implements the semantics of a file.
Which is seldom the case.

That's what "may be a physical device" means.

It means that the standard refers to physical devices as files to
simplify the wording. It does not make physical devices files.
It is the execution environment that may or may not provide a file-like
interface to a physical device. Even if it does, this doesn't make the
physical device a file, but this concept seems to be beyond your
comprehending capabilities.

Dan

 

[Dan Pop]

No, the definition of "file" is not implementation-defined, but the
implementation of stdio certainly is. The question of whether a given
entity is a "file" is a matter of whether the stdio implementation
treats it as one.

Nope, it's not an stdio implementation issue, it's an execution
environment issue. All stdio can do is pass the string to the execution
environment and see what happens. We're completely outside the scope of
the language or implementation.

It's an abstraction.

It's an abstraction provided by the execution environment. Which doesn't
automatically make a file anything that can be successfully passed to
fopen(), even if the interface to that thing looks like a file.

If I call fopen("/dev/hda", "r"), and the call succeeds, I've opened a
file, specifically the one whose name is the string pointed to by
"/dev/hda". If I can't do that under Windows, then there's no "file"
(in the sense used in the C standard) associated with the hard disk.

How about considering the more interesting cases when
fopen("/dev/hda", "w") succeeds or when fopen("/dev/watchdog", "w")
succeeds? One will corrupt all your genuine files stored on that device
if used, the other will crash your system if unused. The typical
semantics of "file", right?

How about /dev/null and

Data read in from a text stream
will necessarily compare equal to the data that were earlier
written out to that stream only if: the data consist only of
printing characters and the control characters horizontal tab
and new-line; no new-line character is immediately preceded by
space characters; and the last character is a new-line character.
....
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.

Engage your brain and you'll realise that not everything that can be
successfully passed to fopen *is* a file. C streams provide an interface
to both files and devices (which need not be physical devices, they may be
also execution environment devices). The interface is the same, the
semantics are NOT. It is sheer stupidity to call something a file simply
because it is at the other end of a C stream. Even if the C standard
uses this *convention*, to avoid tons of baroque wording.

Dan

 

[CBFalconer]

You're confusing files and streams.

In the C language (and this group) world, yes. Reread the highly
non-ambiguous definition of files for Pascal, as enunciated by
Wirth, and available in the Pascal standard. Unix and C pioneered
the idea of totallaly encapsulating the outside communications, but
their systems just grew.

 

[Keith Thompson]

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.

It does not make physical devices files.

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?

The standard says, in black and white, that a physical device may be a
file. There is no ambiguity in the statement.

 

[pete]

Dan Pop wrote:

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

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.

 

[pete]

McIntyre

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".