Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #123959 > unrolled thread

do repeating fopen make an error?

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#123959 — do repeating fopen make an error?

do repeating fopen of fclose many times
(i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it) 
make an error?

in my personal opinion there are some 
schemes/patterns of cosing which are bad and most probably this scheme with fopen fclose is at all wrong as it makes some 'temporal' state (state that is holded in 'time' not in ram,
for example if you would call a function DrawText to the same place 
it is not an error as it just draws text, it may overwrite exact the same place with the same pixels but it is not conceptual error - this kind of functions make some 'class' (category) of functions and nearly all functions 
in programming may belong to that class (im not strictly sure if thats tru but its true in some context i got on mind) and there are some exceptions from that category and those exceptions i consider as somethiong most probably evil and wrong

note yet one thing, in OOP you may find some sets of functions that are designed not sor seperate usege but
only in some combinations in a form of code snippets and to do something you in fact probably shouldnt think on those functions as seperate but just copy whole snippets (it is something like fopen-fclose pair but more complex) - [note normal c dont go this way normally, one exception is those fopen-fclose other notable exception 
is those 3 or 5 va_arg macros which you also must use in combinationa) as i said i also find those combinations as devillish... one may incidentally be tied to another as this temporal state is in some way releted to this 
function-set-combinations  (as probably the parts of thsi combinations depend one on another
via those temporal hidden states)

i couldnt say much more on this as this is a bit vague topic but something is going on here..maybe i will say more on this in some future

[toc] | [next] | [standalone]

#123963

W dniu czwartek, 7 grudnia 2017 00:37:57 UTC+1 użytkownik fir napisał:
> do repeating fopen of fclose many times
> (i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it) 
> make an error?
> 
> in my personal opinion there are some 
> schemes/patterns of cosing which are bad and most probably this scheme with fopen fclose is at all wrong as it makes some 'temporal' state (state that is holded in 'time' not in ram,
> for example if you would call a function DrawText to the same place 
> it is not an error as it just draws text, it may overwrite exact the same place with the same pixels but it is not conceptual error - this kind of functions make some 'class' (category) of functions and nearly all functions 
> in programming may belong to that class (im not strictly sure if thats tru but its true in some context i got on mind) and there are some exceptions from that category and those exceptions i consider as somethiong most probably evil and wrong
> 
> note yet one thing, in OOP you may find some sets of functions that are designed not sor seperate usege but
> only in some combinations in a form of code snippets and to do something you in fact probably shouldnt think on those functions as seperate but just copy whole snippets (it is something like fopen-fclose pair but more complex) - [note normal c dont go this way normally, one exception is those fopen-fclose other notable exception 
> is those 3 or 5 va_arg macros which you also must use in combinationa) as i said i also find those combinations as devillish... one may incidentally be tied to another as this temporal state is in some way releted to this 
> function-set-combinations  (as probably the parts of thsi combinations depend one on another
> via those temporal hidden states)
> 
> i couldnt say much more on this as this is a bit vague topic but something is going on here..maybe i will say more on this in some future

i may add yet a bit (though not fully) what i mean by state holded in 'time' or temporal state

imagine you have four api functions
left() right() up() down() calling those functions my lead you to some state which you could then idientify only by the history of previously called functions

one could sat thay you may count each calls and it this is 17 rigts 3 lefts and 5 ups and 7 downs youre 
at 14,-2 but obviously not always 
there is such maping (usually no)

(maybe it even may be worse i mean 
you maybe may need to know a relations between various states
which are obtainable by various call histories but you dont know them, those relations)

if coding evolves into such temporal branches it is great disaster.. once in my life i get 
into it doing some code releted to mouse cursor movement limitation in windows, the stste depended on 
various calls, states and events and i cannot damn comprehend it.. right now i dont remember the details (i was more noob than today 
and those noob state could help to
get lost but anyway those combinanations on various events calls yet even user acctions in gui
(as for example you could make kursor movement timited to soem rectangle and make it yet hidden but if uses switched apps some statec could change, cursor get visible or unclipped etc or something this kind or yet worse) but that was for sure a travel in thiose temporal states, one could try to make it normal state (compare those left right up down api with a simple position holded as x,y) by storing some hints in normal state variables - like set of booleans but it also not quite works ;c

i think some people may also get into this temporal disaster when working on legacy code they do not understood fully, they may built some temporat patches over it which is obviously terrible

what i would like tryin to do is to define what is wrong here and why,
as i said some reckognized small patterns in programming may be some
entry to this world of hell (though if keeping shallow they may be maybe standable, maybe even if going with brain to those temporal states that could be good too, 
becouse for example having such calls as those left-right-up-down appi may be considered as an  adventure - usercoder could be maybe limited by such api 
it is something that plain x,y coordinates will not provide)

in normal c coding hovever i wuold
probably advice to considering stayin away from that things unles maybe well understood what is goin on.. and for present ti,mes to look at all cases where such api-combinations do appear

[toc] | [prev] | [next] | [standalone]

#123977

On 12/7/2017 7:37 AM, fir wrote:
> do repeating fopen of fclose many times
> (i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it)
> make an error?
>

fopen() will always use some memory for the file descriptor block. Some 
operating systems might lock the file as well. fopen() also has modes.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#123998

On Thursday, December 7, 2017 at 6:37:58 AM UTC-8, Mr. Man-wai Chang wrote:
> On 12/7/2017 7:37 AM, fir wrote:
> > do repeating fopen of fclose many times
> > (i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it)
> > make an error?
> >
> 
> fopen() will always use some memory for the file descriptor block. Some 
> operating systems might lock the file as well. fopen() also has modes.
> 
> -- 
>    @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
>   / v \  Simplicity is Beauty!
> /( _ )\ May the Force and farces be with you!
>    ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3

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.

[toc] | [prev] | [next] | [standalone]

#123999

http://www.cplusplus.com/reference/cstdio/fopen/

This, alomg with my really bad abuse of C terminology, should be enough to get the group language lawyers after me.

[toc] | [prev] | [next] | [standalone]

#124001

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.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#124002

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.
> 
> -- 
>    @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
>   / v \  Simplicity is Beauty!
> /( _ )\ May the Force and farces be with you!
>    ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
> 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):

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.

[toc] | [prev] | [next] | [standalone]

#124003

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.
>>
>> -- 
>>     @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
>>    / v \  Simplicity is Beauty!
>> /( _ )\ May the Force and farces be with you!
>>     ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
>> 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
> 
> 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, 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).

[toc] | [prev] | [next] | [standalone]

#124012

Richard Damon <Richard@Damon-Family.org> writes:
> On 12/8/17 7:18 AM, Chad wrote:
[...]
>> 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, 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).

