In article <4hkean$mrc@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

|> No, it must work. EOF is required to have a value different from every
|> character value.

Where does it say this?  (It's what I always thought too, until a recent
discussion in comp.std.c proved me otherwise, at least for C.)

It is indirectly required if INT_MAX >= UCHAR_MAX, at least for fgetc in
C, but if int's and char's are the same size, all bets are off.

By `character value', I presume you mean a value that can be returned by
a successful read, since the original question concerned using
istream::peek and istream::get for binary input.  Although even for
character (non-binary) input, I can see no guarantees once one leaves
the "C" locale.

|> The character-reading functions that can return either
|> a character or EOF return a type that that can represent the EOF value
|> as distinct from any character value.

This is definitly not the case in ISO C, and I can find no such
guarantee in the current draft either, although in this case, it might
be a simple oversight.  Again, there is some ambiguity in your use of
the word character: imagine a 16 bit machine with sizeof( int ) ==
sizeof( char ) == 1, using Unicode as its native character code.
Unicode explicitly doesn't use 0xFFFF (-1) as a legal code, so if EOF is
-1 (a frequent implementation), there is no problem with reading
`characters'.  Reading a `char' from a file opened in binary mode is
still a problem, however.

|> In a traditional implementation, EOF has the int value -1, and characters
|> have 8-bit values. The peek function returns the character value promoted
|> to type int without sign extension, as if by the cast sequence
|>  (int)(unsigned char)the_value
|> Such a value cannot compare equal to the int value -1.

I suspect that a lot of code developed on a traditional implementation
will break on a machine where all integral types are the same length.
(I know that a lot of mine would.  Even in the parts I thought I wrote
portably.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
              -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[Moderator's note: Please note that this article is crossposted to
three newsgroups, two of which are moderated.  The Followup-to line is
set to comp.std.c++.  You should edit your newsgroups line if your
reply would be more appropriate for some other group(s).  mha]


Hello,

I have had a look in the April draft, but I think that there is a small
ambiguity about eof() methods in streams.
Is the eof-flag raised, when the end of the stream is reached, or when
an attempt to move past this end is made? I think the most common
practice is the latter, but the ANSI draft uses the former statement.
Declaring the end of a stream as the first charachter _after_ the last
character of the stream would rescue the expression, but wouldn't fit
into a concept of an end. (Usually one thinks of an end as belonging to
the whole)
As I am rather convinced, that the eof is raised at an attempt to meove
past the end, I'd like to ask how to check this in a binary file without
having to perform a movement.

Regards,
 Axel.
===
Axel Thimm <axl@zedat.fu-berlin.de>
Freie Universitaet Berlin
===

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]