EOF == -1

[Ray Hamel]

The C, C++ and POSIX standards require EOF to be a negative constant expression
of type int. In all implementations I'm aware of, EOF == -1. The only exception
I can find is that EOF was ^Z ( '\x1A' ) in DOS, which is positive and therefore
already nonconforming. There is no doubt a great deal of existing code relying
on the assumption that EOF == -1, so I think it makes sense to standardize this
convention.

A more conservative alternative is to require that static_cast<signed char>(EOF)
be negative.

Best,
Ray

[Miguel Ojeda]

Hi Ray,

On Tue, Mar 6, 2018 at 10:40 PM, Ray Hamel <rayg...@gmail.com> wrote:
> The C, C++ and POSIX standards require EOF to be a negative constant
> expression
> of type int. In all implementations I'm aware of, EOF == -1. The only
> exception
> I can find is that EOF was ^Z ( '\x1A' ) in DOS, which is positive and
> therefore
> already nonconforming. There is no doubt a great deal of existing code
> relying
> on the assumption that EOF == -1, so I think it makes sense to standardize
> this
> convention.

I am not sure there is a lot of code relying on that. Do you have an
example? Code using either the C or C++ standard libraries should be
using EOF (or other ways of detecting the end of file), and therefore
they are not relying on EOF == -1. Code not using the standard library
for I/O is not using EOF at all, so they don't rely on it either.
Therefore, one would think most code out there is not assuming
anything about EOF (and if they do, it is a mistake anyway).

What are the benefits of making EOF == -1 that you have in mind? Even
if you make the standard say that, your code shouldn't/wouldn't rely
on it anyway (since magic constants are not a good idea). On the other
hand, there are some costs to such change: forcing a value for EOF
could actually break invalid code out there (hypothetical code using a
hardcoded different value); and it would make implementing new systems
harder to accommodate to C++ in the future (assuming they use a
different value for EOF).

>
> A more conservative alternative is to require that static_cast<signed
> char>(EOF)
> be negative.

I am not sure I understand why you would want to do such a cast to
begin with -- maybe a use case would clarify your point! :-)

Cheers,
Miguel

>
> Best,
> Ray
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/16a9359c-2d18-4085-9573-305aba68e75d%40isocpp.org.

[Thiago Macieira]

On Tuesday, 6 March 2018 13:40:31 PST Ray Hamel wrote:
> A more conservative alternative is to require that static_cast<signed
> char>(EOF)
> be negative.

That is unnecessary, since EOF is supposed to be a value outside of the range
of char.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Victor Dyachenko]

On Wednesday, March 7, 2018 at 12:40:31 AM UTC+3, Ray Hamel wrote:

A more conservative alternative is to require that static_cast<signed char>(EOF)
be negative.

It's a narrowing conversion. Functions like std::getc() have int as return type (not char!) intentionally to be able to retun "next byte or EOF". So you can compare only int value with EOF.

> There is no doubt a great deal of existing code relying on the assumption that

EOF == -1

Could you provide some code snippet that can't be written not relying on exact value of EOF?

[Thiago Macieira]

On Tuesday, 6 March 2018 13:40:31 PST Ray Hamel wrote:

> The only
> exception
> I can find is that EOF was ^Z ( '\x1A' ) in DOS, which is positive and
> therefore
> already nonconforming.

I also think you're wrong about this one. See the definition of EOF from

http://www.delorie.com/djgpp/doc/incs/stdio.h

[Bo Persson]

On 2018-03-06 22:40, Ray Hamel wrote:
> The C, C++ and POSIX standards require EOF to be a negative constant
> expression
> of type int. In all implementations I'm aware of, EOF == -1. The only
> exception
> I can find is that EOF was ^Z ( '\x1A' ) in DOS, which is positive and
> therefore
> already nonconforming. There is no doubt a great deal of existing code
> relying
> on the assumption that EOF == -1, so I think it makes sense to
> standardize this
> convention.
>

DOS was merely compatible with earlier operating systems that had file
sizes as sector counts instead of byte counts. The last sector was
padded with Ctrl-Z to fill it out.

EOF was then returned when this padding was encountered, not the Ctrl-Z
itself.


Bo Persson

[yakito...@gmail.com]

EOF is truly forced like std::string::npos.

but histry persons use the "#define EOF -1".

so EOF != -1 is truth.

EOF is that graph.

number is undefined is good.

[olafv...@gmail.com]

Op woensdag 7 maart 2018 05:27:25 UTC+1 schreef Thiago Macieira:

On Tuesday, 6 March 2018 13:40:31 PST Ray Hamel wrote:
> A more conservative alternative is to require that static_cast<signed
> char>(EOF)
> be negative.

That is unnecessary, since EOF is supposed to be a value outside of the range
of char.

Is it?

Range of char is often -128..127, EOF is often -1. 

[Thiago Macieira]

On Tuesday, 20 March 2018 17:18:34 CST olafv...@gmail.com wrote:
> Op woensdag 7 maart 2018 05:27:25 UTC+1 schreef Thiago Macieira:
> > On Tuesday, 6 March 2018 13:40:31 PST Ray Hamel wrote:
> > > A more conservative alternative is to require that static_cast<signed
> > > char>(EOF)
> > > be negative.
> >
> > That is unnecessary, since EOF is supposed to be a value outside of the
> > range
> > of char.
>
> Is it?

Yes, but I misspoke. It's a value outside the range of valid characters.

> Range of char is often -128..127, EOF is often -1.

Those functions return 0..255 for the valid characters.

"the fgetc() function shall obtain the next byte as an unsigned char converted
to an int"
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fgetc.html