«

Keith Thompson wrote:
> Roberto Waltman <> writes:
>
.... snip ...
>
>> You may not be able to open 100 files in a single program, even if
>> your code is 100% correct from the coding and logic points of view.
>> And if you can open 100 files, that means 100 less are available to
>> the system as a whole, potentially causing other programs to fail.
>
> Does *every* system impose this kind of limit? I know that many do,
> but it's easy to imagine a system where the number of simultaneously
> open files is limited only by the amount of memory necessary to
> describe them. Such a system would have no fixed-size tables of file
> descriptors, for example.

No. Try CP/M for example, and FCBs. The space is in the users
area, and limited only by what he can get. The disadvantage is
that the user has to close files properly.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

Keith Thompson <kst-> wrote:
>Roberto Waltman <> writes:
>[...]
>> <OT>
>> Reusing the same FILE pointer leads to a simpler and cleaner design,
>> but there are other reasons to do this: Every operating system has
>> some limit on the number of files that can be open simultaneously,
>> both on a per-process and system-wide basis.
>> You may not be able to open 100 files in a single program, even if
>> your code is 100% correct from the coding and logic points of view.
>> And if you can open 100 files, that means 100 less are available to
>> the system as a whole, potentially causing other programs to fail.
>
>Does *every* system impose this kind of limit? I know that many do,
>but it's easy to imagine a system where the number of simultaneously
>open files is limited only by the amount of memory necessary to
>describe them. Such a system would have no fixed-size tables of file
>descriptors, for example.
>
>> </OT>

Point well taken, I have not yet used *every* OS, please replace
"every" with "most" in my response
All those that I did use had some fixed limit, (in some cases
changeable by the users,) but of course an implementer could choose a
different approach.

CBFalconer <> wrote:
>Keith Thompson wrote:
>> Roberto Waltman <> writes:
>>> You may not be able to open 100 files in a single program, even if
>>> your code is 100% correct from the coding and logic points of view.
>>> And if you can open 100 files, that means 100 less are available to
>>> the system as a whole, potentially causing other programs to fail.
>>
>> Does *every* system impose this kind of limit? I know that many do,
>> but it's easy to imagine a system where the number of simultaneously
>> open files is limited only by the amount of memory necessary to
>> describe them. Such a system would have no fixed-size tables of file
>> descriptors, for example.
>
>No. Try CP/M for example, and FCBs. The space is in the users
>area, and limited only by what he can get. The disadvantage is
>that the user has to close files properly.

I forgot about CP/M - Same thing with DEC RSTS-11/RSX-11 and HP
RTE-II/III - File control blocks in user space.

CBFalconer <> writes:
> Keith Thompson wrote:
>> Roberto Waltman <> writes:
>>
> ... snip ...
>>
>>> You may not be able to open 100 files in a single program, even if
>>> your code is 100% correct from the coding and logic points of view.
>>> And if you can open 100 files, that means 100 less are available to
>>> the system as a whole, potentially causing other programs to fail.
>>
>> Does *every* system impose this kind of limit? I know that many do,
>> but it's easy to imagine a system where the number of simultaneously
>> open files is limited only by the amount of memory necessary to
>> describe them. Such a system would have no fixed-size tables of file
>> descriptors, for example.
>
> No. Try CP/M for example, and FCBs. The space is in the users
> area, and limited only by what he can get. The disadvantage is
> that the user has to close files properly.

Does "the user has to close files properly" imply that if I fail to
close a file, it will continue to consume system resources after my
program terminates?