The C standard says exactly nothing about file descriptors.  fopen()
returns a FILE* pointer; the contents of type FILE are unspecified.
(The term "file descriptor" usually refers to a small integer value
returned by the POSIX open() function.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#124014

W dniu piątek, 8 grudnia 2017 17:05:36 UTC+1 użytkownik Keith Thompson napisał:
> Richard Damon <Richard@Damon-Family.org> writes:
> > On 12/8/17 7:18 AM, Chad wrote:
> [...]
> >> 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, 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).
> 
> The C standard says exactly nothing about file descriptors.  fopen()
> returns a FILE* pointer; the contents of type FILE are unspecified.
> (The term "file descriptor" usually refers to a small integer value
> returned by the POSIX open() function.)
> 
as i mentioned in a thread "141 functions" the FILE def you can find in clib implementation headers


typedef struct _iobuf 
{ 
 char* _ptr; 
 int _cnt; 
 char* _base; 
 int _flag; 
 int _file; 
 int _charbuf; 
 int _bufsiz; 
 char* _tmpfname; 
} FILE; 

[toc] | [prev] | [next] | [standalone]

#124015

On 08/12/2017 16:27, fir wrote:
> W dniu piątek, 8 grudnia 2017 17:05:36 UTC+1 użytkownik Keith Thompson napisał:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 12/8/17 7:18 AM, Chad wrote:
>> [...]
>>>> 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, 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).
>>
>> The C standard says exactly nothing about file descriptors.  fopen()
>> returns a FILE* pointer; the contents of type FILE are unspecified.
>> (The term "file descriptor" usually refers to a small integer value
>> returned by the POSIX open() function.)
>>
> as i mentioned in a thread "141 functions" the FILE def you can find in clib implementation headers
> 
> 
> typedef struct _iobuf
> {
>   char* _ptr;
>   int _cnt;
>   char* _base;
>   int _flag;
>   int _file;
>   int _charbuf;
>   int _bufsiz;
>   char* _tmpfname;
> } FILE;
> 

