Re: EOF location?
- From: Clever Monkey <clvrmnky.invalid@xxxxxxxxxxxxxxxxxxx>
- Date: Wed, 31 May 2006 12:37:58 -0400
Richard wrote:
Not so Clever Monkey wrote:I don't know what either of us are talking about anymore. I'm not sure how we got on the subject of what is or is not part of an API.
I carefully noted in the rest of my reply that this is an APIA single 0x1A (control-Z in ASCII) is used to indicate EOF,That is only true if the particular program tests specifically for that
character. Any file can have Ctrl-Zs scattered through them and what
happens is entirely dependent on the program.
convention.
You keep talking about 'API' but The DOS/Win32 API does not have that
convention, nor does POSIX. Neither knows nor cares about Ctrl-Z in
disk files. Certain application programs may still recognize Ctrl-Z and
may or may not deal with them in any way they see fit.
The only 'convention' was with CP/M programs 30 years ago and that was
_not_ part of the 'API'.
I mention API mostly in reference of the Win32 API (which seemed appropriate, given the context under which I was responding -- remember, I only have Pete Dashwood's reply as the OP) and used the term only because I was generalizing the idea of file access, and what EOF might mean to any sort of code one might run into.
In order to generalize and abstract the idea of "data" being accessed via "files", I used the most general form of a collection of routines that would allow us to (among other things) inspect files -- an API. I also used the word "routine" as well. I did not want to specifically talk about a particular (for example) platform or library or even function, since how we handle such data is really up to us.
At any rate, you are correct: the common file and string handling routines do not care about the EOF char -- it is divorced from the notion of end-of-file). I did not intend to suggest otherwise, and a quick test using fopen(), gets() and strlen() proves that.
However, some code, when it sees a cntrl-Z, will stop opening up the file. I've seen it happen. That's all I was driving at. I usually don't even care if the cntrl-Z is there or not, since the APIs/functions/routines/languages/things I use tell me what they do when they encounter the "end of file" or not, and I can figure out the rest.
I certainly made no absolute statements about such characters, only general observations I've made over the years. My last two paragraphs were off-hand remarks meant to convey "such characters may be present, but the programmer only needs to care about them if they need to care about them".
That all being said, I think I now understand what you might have been getting at. For the question, "would an EOF char in a file count as part of the file for the purpose of file size?". The answer is, almost certainly.
8$ print "\^Z" > outfile.txt
9$ od -ch outfile.txt
0000000000 032 \r \n
1A 0D 0A
0000000003
10$ ls -l outfile.txt
-rw-rw-rw- 1 user group 3 May 31 12:14 outfile.txt
11$
I did not mean to suggest that this was not the case. I certainly know that such characters can be part of any file. Since I was answering that question only indirectly I focused instead on the idea that such a stream of characters can mean all sorts of things to different functions, routines, code, APIs, things.
For some reason, the following tickles me:
12$ file outfile.txt
outfile.txt: ARC archive
13$
.
- References:
- EOF location?
- From: HeyBub
- Re: EOF location?
- From: Pete Dashwood
- Re: EOF location?
- From: Clever Monkey
- Re: EOF location?
- From: Richard
- Re: EOF location?
- From: Clever Monkey
- Re: EOF location?
- From: Richard
- EOF location?
- Prev by Date: Re: Newbie Question
- Next by Date: Re: Rewrite Twice?
- Previous by thread: Re: EOF location?
- Next by thread: Re: EOF location?
- Index(es):
Relevant Pages
|