Note that the standard says that exit() closes all open streams (and
returning from main() is equivalent to calling exit(), so a C program
under a conforming implementation shouldn't have this problem.

Of course closing files you opened is a good idea anyway.

--
Keith Thompson (The_Other_Keith) kst- <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.

Keith Thompson <kst-> wrote:
>CBFalconer <> writes:
>> No. Try CP/M for example, and FCBs. The space is in the users
>> area, and limited only by what he can get. The disadvantage is
>> that the user has to close files properly.
>
>Does "the user has to close files properly" imply that if I fail to
>close a file, it will continue to consume system resources after my
>program terminates?

No. The problem is not resource leakage, but potential data
corruption. A system such as CP/M does not keep track of files
accessed via FCBs in userland, therefore you can loose or otherwise
corrupt data if you do not close open files before terminating a
program.

>Note that the standard says that exit() closes all open streams (and
>returning from main() is equivalent to calling exit(), so a C program
>under a conforming implementation shouldn't have this problem.

Correct. A conforming C program using user-space FCBs would close any
open files as part of the cleanup following main().

>Does "the user has to close files properly" imply that if I fail to
>close a file, it will continue to consume system resources after my
>program terminates?

Likely not, if the resources involved are all in user memory, and
that memory is all recovered on exit.

What might happen (and sometimes did in CP/M) is that the file
contents does not reflect all the writes you did (the file still
appears as zero-length, even if the data was actually written,
since the file length was not updated).

>Note that the standard says that exit() closes all open streams (and
>returning from main() is equivalent to calling exit(), so a C program
>under a conforming implementation shouldn't have this problem.

I don't believe this is required to happen if, for example, the
program is terminated by typing an interrupt character rather
than by calling exit().

>Of course closing files you opened is a good idea anyway.

*IF* you get a chance, which may not be the case if the program
gets killed externally.

Gordon L. Burditt

(Gordon Burditt) writes:
>>Does "the user has to close files properly" imply that if I fail to
>>close a file, it will continue to consume system resources after my
>>program terminates?
>
> Likely not, if the resources involved are all in user memory, and
> that memory is all recovered on exit.
[snip]

Thanks.

Gordon, *please* do us all a favor and don't snip attributions when
you post a followup. We've had this discussion before; see
<http://groups.google.com/group/comp.lang.c/msg/291038dca20a505e>.

--
Keith Thompson (The_Other_Keith) kst- <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.

>>>Does "the user has to close files properly" imply that if I fail to
>>>close a file, it will continue to consume system resources after my
>>>program terminates?
>>
>> Likely not, if the resources involved are all in user memory, and
>> that memory is all recovered on exit.
>[snip]
>
>Thanks.
>
>Gordon, *please* do us all a favor and don't snip attributions when
>you post a followup. We've had this discussion before; see
><http://groups.google.com/group/comp.lang.c/msg/291038dca20a505e>.

Attribution = misattribution. Even though you and I think that
attributions indicate who wrote what, and we might even agree on
who wrote what, the authors of other articles in the thread don't
agree, and if I don't snip attributions, I get complaints from
several authors each claiming I mis-attributed the *SAME* text to
them. That can draw lawsuits. As far as I know, non-attribution
cannot.

Gordon L. Burditt

On 2006-05-19, Gordon Burditt <> wrote:
>>>>Does "the user has to close files properly" imply that if I fail to
>>>>close a file, it will continue to consume system resources after my
>>>>program terminates?
>>>
>>> Likely not, if the resources involved are all in user memory, and
>>> that memory is all recovered on exit.
>>[snip]
>>
>>Thanks.
>>
>>Gordon, *please* do us all a favor and don't snip attributions when
>>you post a followup. We've had this discussion before; see
>><http://groups.google.com/group/comp.lang.c/msg/291038dca20a505e>.
>
> Attribution = misattribution. Even though you and I think that
> attributions indicate who wrote what, and we might even agree on
> who wrote what, the authors of other articles in the thread don't
> agree, and if I don't snip attributions, I get complaints from
> several authors each claiming I mis-attributed the *SAME* text to
> them. That can draw lawsuits. As far as I know, non-attribution
> cannot.
>
> Gordon L. Burditt
Quoting others without giving them credit may very well draw lawsuits,
although I can't imagine why anyone would sue over UseNET.

Nobody disagrees over who wrote what. You need to quote attributions.

--
Andrew Poelstra [apoelstra@wp____ware.net] < http://www.wpsoftware.net/blog >
Get your game faces on, because this is not a game.

(Gordon Burditt) writes:

> Attribution = misattribution. Even though you and I think that
> attributions indicate who wrote what, and we might even agree on
> who wrote what, the authors of other articles in the thread don't
> agree, and if I don't snip attributions, I get complaints from
> several authors each claiming I mis-attributed the *SAME* text to
> them. That can draw lawsuits. As far as I know, non-attribution
> cannot.

I don't understand your objection. I've been posting to Usenet
for many years now and I've never encountered anyone who made
such bizarre allegations. Is this something that really happened
or are you just inventing a hypothetical?
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}