Files & dirs: historical reasons?

M

malc

Eric Sosman said:
Kenneth Brody wrote On 12/19/06 09:39,:

You believe wrongly, infidel.

Why? The only relevant place i so far managed to find does not require
them to be macros.

<quote>
7.19.1[#3]
....
stderr
stdin
stdout

which are expressions of type pointer to FILE that point to the FILE
objects associated, respectively, with the standard error, input, and
output streams.
</quote>

The other relevant piece is:

<quote>
7.19.5.4[#2]
....
The primary use of the freopen function is to change the file
associated with a standard text stream (stderr, stdin, or stdout),
as those identifiers need not be modifiable lvalues to which the
value returned by the fopen function may be assigned.
</quote>
 
G

Guest

malc said:
Eric Sosman said:
Kenneth Brody wrote On 12/19/06 09:39,:

You believe wrongly, infidel.

Why? The only relevant place i so far managed to find does not require
them to be macros.

<quote>
7.19.1[#3]
...
stderr
stdin
stdout

which are expressions of type pointer to FILE that point to the FILE
objects associated, respectively, with the standard error, input, and
output streams.
</quote>

<quote>
7.19.1[#3]
The macros are
....
stderr
stdin
stdout

which are expressions of type pointer to FILE that point to the FILE
objects associated, respectively, with the standard error, input, and
output streams.
</quote>
 
E

Eric Sosman

malc said:
Eric Sosman said:
Kenneth Brody wrote On 12/19/06 09:39,:
You believe wrongly, infidel.

Why? The only relevant place i so far managed to find does not require
them to be macros.

<quote>
7.19.1[#3]
...

The first three words you've elided are "The macros are."
stderr
stdin
stdout
[...]

.... and these three identifiers are part of the list -- indeed,
part of the same sentence -- that begins with "The macros are."

Not "The identifiers are."

Not "The keywords are."

Not "The names of the fattest Whos in Whoville are."

... but "The macros are."
 
M

malc

Eric Sosman said:
malc said:
Why? The only relevant place i so far managed to find does not
require them to be macros.
[..snip..]

... and these three identifiers are part of the list -- indeed,
part of the same sentence -- that begins with "The macros are."

Indeed. Thank you for pointing that out.
 
R

Random832

2006-12-26 said:
Useless for modern programs, yes.
But, utterly pointless, no.

The standard specifies such things for compatibility with legacy code.
Probably small amounts of legacy code. But, since it doesn't harm,
maintaining backward compatibility is a good thing.

For stdin, stdout and stderr, requiring that they be macros (instead of
simply allowing it) allow some programs to do things such as:

#include <stdio.h>

#undef stdin
#define stdin my_stdin

This falls under the category of "not legal anyway". And, regardless,
it's ok, in general, to #undef something that's not defined.
 
D

Dave Thompson

Richard Heathfield wrote:
As I've said before, I do consider CMS, CP/M and early MS-DOS -- and
RT-11 -- to have single, fixed directories. OS/360 et seq is more
problematic; it does (at least did) have catalogs which provide the
function of directories and even directory trees, but aren't organized
into separate directories the way we are now used to.
Yeah, the PDP-11 I used with an RT-11 OS had no subdirectories.
All the files were in one place, had to be unique names and limited
to 8 characters (I think). It was a real PITA.
6.3, and drawn from the same 'RAD50' character set used for
object-file symbols: 26 letters -- uppercase only, although most
programs and certainly the 'standard' command parser allowed you to
enter lowercase and upshifted it for you; 10 digits; dollarsign;
underscore; period, which you couldn't actually use in a filename*
because it was the separator; and space (trailing only). (* I don't
recall testing if you could put period in the extension, where the
parse would be unambiguous, and no longer have the opportunity.)

And just to be clear, all the _directory entries_ were in one place,
in the (one-per-volume) directory. The file contents were of course in
different places, in general spread over the volume.

AIR there was a DECUS driver, I think later added to the official
system, which could 'mount' a (single large) file on a (real) disk as
a virtual disk volume, and thus have a (single) directory and files
within that. That provided the effect of nesting, but clumsily, and
without allowing practical recursion/treewalking. (The same, pretty
obvious, concept has been invented in many other places as well.)


- David.Thompson1 at worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,772
Messages
2,569,589
Members
45,100
Latest member
MelodeeFaj
Top