By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,978 Members | 1,831 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,978 IT Pros & Developers. It's quick & easy.

Why is stdprn not defined under Windows?

P: n/a
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?
Nov 14 '05 #1
Share this Question
Share on Google+
54 Replies


P: n/a
Sathyaish wrote:
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined.
There is no pre-defined stream named 'stdprn' in C. You might be able
to do what you want by opening a stream with the name your platform uses
for the printer. That might be "prn". For example, this works on my
Windows box:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *prn;
if (!(prn = fopen("prn", "wb"))) {
perror("Could not open \"prn\" for output");
exit(EXIT_FAILURE);
}
fprintf(prn, "This is a simple test.\n");
fclose(prn);
return 0;
}
Why is
that?
Because there *is no such thing as stdprn* defined in C.
Is it because of Windows, I am guessing?


If so, Windows got something right.
Nov 14 '05 #2

P: n/a
Sathyaish wrote:
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?


As it's not a part of the C language, why are you asking here?

--ag

--
Artie Gold -- Austin, Texas

"If you don't think it matters, you're not paying attention."
Nov 14 '05 #3

P: n/a
>I am trying to print to the printer.

There is no standard way to do that in standard C, unless stdout is
connected to the printer.
I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
There is no stdprn in standard C.
that? Is it because of Windows, I am guessing? Do I have to use only
There is no stdprn in standard C, regardless of platform.
"stdprn" is a name reserved for the programmer. Header files
like <stdio.h> should not define it.
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?


Make up your mind: are you printing to a printer or to a window?
Or does your printer itself have windows? Also remember that there
is no guarantee that a computer has a printer. Or that it has only
one printer.

Many applications that want to print something put it in a file and
then either use system() with a platform-specific command to print
it, or let something else do it after the program has finished.

Some applications open a system-specific device (e.g. "PRN:" or
"/dev/lpt0") and output directly to it as though it were a file.
There is no guarantee that an application gets to talk to a "live"
printer rather than going through a spooler.

Gordon L. Burditt
Nov 14 '05 #4

P: n/a
Sathyaish wrote:
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?


I don't do Windows so I can't answer any of your questions about them.
Try one of the many Windows specific newsgroups.

In UNIX, a printer is just another file
that you can open for writing if you have the correct permissions.
Unlike terminals, printers are usually shared.
This can cause problems if two or more applications
are trying to write to the same printer at the same time
so you may need some kind of monitor to mange requests
and queues for print jobs.
Nov 14 '05 #5

P: n/a
On 5 Oct 2004 17:41:29 -0700, in comp.lang.c , Vi****************@yahoo.com
(Sathyaish) wrote:
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that?
Because there's no such thing as a printer. Seriously.
Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?


The ability to print is totally system specific, and you should reasonably
expect to have to use system-specific functionality to do it. You'd need to
ask in a Windows group for how to do that tho.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #6

P: n/a
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.

--
pete
Nov 14 '05 #7

P: n/a
In <7b**************************@posting.google.com > Vi****************@yahoo.com (Sathyaish) writes:
I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that?


It is the implementation's way to suggest that you should "talk" to the
printer using the Windows printing services and not <stdio.h> streams.
Take the hint.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #8

P: n/a
pete <pf*****@mindspring.com> writes:
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, [...]
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton
Nov 14 '05 #9

P: n/a
On Wed, 06 Oct 2004 12:58:18 -0700, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote:
pete <pf*****@mindspring.com> writes:
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,


sort-of depends how you choose to define "file".

File (n): end point of a C stream.

:-)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #10

P: n/a
Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:
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.

N869
7.19.3 Files
[#1] 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. Creating an existing file causes its
former contents to be discarded, if necessary. If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), ...

--
pete
Nov 14 '05 #11

P: n/a
On Thu, 07 Oct 2004 04:48:58 GMT, pete <pf*****@mindspring.com> wrote:
Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:
> 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.

N869
7.19.3 Files
[#1] 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. Creating an existing file causes its
former contents to be discarded, if necessary. If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), ...


That says a file *may be* a physical device. It does not say a
physical device *is* a file.

Some OS's, notably Unix, treat devices as files. Some don't.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #12

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:
> 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.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #13

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:

> 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?

--
pete
Nov 14 '05 #14

P: n/a
"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

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?


I wouldn't say so. I'd say they are devices (to which
standard streams are attached).

-Mike
Nov 14 '05 #15

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
>Ben Pfaff wrote:
>>
>> pete <pf*****@mindspring.com> writes:
>>
>> > 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.

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*?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #16

