Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8377
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Smaller C |
| Date | 2015-07-15 02:23 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x1sxdtm6yfako5@localhost> (permalink) |
| References | (14 earlier) <op.x1nizmxyyfako5@localhost> <mnuak9$f21$1@dont-email.me> <mo02q5$i3g$1@speranza.aioe.org> <op.x1qtwod5yfako5@localhost> <mo2g2d$53h$1@speranza.aioe.org> |
On Tue, 14 Jul 2015 04:08:43 -0400, James Harris
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
> news:op.x1qtwod5yfako5@localhost...
>> On Mon, 13 Jul 2015 06:10:14 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:
>>> As stdin, stdout and stderr are pointers that it should be possible
>>> to change
>>
>> ...
>>
>>> I don't see how they can be constants, at least in a conforming
>>> implementation.
>>
>> Most C implementations treat them as constants. GCC is non-standard
>> here. GCC argues that the C specification doesn't require static
>> pointers for stdin, stdout, stderr. Apparently, they do this to
>> allow GCC to reassign streams, e.g., pipes.
>
> The C89 draft that I have says: "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."
Yes.
> So you may not be able to say
>
> stdout = open("prog.c", "r");
Why would you want/need to do that though? ...
You can assign stdout's value to a variable of type file pointer
and use that file pointer to write to stdout.
> but you can say
>
> freopen("prog.c", "r", stdout);
Yes. You can attach or redirect stdout to a file with freopen().
>>> I have been looking at freopen() and it is a bit of a weird one. The
>>> signature is
>>>
>>> FILE *freopen(const char *path, const char *mode, FILE *stream);
>>>
>>> The path and the mode are as in the fopen call but note that freopen
>>> has *two* file pointers.
>>
>> It really has only *one* file pointer ...
>>
>> According to H&S, not the C specifications, the return file pointer
>> must be either the passed file pointer 'stream' or NULL for failure.
>> I.e., FILE *stream is passed back as the return FILE * unless it needs
>> to be set to NULL for failure.
>
> OK.
>
>> freopen() fclose's stream, fopen's path/mode, associates path/mode
>> with stream instead of using a new file pointer.
>
> So 'stream' points to the same FILE struct
Yes.
> and it is the FILE struct
> that has somehow been changed rather than the pointer?
What?
Again, why are you insisting that something changes in that struct?
> That would make sense in isolation but it would screw up any other
> FILE pointer which pointed to the same struct.
Why would you have additional file pointers pointing to the same struct?
> If it helps to visualise a FILE struct there is a sample at
>
> [link]
>
> It is as follows.
>
> typedef struct
> {
> short level ;
> short token ;
> short bsize ;
> char fd ;
> unsigned flags ;
> unsigned char hold ;
> unsigned char *buffer ;
> unsigned char * curp ;
> unsigned istemp;
> }FILE ;
...
> If the pointer is to be unchanged then the FILE struct that it points to
> has to change - perhaps by changing the fd field, above, and others -
Why? ...
1) The 'fd' was 0 for stdin before the call to freopen(). Still is.
2) The filename and file mode flags aren't stored in the struct.
What changed?
> and, as I was saying, there could be another pointer to the same struct
> which would also find that its associated file had changed.
How?
How could there be two file pointers to the same file or standard
I/O stream (stdin, stdout, stderr)?
You would have multiple writers to the file or stream. That's bad.
> It would seem better for freopen to allow the pointer to change as
>
> freopen(fname, mode, &stdout);
>
> where the & allows the *pointer* to change rather than the FILE struct.
I think you're confused about that struct needing to change.
> The freopen call may be a macro which does prepend an ampersand.
> I cannot see how it could change the pointer otherwise.
It doesn't or shouldn't.
>> Why would there need to be any change? ...
>
> Well, stdin is a pointer. It points to a FILE struct.
> AIUI if it points to the standard-in FILE struct before the call then
> I thought the purpose of the call was to get it to point to a different
> FILE struct.
No.
freopen() is to associate a different file, i.e., filename, with
the file ... However, the file here isn't a file but is a stream.
freopen() is used for redirecting stdin, stdout, stderr.
...
AISI, this is the everything is a file concept for POSIX.
stdin is a stream, but can be used like an open file. What is
stdin's filename? What name was used with fopen() by the OS to
open the file stdin? It doesn't have one or it's unknown to us
since it's a stream.
I can only describe the "mental model" I have for this since I've
neither implemented it, nor studied it in any depth. If implementing
a C library, I would need to find a solution that works correctly
according to C's usage. I did do something in a very limited sense
related to this some years ago for in memory files.
So, in my "mental model," there should be at least *two* structs per
file, but only *one* struct per stream. One of the file structs
handles the high-level filesystem information. The other file struct
handles the low-level filesystem information. In this case, a C FILE
struct would be the low-level information needed for direct or raw
filesystem access to the opened file. There should also be another
high-level struct which handles the high-level file information, e.g.,
filename, path, drive, file open mode, renamed flag, delete flag,
type of buffering, pointers to buffers, pointer to directory entry,
etc. All this info is created with fopen() and flushed with fclose().
So, one item in the high-level struct should be a FILE pointer which
points to the low-level struct for the opened file or stream. In my
mental model, both of these are stored in arrays of the appropriate
type. E.g., array of high-level structs, and an array of low-level
structs. Now, 'stdin', 'stdout', and 'stderr' are streams and so
they don't have a high-level struct associated with them, unless
you use freopen() to connect them with a true file.
Rod Pemberton
Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-11 20:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-12 04:24 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 03:17 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 03:28 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:12 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 17:09 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-13 11:10 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:13 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-14 09:08 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:23 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:12 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:54 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-07 12:19 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-07 13:30 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:38 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:49 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 20:58 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 01:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-10 10:45 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 23:20 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:26 +0200
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:50 +0200
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-11 00:58 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 17:38 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-11 23:39 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 19:39 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:22 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:21 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-12 21:53 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:49 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:58 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 07:32 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:05 +0100
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 13:19 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-15 00:01 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 14:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-26 16:23 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2015-09-27 00:23 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-26 16:37 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:17 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:24 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:46 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:14 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-27 13:52 +0000
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:28 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:31 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 16:21 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-20 17:25 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:43 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:21 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 13:02 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:09 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 13:32 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 18:51 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 18:16 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:36 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:56 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:45 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 10:28 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:53 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:17 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 16:54 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:39 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 20:31 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 09:03 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:33 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 23:17 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-20 17:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-20 23:46 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 21:37 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 22:29 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 03:25 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:18 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:47 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:00 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-13 09:15 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 10:55 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-15 19:23 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-16 03:03 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-16 10:17 -0700
csiph-web