Why is stdprn not defined under Windows?

[Sathyaish]

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?

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

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

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

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

[...]

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.

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.

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

[Dan Pop]

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

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

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

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

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

--
pete

[Keith Thompson]

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

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.

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

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

[pete]

Keith Thompson wrote:

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

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.

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.

--
pete