Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #124073
| Message-Id | <kmnrfe-gn4.ln1@walter.foo> |
|---|---|
| From | "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> |
| Subject | Re: do repeating fopen make an error? |
| Newsgroups | comp.lang.c |
| Date | 2017-12-09 11:34 +1100 |
| References | (1 earlier) <p0bjnr$1cc$10@toylet.eternal-september.org> <0a6c8c2f-444d-4155-bb10-ebccd3eb9b24@googlegroups.com> <p0drkv$mp4$1@toylet.eternal-september.org> <41c2cb1c-793f-4cad-aedc-145192a86aa5@googlegroups.com> <%RvWB.77146$zp3.43998@fx12.iad> |
Groovy hepcat Richard Damon was jivin' in comp.lang.c on Fri, 8 Dec 2017
11:47 pm. It's a cool scene! Dig it.
> On 12/8/17 7:18 AM, Chad wrote:
>> FOn Friday, December 8, 2017 at 3:05:19 AM UTC-8, Mr. Man-wai Chang
>> wrote:
>>> On 8/12/2017 5:18 PM, Chad wrote:
>>>>>
>>>>> fopen() will always use some memory for the file descriptor block.
>>>>> Some operating systems might lock the file as well. fopen() also
>>>>> has modes.
>>>>
>>>> Doesn't fopen() return a file pointer? Just curious, because I
>>>> thought that open() itself returned a file descriptor. The
>>>> difference being that the former is supposedly portable.
>>>
>>> Yes, fopen() returns a file handle (an integer?) to the file
>>> descriptor managed by operating systems.
No, fopen() returns a pointer to FILE.
>> And what happens if I use fopen() on an OS that has no notion of a
>> file descriptor? For example, I know of legacy OS's that have no
>> notion of a file descriptor. Because in the K & R book, they make a
>> distinction.
>
> The OS doesn't need to have file descriptors. The C Standard says that
> fopen returns a file descriptor,
Oh really? Where does it say that? I can find this in n1570.pdf:
*********************************************************************
7.21.5.3 The fopen function
Synopsis
1 #include <stdio.h>
FILE *fopen(const char * restrict filename,
const char * restrict mode);
...
Returns
9 The fopen function returns a pointer to the object controlling the
stream. If the open operation fails, fopen returns a null pointer.
*********************************************************************
And I also see this:
*********************************************************************
7.21 Input/output <stdio.h>
7.21.1 Introduction
...
2 The types declared are size_t (described in 7.19);
FILE
which is an object type capable of recording all the information
needed to control a stream, including its file position indicator, a
pointer to its associated buffer (if any), an error indicator that
records whether a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has been reached; ...
*********************************************************************
But I see no reference there to file descriptors. Doing a search for the
word "descriptor" turned up nothing. But perhaps you know something I
don't. Perhaps there's something I've missed. Maybe you've found some
mysterious text that remains hidden from the rest of us, some cryptic
part of the standard that we mere mortals can't see.
> if the OS has a compatible function
> to call that returns one, the implementation can just forward to that.
> If the OS doesn't, then the implementation can provide the file
> descriptors (often in an array, with the 'file descriptor' returned
> being the index into that array).
A pointer is a pointer is a pointer, not an index into an array. And
fopen() returns a pointer. That's it.
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-06 15:37 -0800
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-06 16:21 -0800
Re: do repeating fopen make an error? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-12-07 22:37 +0800
Re: do repeating fopen make an error? Chad <cdalten@gmail.com> - 2017-12-08 01:18 -0800
Re: do repeating fopen make an error? Chad <cdalten@gmail.com> - 2017-12-08 01:33 -0800
Re: do repeating fopen make an error? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-12-08 19:05 +0800
Re: do repeating fopen make an error? Chad <cdalten@gmail.com> - 2017-12-08 04:18 -0800
Re: do repeating fopen make an error? Richard Damon <Richard@Damon-Family.org> - 2017-12-08 07:47 -0500
Re: do repeating fopen make an error? Keith Thompson <kst-u@mib.org> - 2017-12-08 08:05 -0800
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-08 08:27 -0800
Re: do repeating fopen make an error? bartc <bc@freeuk.com> - 2017-12-08 16:59 +0000
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-08 10:30 -0800
Re: do repeating fopen make an error? Chad <cdalten@gmail.com> - 2017-12-08 10:43 -0800
Re: do repeating fopen make an error? supercat@casperkitty.com - 2017-12-08 11:52 -0800
Re: do repeating fopen make an error? "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2017-12-09 11:34 +1100
Re: do repeating fopen make an error? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-12-08 23:06 +0800
Re: do repeating fopen make an error? supercat@casperkitty.com - 2017-12-08 08:03 -0800
Re: do repeating fopen make an error? gordonb.zy1op@burditt.org (Gordon Burditt) - 2017-12-09 13:07 -0600
Re: do repeating fopen make an error? mark.bluemel@gmail.com - 2017-12-08 02:56 -0800
Re: do repeating fopen make an error? supercat@casperkitty.com - 2017-12-08 07:57 -0800
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-08 08:17 -0800
Re: do repeating fopen make an error? gordonb.29zvv@burditt.org (Gordon Burditt) - 2017-12-09 13:00 -0600
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-09 14:45 -0800
Re: do repeating fopen make an error? fir <profesor.fir@gmail.com> - 2017-12-09 15:25 -0800
csiph-web