Under Linux it looks more like this:

struct _IO_FILE{
   int _flags;
char*_IO_read_ptr;
   char*_IO_read_end;
   char*_IO_read_base;
   char*_IO_write_base;
   char*_IO_write_ptr;
   char*_IO_write_end;
   char*_IO_buf_base;
   char*_IO_buf_end;
   char*_IO_save_base;
   char*_IO_backup_base;
   char*_IO_save_end;
struct _IO_marker*_markers;
struct _IO_FILE*_chain;
int _fileno;
int _flags2;
__off_t _old_offset;
unsigned short _cur_column;
   signed char _vtable_offset;
   char _shortbuf[1];
_IO_lock_t*_lock;
__off64_t _offset;
void*__pad1;
   void*__pad2;
   void*__pad3;
   void*__pad4;
size_t __pad5;
   int _mode;
   char _unused2[15*sizeof(int)-4*sizeof(void*)-sizeof(size_t)];
};

Elsewhere this is this:

typedef struct _IO_FILE FILE;

This is is why C can't specify what it contains, as it depends on the 
implementation.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#124017

W dniu piątek, 8 grudnia 2017 18:00:18 UTC+1 użytkownik Bart napisał:
> On 08/12/2017 16:27, fir wrote:
> > W dniu piątek, 8 grudnia 2017 17:05:36 UTC+1 użytkownik Keith Thompson napisał:
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>> On 12/8/17 7:18 AM, Chad wrote:
> >> [...]
> >>>> 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, 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).
> >>
> >> The C standard says exactly nothing about file descriptors.  fopen()
> >> returns a FILE* pointer; the contents of type FILE are unspecified.
> >> (The term "file descriptor" usually refers to a small integer value
> >> returned by the POSIX open() function.)
> >>
> > as i mentioned in a thread "141 functions" the FILE def you can find in clib implementation headers
> > 
> > 
> > typedef struct _iobuf
> > {
> >   char* _ptr;
> >   int _cnt;
> >   char* _base;
> >   int _flag;
> >   int _file;
> >   int _charbuf;
> >   int _bufsiz;
> >   char* _tmpfname;
> > } FILE;
> > 
> 
> Under Linux it looks more like this:
> 
> struct _IO_FILE{
>    int _flags;
> char*_IO_read_ptr;
>    char*_IO_read_end;
>    char*_IO_read_base;
>    char*_IO_write_base;
>    char*_IO_write_ptr;
>    char*_IO_write_end;
>    char*_IO_buf_base;
>    char*_IO_buf_end;
>    char*_IO_save_base;
>    char*_IO_backup_base;
>    char*_IO_save_end;
> struct _IO_marker*_markers;
> struct _IO_FILE*_chain;
> int _fileno;
> int _flags2;
> __off_t _old_offset;
> unsigned short _cur_column;
>    signed char _vtable_offset;
>    char _shortbuf[1];
> _IO_lock_t*_lock;
> __off64_t _offset;
> void*__pad1;
>    void*__pad2;
>    void*__pad3;
>    void*__pad4;
> size_t __pad5;
>    int _mode;
>    char _unused2[15*sizeof(int)-4*sizeof(void*)-sizeof(size_t)];
> };
> 
> Elsewhere this is this:
> 
> typedef struct _IO_FILE FILE;
> 
> This is is why C can't specify what it contains, as it depends on the 
> implementation.
> 

interesting 

i wonder who (what) needs all those fields.. is that c stdlib who needs that? making api work faster? 

(as i said i once started to see all such api who makes 'temporal' hidden states (instead of strightly dealing wuth physical states) as bad - but more on this maybe other time)

[toc] | [prev] | [next] | [standalone]

#124018

I *think* some of those fields are meant to handle the differences between printing letters a line at a time, printing them a letter at a time, or printing to an unbuffered output.

[toc] | [prev] | [next] | [standalone]

#124021

On Friday, December 8, 2017 at 12:31:03 PM UTC-6, fir wrote:
> i wonder who (what) needs all those fields.. is that c stdlib who needs that? making api work faster? 