P: n/a
Da*****@cern.ch (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.

Presumably a remove() operation on an external file that is a physical
device would fail (though it could conceivably unplug the device from
the system if the implementer is sufficiently perverse). Similarly,
there's no reason to expect that closing and re-opening a physical
device will let you re-read the same input. You can't even assume
that for a disk file, since some external entity (such as another
process) might have modified the file in the meantime.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #17

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

>Ben Pfaff wrote:
>>
>> pete <pf*****@mindspring.com> writes:
>>
>> > 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.

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*?


Because disk files are substantially different from files
which are physical devices.
What kind of physical device do you think the standard
is refering to, when it says that a file may be a physical device?

This sentence:
N869
7.19.3 Files
[#1] If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), then a file position indicator
associated with the stream is positioned at the start
(character number zero) of the file, unless the file is
opened with append mode in which case it is implementation-
defined whether the file position indicator is initially
positioned at the beginning or the end of the file.

doesn't make any sense, unless a disk file is one kind of file,
and a terminal is another kind of file.

--
pete
Nov 14 '05 #18

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Presumably a remove() operation on an external file that is a physical
device would fail (though it could conceivably unplug the device from
the system if the implementer is sufficiently perverse).


I don't think that "unplugging the device" is necessarily "perverse". I
have a USB device that reads memory cards. I can plug in my camera
memory stick and copy files from it. When I want to remove the stick, I
"unplug or eject" the media. If there is no memory stick in the device
and I click "unplug or eject", it just shuts off the SmartDisk device
(the LED goes off and the icon is removed from the taskbar).

--
Mabden
Nov 14 '05 #19

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Presumably a remove() operation on an external file that is a physical
device would fail (though it could conceivably unplug the device from
the system if the implementer is sufficiently perverse).


I don't think that "unplugging the device" is necessarily "perverse". I
have a USB device that reads memory cards. I can plug in my camera
memory stick and copy files from it. When I want to remove the stick, I
"unplug or eject" the media. If there is no memory stick in the device
and I click "unplug or eject", it just shuts off the SmartDisk device
(the LED goes off and the icon is removed from the taskbar).


Sure, but the question is whether a call to remove() should do this.
I would find such behavior odd, but it would be perfectly legal as far
as the standard is concerned.

<OT>On a Unix-like system, remove() would be more likely to delete the
entry in /dev rather than doing anything to the physical device, but
only if the caller has appropriate privileges.</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #20

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #21

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

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


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #22

P: n/a
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:

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


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #23

P: n/a
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
Nov 14 '05 #24

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

>Ben Pfaff wrote:
>>
>> pete <pf*****@mindspring.com> writes:
>>
>> > 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.

--
pete
Nov 14 '05 #25

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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. 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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #26

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #27

P: n/a
>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
Nov 14 '05 #28

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #29

P: n/a
Dan Pop wrote:
pete <pf*****@mindspring.com> writes:
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?


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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #30

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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"

/* 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
Nov 14 '05 #31

P: n/a
Dan Pop wrote:

In <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:

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.


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.

--
pete
Nov 14 '05 #32

P: n/a
In <41***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Files provide the fundamental communication path between the
program and the outside world.


You're confusing files and streams.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #33

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
>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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #34

P: n/a
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
Dan Pop wrote:

In <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> writes:
>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.


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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #35

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #36

P: n/a
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
Files provide the fundamental communication path between the
program and the outside world.


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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #37

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes: [...] 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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #38

P: n/a
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
Nov 14 '05 #39

P: n/a
Dan Pop wrote:
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".

--
pete
Nov 14 '05 #40

P: n/a
pete wrote:
Dan Pop wrote:
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".


Any resemblence between Dan and Orson Welles is purely
coincidental.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #41

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #42

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.
Consider a hard disk.


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

--
pete
Nov 14 '05 #43

P: n/a
pete wrote:

Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.

Consider a hard disk.


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
Nov 14 '05 #44

P: n/a
pete wrote:

pete wrote:

Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:

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

Consider a hard disk.


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.


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
Nov 14 '05 #45

P: n/a
pete wrote:

pete wrote:

pete wrote:

Dan Pop wrote:
>
> In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
>
> >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.

> Consider a hard disk.

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.


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.

--
pete
Nov 14 '05 #46

P: n/a
On Fri, 15 Oct 2004 02:52:33 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:
Dan Pop wrote:
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).
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #47

P: n/a
Dan Pop wrote:

In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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?


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
Nov 14 '05 #48

P: n/a
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.

--
pete
Nov 14 '05 #49

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <41***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #50

54 Replies

This discussion thread is closed

Replies have been disabled for this discussion.