Re: EOF location?


Clever Monkey wrote:

It might, but it is not. I was making the point that I was on a Win32
machine with POSIX utilities that allow us to inspect files.

There are many utilities that 'allow us to inspect files'. Using ones
that will use Win32 semantics may show Win32 features rather than POSIX
features. But in fact neither will show us what you claimed for EOF.

There are
several ways to do this. Just trying to be clear, here. (By the way,
even if I was running cygwin, I would consider this simply a programming
environment and set of libraries running on "some sort of" Win32/DOS.)

Exactly, a POSIX/Unix environment, not a Win32/DOS one.

Each
line is 11 characters long; 9 characters and two line-end characters.
Note also that the size in bytes is the same as the character count.

Well duhhh.

I was replying in the same spirit of the OP (or the closest thing to an
OP that my node is willing to give me) of "showing your work".

Unfortunately your 'work' was lacking:

"""The EOF/EOT marker is "present", but is
usually used up by API calls that scan for it while retrieving the
contents of a file."""

You assumed that there was a EOF (x'1a') character but it wasn't
showing because:

"""This implies that those routines that count characters will ignore
the
EOF. Indeed, those routines will likely stop whatever they are doing
immediately once they encounter the EOF and return with whatever they
got so far. Applications that use the usual APIs to get at the
contents
of text files will normally never count or show the trailing EOF. """

You never tried a file with hex characters in them other than CR/LF so
you came to an invalid conclusion.

Ok. I never implied otherwise. Some file APIs are able to return
lines. They will return lines that include any line ends that are
present, even if there are no line ends.

You are confusing 'API's with library functions. There are _no_ Win32
disk APIs that return 'lines' with or without line terminators.

The other stuff was just background.

It is the 'other stuff' that is complete nonsense.

Not true. Under some circumstances using these APIs to cycle through a
text file until you get "EOF" will fail when confronted with a file that
contains embedded EOF chars.

Which 'API's ? Programs may test for characters and stop on certain
ones, but the Win32 'API' will never stop on an embedded x'1A'. Nor
will POSIX.

It's a rare enough but common problem.

'Rare but common'. wonderful.

DOS/Win32 have no disk file APIs that will ever notice a Ctrl-Z nor
care about it. If the file is full of EOF (Ctrl-Z) characters then dir
will show how many there are.

I haven't used actual DOS in years, but I'm unclear on how "dir" would
do this.

DIR reports the size of the file, it does not inspect the contents.
You should not that I said 'full of Ctrl-Z's. Try it, try learning
something rather than repeating half-learnt nonsense.

I agree this is a convention, and I am pretty POSIX oriented in this
regard. I understand you can make a program to actually read in such
chars.

You can in POSIX/Unix/Linux too. Write a C program using fopen/fgetc
on a file of random hex characters and see that it will read to the
size of the file.

It is pretty common on Win32/DOS to refer to such files or file
access as "binary" (not necessarily binary used in the sense of libc
APIs that work with FILEs, but similar).

No 'binary', just fopen(..., "r") and fgetc() and you will see
characters in the file that are 0x1A, and the characters beyond.

Don't you ever try this stuff before you post it ? I do. Then _I_ know
what I am talking about.

However, since we were talking about the notion of line ends I kept my
discussion pretty much about so-called text files, where both EOL and
EOF can matter quite a bit.

You just don't listen do you.

.

Relevant Pages

  • Re: EOF location?
    ... line is 11 characters long; 9 characters and two line-end characters. ... Under some circumstances using these APIs to cycle through a text file until you get "EOF" will fail when confronted with a file that contains embedded EOF chars. ...
    (comp.lang.cobol)
  • Re: Unusual Input with fgets( )
    ... I assume you mean end-of-file, not the characters 'E', 'O', 'F'. ... EOF can't. ... It's hard to tell why your program halts, ...
    (comp.lang.c)
  • Re: Reading text file characters
    ... >> If anyone is still with this thread, I did a hex dump suggested by ... >> What doesn't show up in the numbers below is the last line of the hex ... >fill their file buffer with EOF characters, ... Since the first EOF marks the end, ...
    (microsoft.public.vb.general.discussion)
  • Re: converting std::basic_string to upper or lower case.
    ... >> upper case characters were coming back messed up. ... > 0-127 + EOF). ... So if you pass a negative char value it isn't going to be ... >> nagging suspicions it's not and that only the memory returned from ...
    (microsoft.public.vc.stl)
  • Re: EOF location?
    ... *> Get a directory report on the file... ... It would appear that there are three more characters than we actually ... the two characters which indicate EOF ... An ASCII CRLF pair are actually "line separators" used to ...
    (comp.lang.cobol)