Operating systems' I/O routines often have semantics that differ slightly
from those of the C Standard Library.  A hosted C implementation, for example,
is required to support "unget" functionality on streams without regard for
whether the underlying OS provides such a feature.  Further, even if an OS
has an ability to handle single-character I/O (some only allow files to be
read and written in fixed-sized chunks of 128 bytes or so), it would not be
uncommon for a sequence of 1024 single-byte reads to take an order or two of
magnitude longer than a single 1024-byte read.  Such issues are usually
resolved by having a C implementation act as a wrapper between standard-
library I/O requests and OS-level requests.  If user code performs 1024
single-byte reads, having the Standard library perform a 1024-byte read,
use the first byte to satisfy the first request, and then using the next
1023 bytes in sequence to satisfy the next 1023 requests, may be much
faster than using an OS call for every byte.

[toc] | [prev] | [next] | [standalone]

#124073

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

[toc] | [prev] | [next] | [standalone]

#124004

On 8/12/2017 8:18 PM, Chad wrote:
>
> 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.

I believe it's linker's duty to bind C's fopen() in your program to the 
proper operating system API call for opening a file, instead of making 
the call yourself using assembly languages. C syntax supports inline 
assembly instructions.

BTW, another name for "file descriptor" is called File Control Block. :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#124011

On Friday, December 8, 2017 at 9:06:22 AM UTC-6, Mr. Man-wai Chang wrote:
> On 8/12/2017 8:18 PM, Chad wrote:
> >
> > 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.
> 
> I believe it's linker's duty to bind C's fopen() in your program to the 
> proper operating system API call for opening a file, instead of making 
> the call yourself using assembly languages. C syntax supports inline 
> assembly instructions.

It is the implementation's duty to bind fopen() to something that behaves
as defined by the Standard in the cases mandated thereby.  That does not
imply that it use an underlying OS for that purpose.  Nothing would forbid
an implementation from running in a context where it couldn't open any
files for writing, and where there weren't any files available for reading.
Since an implementation of fopen() that unconditionally returned null would
be indistinguishable from one that was running in such a context, I don't
think anything in the Standard would forbid a conforming implementation of
fopen() from simply returning null.  Such an implementation would of course
be of such low quality as to be essentially useless, but the authors of the
Standard have said in the rationale that they don't expect the possibility
of conforming-but-useless implementations to be a problem.

[toc] | [prev] | [next] | [standalone]

#124068

> Yes, fopen() returns a file handle (an integer?) to the file descriptor 
> managed by operating systems.

No, fopen() returns a pointer to a FILE object.  The FILE object might
contain a file descriptor (small integer) managed by the operating
system if there is such a thing for that OS.

[toc] | [prev] | [next] | [standalone]

#124000

On Wednesday, 6 December 2017 23:37:57 UTC, fir  wrote:
> do repeating fopen of fclose many times
> (i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it) 
> make an error?

You can open the file as many times as you like (subject to limits on the number
of file handles supported by the operating system). The interaction of these handles, if you are writing to one or more, may be complex, but not in any 
sense an error.

Closing a file handle which isn't open would be an error.

(I see no point in quoting or engaging with the rest of this garbled mess)

[toc] | [prev] | [next] | [standalone]

#124009

On Friday, December 8, 2017 at 4:56:33 AM UTC-6, mark.b...@gmail.com wrote:
> On Wednesday, 6 December 2017 23:37:57 UTC, fir  wrote:
> > do repeating fopen of fclose many times
> > (i mean fopenig the same file many times without fclosing it, or fclosing some handle many times without reopenig it) 
> > make an error?
> 
> You can open the file as many times as you like (subject to limits on the number
> of file handles supported by the operating system). The interaction of these handles, if you are writing to one or more, may be complex, but not in any 
> sense an error.

Given e.g. "FILE *F1 = fopen("fred","r"), f2 = fopen("./fred","r");", an
implementation may or may not recognize that both operations are acting
upon the same file.  Further, some operating systems may by default treat
"fopen" as granting exclusive access to a file, and may not honor a request
to open a file that is already open, even by the same application.

Attempting to open a file that is already open would therefore fall in the
realm of things which are likely to work on some implementations and fail
on others.  In general, the success or failure of a repeated fopen attempt
would depend upon how the underlying OS would process repeated requests to
open the same file, but the Standard doesn't imply any such relationship
between the underlying OS and the behavior of the "abstract machine".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web