------=_Part_18588_157040309.1520372431311
Content-Type: multipart/alternative;
 boundary="----=_Part_18589_9836364.1520372431311"

------=_Part_18589_9836364.1520372431311
Content-Type: text/plain; charset="UTF-8"

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

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@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.

------=_Part_18589_9836364.1520372431311
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The C, C++ and POSIX standards require <span style=3D"font=
-family: courier\ new, monospace;">EOF</span> to be a negative constant exp=
ression<br>of type <span style=3D"font-family: courier\ new, monospace;">in=
t</span>. In all implementations I&#39;m aware of, <span style=3D"font-fami=
ly: courier\ new, monospace;">EOF =3D=3D -1</span>. The only exception<br>I=
 can find is that EOF was ^Z ( <span style=3D"font-family: courier\ new, mo=
nospace;">&#39;\x1A&#39;</span> ) in DOS, which is positive and therefore<b=
r>already nonconforming. There is no doubt a great deal of existing code re=
lying<br>on the assumption that <span style=3D"font-family: courier\ new, m=
onospace;">EOF =3D=3D -1</span>, so I think it makes sense to standardize t=
his<br>convention.<br><br>A more conservative alternative is to require tha=
t <span style=3D"font-family: courier\ new, monospace;">static_cast&lt;sign=
ed char&gt;(EOF)</span><br>be negative.<br><br>Best,<br>Ray</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/16a9359c-2d18-4085-9573-305aba68e75d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16a9359c-2d18-4085-9573-305aba68e75d=
%40isocpp.org</a>.<br />

------=_Part_18589_9836364.1520372431311--

------=_Part_18588_157040309.1520372431311--

.

Hi Ray,

On Tue, Mar 6, 2018 at 10:40 PM, Ray Hamel <rayghamel@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-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@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.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72%3Deh%2BKwojTT_MDqAWTwp5m7EMDgbF1%2BfLRE0ix0Mh5q9A%40mail.gmail.com.

.

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



--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1716243.0nMJBuYzoy%40tjmaciei-mobl1.

.

------=_Part_19901_424127736.1520403357293
Content-Type: multipart/alternative;
 boundary="----=_Part_19902_629069634.1520403357293"

------=_Part_19902_629069634.1520403357293
Content-Type: text/plain; charset="UTF-8"


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?

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1695e85c-ea74-49b1-b398-6f6f4f645c31%40isocpp.org.

------=_Part_19902_629069634.1520403357293
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, March 7, 2018 at 12:40:31 AM UTC+3, Ray =
Hamel wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">A=
 more conservative alternative is to require that <span>static_cast&lt;sign=
ed char&gt;(EOF)</span><br>be negative.<br></div></blockquote><div><br>It&#=
39;s a narrowing conversion. Functions like std::getc() have int as return =
type (not char!) intentionally to be able to retun &quot;next byte or EOF&q=
uot;. So you can compare only int value with EOF.<br><br> &gt; There is no =
doubt a great deal of existing code relying on the assumption that <span>EO=
F =3D=3D -1<br><br>Could you provide some code snippet that can&#39;t be wr=
itten not relying on exact value of EOF?<br></span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1695e85c-ea74-49b1-b398-6f6f4f645c31%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1695e85c-ea74-49b1-b398-6f6f4f645c31=
%40isocpp.org</a>.<br />

------=_Part_19902_629069634.1520403357293--

------=_Part_19901_424127736.1520403357293--

.

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

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



--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4742567.kt3bcQP1NG%40tjmaciei-mobl1.

.

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

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/p7p1mq%24ur0%241%40blaine.gmane.org.

.

------=_Part_1297_2090286919.1521081946563
Content-Type: multipart/alternative;
 boundary="----=_Part_1298_900179074.1521081946563"

------=_Part_1298_900179074.1521081946563
Content-Type: text/plain; charset="UTF-8"

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.

>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6c90b227-c618-4bb6-bc53-38d0fe1e5399%40isocpp.org.

------=_Part_1298_900179074.1521081946563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>EOF is truly forced like std::string::npos.</div><div=
>but histry persons use the &quot;#define EOF -1&quot;.</div><div>so EOF !=
=3D -1 is truth.</div><div>EOF is that graph.</div><div>number is undefined=
 is good.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6c90b227-c618-4bb6-bc53-38d0fe1e5399%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6c90b227-c618-4bb6-bc53-38d0fe1e5399=
%40isocpp.org</a>.<br />

------=_Part_1298_900179074.1521081946563--

------=_Part_1297_2090286919.1521081946563--

.

------=_Part_14658_1180395268.1521537514203
Content-Type: multipart/alternative;
 boundary="----=_Part_14659_365699921.1521537514203"

------=_Part_14659_365699921.1521537514203
Content-Type: text/plain; charset="UTF-8"



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.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2fe2d7b3-5a98-4626-b116-374a64aaad47%40isocpp.org.

------=_Part_14659_365699921.1521537514203
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Op woensdag 7 maart 2018 05:27:25 UTC+1 schreef Th=
iago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 6 Ma=
rch 2018 13:40:31 PST Ray Hamel wrote:
<br>&gt; A more conservative alternative is to require that static_cast&lt;=
signed
<br>&gt; char&gt;(EOF)
<br>&gt; be negative.
<br>
<br>That is unnecessary, since EOF is supposed to be a value outside of the=
 range=20
<br>of char.
<br></blockquote><div><br></div><div>Is it?</div><div>Range of char is ofte=
n -128..127, EOF is often -1.=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2fe2d7b3-5a98-4626-b116-374a64aaad47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2fe2d7b3-5a98-4626-b116-374a64aaad47=
%40isocpp.org</a>.<br />

------=_Part_14659_365699921.1521537514203--

------=_Part_14658_1180395268.1521537514203--

.

On Tuesday, 20 March 2018 17:18:34 CST olafvdspek@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

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



--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1855560.vHOCNjniRK%40tjmaciei-mobl1.

.