------=_Part_1736_601913448.1477465544923
Content-Type: multipart/alternative;
 boundary="----=_Part_1737_673616425.1477465544923"

------=_Part_1737_673616425.1477465544923
Content-Type: text/plain; charset=UTF-8

I'd like to make a case for fixing the undefined behaviour in the character
classification functions (is_digit, is_xdigit, is_alpha, is_alnum, etc.).
These function display undefined behaviour when confronted with negative
values, and it is entirely too easy to accidentally call them with such:

void main (int argc, const char *argv[])
{   if (argc)
        isdigit (argv [0][0]);
}

....done. At this point the user can call the program with some character
string containing any value above 0x7f, and assuming char acts as a signed
type (not uncommon), this program will exhibit undefined behaviour.

Since this undefined behaviour could pop up for any character string that
is not baked into the program itself (where, at least, the programmer can
know in advance that no characters with ASCII values above 0x7f are
present), we are left with the rather ridiculous situation that we must
'pre-classify' characters before we are allowed to classify them:

return is_safe_char (c) && is_digit (c);

....where is_safe_char would be something like:

bool is_safe_char (int c)
{   return c >= 0 && c <= 0x7f;
}

But why stop there? Writing your own character classification functions is
easy, after all. In my experience projects invariably fall into one of two
cathegories: those that write their own versions of the character
classification functions, and those that are blissfully unaware of the
problem and wonder why their software sometimes fails.

It has been made clear to me that some implementations use lookup tables
for the implementation of this group of functions. Such behaviour can be
maintained; all that is needed is a single additional test to see if the
input value lies somewhere within the table range or not. This test is
effectively already mandatory anyway (since not having it is pretty much a
guarantee of undefined behaviour somewhere down the line), so why not stick
it in the library where it belongs, instead of in every single piece of C++
code out there? It removes a risk not everyone is aware of and that is
completely unnecessary.

There may be other cases of undefined behaviour around that could be
removed with a trivial change, but these have been bugging me for years...




--
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/35daf87a-bf1d-46de-b16c-c2965fbadc8f%40isocpp.org.

------=_Part_1737_673616425.1477465544923
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to make a case for fixing the undefined behav=
iour in the character classification functions (is_digit, is_xdigit, is_alp=
ha, is_alnum, etc.). These function display undefined behaviour when confro=
nted with negative values, and it is entirely too easy to accidentally call=
 them with such:<br><br>void main (int argc, const char *argv[])<br>{=C2=A0=
=C2=A0 if (argc)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 isdigit (arg=
v [0][0]);<br>}<br><br>...done. At this point the user can call the program=
 with some character string containing any value above 0x7f, and assuming c=
har acts as a signed type (not uncommon), this program will exhibit undefin=
ed behaviour. <br><br>Since this undefined behaviour could pop up for any c=
haracter string that is not baked into the program itself (where, at least,=
 the programmer can know in advance that no characters with ASCII values ab=
ove 0x7f are present), we are left with the rather ridiculous situation tha=
t we must &#39;pre-classify&#39; characters before we are allowed to classi=
fy them:<br><br>return is_safe_char (c) &amp;&amp; is_digit (c);<br><br>...=
where is_safe_char would be something like:<br><br>bool is_safe_char (int c=
)<br>{=C2=A0=C2=A0 return c &gt;=3D 0 &amp;&amp; c &lt;=3D 0x7f;<br>}<br><b=
r>But why stop there? Writing your own character classification functions i=
s easy, after all. In my experience projects invariably fall into one of tw=
o cathegories: those that write their own versions of the character classif=
ication functions, and those that are blissfully unaware of the problem and=
 wonder why their software sometimes fails.<br>=C2=A0=C2=A0 <br>It has been=
 made clear to me that some implementations use lookup tables for the imple=
mentation of this group of functions. Such behaviour can be maintained; all=
 that is needed is a single additional test to see if the input value lies =
somewhere within the table range or not. This test is effectively already m=
andatory anyway (since not having it is pretty much a guarantee of undefine=
d behaviour somewhere down the line), so why not stick it in the library wh=
ere it belongs, instead of in every single piece of C++ code out there? It =
removes a risk not everyone is aware of and that is completely unnecessary.=
<br><br>There may be other cases of undefined behaviour around that could b=
e removed with a trivial change, but these have been bugging me for years..=
.. <br><br><br><br><br></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/35daf87a-bf1d-46de-b16c-c2965fbadc8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/35daf87a-bf1d-46de-b16c-c2965fbadc8f=
%40isocpp.org</a>.<br />

------=_Part_1737_673616425.1477465544923--

------=_Part_1736_601913448.1477465544923--

.

------=_Part_1398_56848167.1477465886441
Content-Type: multipart/alternative;
 boundary="----=_Part_1399_901643724.1477465886441"

------=_Part_1399_901643724.1477465886441
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 26, 2016 at 3:05:45 AM UTC-4, Hans Guijt wrote:
>
> I'd like to make a case for fixing the undefined behaviour in the
> character classification functions (is_digit, is_xdigit, is_alpha,
> is_alnum, etc.). These function display undefined behaviour when confronted
> with negative values, and it is entirely too easy to accidentally call them
> with such:
>
> void main (int argc, const char *argv[])
> {   if (argc)
>         isdigit (argv [0][0]);
> }
>
> ...done. At this point the user can call the program with some character
> string containing any value above 0x7f, and assuming char acts as a signed
> type (not uncommon), this program will exhibit undefined behaviour.
>
> Since this undefined behaviour could pop up for any character string that
> is not baked into the program itself (where, at least, the programmer can
> know in advance that no characters with ASCII values above 0x7f are
> present), we are left with the rather ridiculous situation that we must
> 'pre-classify' characters before we are allowed to classify them:
>
> return is_safe_char (c) && is_digit (c);
>
> ...where is_safe_char would be something like:
>
> bool is_safe_char (int c)
> {   return c >= 0 && c <= 0x7f;
> }
>
> But why stop there? Writing your own character classification functions is
> easy, after all. In my experience projects invariably fall into one of two
> cathegories: those that write their own versions of the character
> classification functions, and those that are blissfully unaware of the
> problem and wonder why their software sometimes fails.
>
> It has been made clear to me that some implementations use lookup tables
> for the implementation of this group of functions. Such behaviour can be
> maintained; all that is needed is a single additional test to see if the
> input value lies somewhere within the table range or not. This test is
> effectively already mandatory anyway (since not having it is pretty much a
> guarantee of undefined behaviour somewhere down the line), so why not stick
> it in the library where it belongs, instead of in every single piece of C++
> code out there? It removes a risk not everyone is aware of and that is
> completely unnecessary.
>
> There may be other cases of undefined behaviour around that could be
> removed with a trivial change, but these have been bugging me for years...
>
>
>
>
>
Because they are meant to be used as isdigit((unsigned char) c).

--
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/9e242562-aba1-4f8d-8e0a-b2de34f6a10b%40isocpp.org.

------=_Part_1399_901643724.1477465886441
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 26, 2016 at 3:05:45 AM UTC-4=
, Hans Guijt wrote:<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">I&#39;d like to make a case for fixing the undefined behaviour in the=
 character classification functions (is_digit, is_xdigit, is_alpha, is_alnu=
m, etc.). These function display undefined behaviour when confronted with n=
egative values, and it is entirely too easy to accidentally call them with =
such:<br><br>void main (int argc, const char *argv[])<br>{=C2=A0=C2=A0 if (=
argc)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 isdigit (argv [0][0]);<=
br>}<br><br>...done. At this point the user can call the program with some =
character string containing any value above 0x7f, and assuming char acts as=
 a signed type (not uncommon), this program will exhibit undefined behaviou=
r. <br><br>Since this undefined behaviour could pop up for any character st=
ring that is not baked into the program itself (where, at least, the progra=
mmer can know in advance that no characters with ASCII values above 0x7f ar=
e present), we are left with the rather ridiculous situation that we must &=
#39;pre-classify&#39; characters before we are allowed to classify them:<br=
><br>return is_safe_char (c) &amp;&amp; is_digit (c);<br><br>...where is_sa=
fe_char would be something like:<br><br>bool is_safe_char (int c)<br>{=C2=
=A0=C2=A0 return c &gt;=3D 0 &amp;&amp; c &lt;=3D 0x7f;<br>}<br><br>But why=
 stop there? Writing your own character classification functions is easy, a=
fter all. In my experience projects invariably fall into one of two cathego=
ries: those that write their own versions of the character classification f=
unctions, and those that are blissfully unaware of the problem and wonder w=
hy their software sometimes fails.<br>=C2=A0=C2=A0 <br>It has been made cle=
ar to me that some implementations use lookup tables for the implementation=
 of this group of functions. Such behaviour can be maintained; all that is =
needed is a single additional test to see if the input value lies somewhere=
 within the table range or not. This test is effectively already mandatory =
anyway (since not having it is pretty much a guarantee of undefined behavio=
ur somewhere down the line), so why not stick it in the library where it be=
longs, instead of in every single piece of C++ code out there? It removes a=
 risk not everyone is aware of and that is completely unnecessary.<br><br>T=
here may be other cases of undefined behaviour around that could be removed=
 with a trivial change, but these have been bugging me for years... <br><br=
><br><br><br></div></blockquote><div><br></div><div>Because they are meant =
to be used as isdigit((unsigned char) c).</div><div><br></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/9e242562-aba1-4f8d-8e0a-b2de34f6a10b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e242562-aba1-4f8d-8e0a-b2de34f6a10b=
%40isocpp.org</a>.<br />

------=_Part_1399_901643724.1477465886441--

------=_Part_1398_56848167.1477465886441--

.

------=_Part_1740_1014560637.1477466455111
Content-Type: multipart/alternative;
 boundary="----=_Part_1741_73607209.1477466455111"

------=_Part_1741_73607209.1477466455111
Content-Type: text/plain; charset=UTF-8


On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>
>
> Because they are meant to be used as isdigit((unsigned char) c).
>

Great, in that case I'm sure there is no opposition to changing the
signature to reflect this requirement? It's a much cleaner solution than
requiring a cast in every invocation, after all.


--
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/d24d9d41-d5ba-47ed-8e98-915f84063a92%40isocpp.org.

------=_Part_1741_73607209.1477466455111
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T.=
 C. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><br></div><div>Because they are meant to be used as isdigit((unsigned cha=
r) c).</div></div></blockquote><div>=C2=A0</div><div>Great, in that case I&=
#39;m sure there is no opposition to changing the signature to reflect this=
 requirement? It&#39;s a much cleaner solution than requiring a cast in eve=
ry invocation, after all.<br><br><br></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/d24d9d41-d5ba-47ed-8e98-915f84063a92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d24d9d41-d5ba-47ed-8e98-915f84063a92=
%40isocpp.org</a>.<br />

------=_Part_1741_73607209.1477466455111--

------=_Part_1740_1014560637.1477466455111--

.

------=_Part_1210_159454386.1477470384343
Content-Type: multipart/alternative;
 boundary="----=_Part_1211_2094825598.1477470384343"

------=_Part_1211_2094825598.1477470384343
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 26, 2016 at 10:20:55 AM UTC+3, Hans Guijt wrote:
>
>
> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>
>>
>> Because they are meant to be used as isdigit((unsigned char) c).
>>
>
> Great, in that case I'm sure there is no opposition to changing the
> signature to reflect this requirement? It's a much cleaner solution than
> requiring a cast in every invocation, after all.
>

But, this is a C function, C++ can't change it like that.

C++ has an alternative - the one with the locale.
Granted, it throws when the input is non-char, but it is not an UB.

--
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/5de60c76-a73b-4d29-bea5-a9eed19f4c67%40isocpp.org.

------=_Part_1211_2094825598.1477470384343
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 26, 2016 at 10:20:55 AM UTC+=
3, Hans Guijt wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><=
div>Because they are meant to be used as isdigit((unsigned char) c).</div><=
/div></blockquote><div>=C2=A0</div><div>Great, in that case I&#39;m sure th=
ere is no opposition to changing the signature to reflect this requirement?=
 It&#39;s a much cleaner solution than requiring a cast in every invocation=
, after all.<br></div></div></blockquote><div><br></div><div>But, this is a=
=C2=A0C function, C++ can&#39;t change it like that. </div><div><br></div><=
div>C++ has an alternative - the one with the locale. </div><div>Granted, i=
t throws when the input is non-char, but it is not an UB.=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/5de60c76-a73b-4d29-bea5-a9eed19f4c67%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5de60c76-a73b-4d29-bea5-a9eed19f4c67=
%40isocpp.org</a>.<br />

------=_Part_1211_2094825598.1477470384343--

------=_Part_1210_159454386.1477470384343--

.

------=_Part_1162_775423578.1477470517220
Content-Type: multipart/alternative;
 boundary="----=_Part_1163_228402737.1477470517220"

------=_Part_1163_228402737.1477470517220
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:
>
>
> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>
>>
>> Because they are meant to be used as isdigit((unsigned char) c).
>>
>
> Great, in that case I'm sure there is no opposition to changing the
> signature to reflect this requirement? It's a much cleaner solution than
> requiring a cast in every invocation, after all.
>
>
>
The reason they take int is because they also accept EOF. That's C's style,
for better or worse.

In any event, there's no way in hell C++ is going to change this. It's a
massive C compatibility break.

--
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/c976d139-ae31-4756-96a6-30a69d81f14d%40isocpp.org.

------=_Part_1163_228402737.1477470517220
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4=
, Hans Guijt wrote:<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"><br>On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div=
>Because they are meant to be used as isdigit((unsigned char) c).</div></di=
v></blockquote><div>=C2=A0</div><div>Great, in that case I&#39;m sure there=
 is no opposition to changing the signature to reflect this requirement? It=
&#39;s a much cleaner solution than requiring a cast in every invocation, a=
fter all.<br><br><br></div></div></blockquote><div><br></div><div>The reaso=
n they take int is because they also accept EOF. That&#39;s C&#39;s style, =
for better or worse.</div><div><br></div><div>In any event, there&#39;s no =
way in hell C++ is going to change this. It&#39;s a massive C compatibility=
 break.</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/c976d139-ae31-4756-96a6-30a69d81f14d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c976d139-ae31-4756-96a6-30a69d81f14d=
%40isocpp.org</a>.<br />

------=_Part_1163_228402737.1477470517220--

------=_Part_1162_775423578.1477470517220--

.

--089e013d1d9c8bef1a053fc4788e
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 26, 2016 at 4:28 AM, T. C. <rs2740@gmail.com> wrote:

>
>
> On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:
>>
>>
>> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>>
>>>
>>> Because they are meant to be used as isdigit((unsigned char) c).
>>>
>>
>> Great, in that case I'm sure there is no opposition to changing the
>> signature to reflect this requirement? It's a much cleaner solution than
>> requiring a cast in every invocation, after all.
>>
>>
>>
> The reason they take int is because they also accept EOF. That's C's
> style, for better or worse.
>
> In any event, there's no way in hell C++ is going to change this. It's a
> massive C compatibility break.
>

We could maybe overload the function:

int isdigit(int c);
bool isdigit(char c);

No idea if that is a good idea.

>
> --
Be seeing you,
Tony

--
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/CAOHCbiu0Hd7LsMkKGcvxvo7h3TJzjZAuXPWxNT0WuESUfrFCaw%40mail.gmail.com.

--089e013d1d9c8bef1a053fc4788e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Oct 26, 2016 at 4:28 AM, T. C. <span dir=3D"ltr">&lt;<a href=3D=
"mailto:rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""=
><br><br>On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Wednesda=
y, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Because they are mea=
nt to be used as isdigit((unsigned char) c).</div></div></blockquote><div>=
=C2=A0</div><div>Great, in that case I&#39;m sure there is no opposition to=
 changing the signature to reflect this requirement? It&#39;s a much cleane=
r solution than requiring a cast in every invocation, after all.<br><br><br=
></div></div></blockquote><div><br></div></span><div>The reason they take i=
nt is because they also accept EOF. That&#39;s C&#39;s style, for better or=
 worse.</div><div><br></div><div>In any event, there&#39;s no way in hell C=
++ is going to change this. It&#39;s a massive C compatibility break.</div>=
</div></blockquote><div><br></div><div>We could maybe overload the function=
:<br><br></div><div>int isdigit(int c);<br></div><div>bool isdigit(char c);=
<br><br></div><div>No idea if that is a good idea.<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><span class=3D"">

<p></p></span><br></blockquote></div>-- <br><div class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br>=
</div>Tony<br></div></div>
</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/CAOHCbiu0Hd7LsMkKGcvxvo7h3TJzjZAuXPWx=
NT0WuESUfrFCaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu0Hd7LsMkK=
Gcvxvo7h3TJzjZAuXPWxNT0WuESUfrFCaw%40mail.gmail.com</a>.<br />

--089e013d1d9c8bef1a053fc4788e--

.

------=_Part_1058_1732431302.1477496046887
Content-Type: multipart/alternative;
 boundary="----=_Part_1059_2124183137.1477496046887"

------=_Part_1059_2124183137.1477496046887
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 26, 2016 at 9:19:15 AM UTC-4, Tony V E wrote:
>
>
>
> On Wed, Oct 26, 2016 at 4:28 AM, T. C. <rs2...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:
>>>
>>>
>>> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>>>
>>>>
>>>> Because they are meant to be used as isdigit((unsigned char) c).
>>>>
>>>
>>> Great, in that case I'm sure there is no opposition to changing the
>>> signature to reflect this requirement? It's a much cleaner solution than
>>> requiring a cast in every invocation, after all.
>>>
>>>
>>>
>> The reason they take int is because they also accept EOF. That's C's
>> style, for better or worse.
>>
>> In any event, there's no way in hell C++ is going to change this. It's a
>> massive C compatibility break.
>>
>
> We could maybe overload the function:
>
> int isdigit(int c);
> bool isdigit(char c);
>
> No idea if that is a good idea.
>
>>
>> --
> Be seeing you,
> Tony
>

That breaks anything that expects ::isdigit to be unambiguous (e.g., pass
it to an algorithm).

--
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/1314a997-2f74-4b52-9755-bc9d1deb6982%40isocpp.org.

------=_Part_1059_2124183137.1477496046887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 26, 2016 at 9:19:15 AM UTC-4=
, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div><br><div class=3D"gmail_quote">On Wed, Oct 26, 2016 at 4:28 AM=
, T. C. <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"AXnNJDx0AQAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">rs2...@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Wednesday, October=
 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><br>On Wednesday, October 26, 2016 at 9:11:26=
 AM UTC+2, T. C. wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div><br></div><div>Because they are meant to be used as isdigit((unsi=
gned char) c).</div></div></blockquote><div>=C2=A0</div><div>Great, in that=
 case I&#39;m sure there is no opposition to changing the signature to refl=
ect this requirement? It&#39;s a much cleaner solution than requiring a cas=
t in every invocation, after all.<br><br><br></div></div></blockquote><div>=
<br></div></span><div>The reason they take int is because they also accept =
EOF. That&#39;s C&#39;s style, for better or worse.</div><div><br></div><di=
v>In any event, there&#39;s no way in hell C++ is going to change this. It&=
#39;s a massive C compatibility break.</div></div></blockquote><div><br></d=
iv><div>We could maybe overload the function:<br><br></div><div>int isdigit=
(int c);<br></div><div>bool isdigit(char c);<br><br></div><div>No idea if t=
hat is a good idea.<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>

<p></p></span><br></blockquote></div>-- <br><div><div dir=3D"ltr"><div>Be s=
eeing you,<br></div>Tony<br></div></div></div></div></blockquote><div><br><=
/div><div>That breaks anything that expects ::isdigit=C2=A0to be unambiguou=
s (e.g., pass it to an algorithm).=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/1314a997-2f74-4b52-9755-bc9d1deb6982%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1314a997-2f74-4b52-9755-bc9d1deb6982=
%40isocpp.org</a>.<br />

------=_Part_1059_2124183137.1477496046887--

------=_Part_1058_1732431302.1477496046887--

.

--001a1143f082e0e3bc053fc681c1
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 26, 2016 at 11:34 AM, T. C. <rs2740@gmail.com> wrote:

>
>
> On Wednesday, October 26, 2016 at 9:19:15 AM UTC-4, Tony V E wrote:
>>
>>
>>
>> On Wed, Oct 26, 2016 at 4:28 AM, T. C. <rs2...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:
>>>>
>>>>
>>>> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>>>>
>>>>>
>>>>> Because they are meant to be used as isdigit((unsigned char) c).
>>>>>
>>>>
>>>> Great, in that case I'm sure there is no opposition to changing the
>>>> signature to reflect this requirement? It's a much cleaner solution than
>>>> requiring a cast in every invocation, after all.
>>>>
>>>>
>>>>
>>> The reason they take int is because they also accept EOF. That's C's
>>> style, for better or worse.
>>>
>>> In any event, there's no way in hell C++ is going to change this. It's a
>>> massive C compatibility break.
>>>
>>
>> We could maybe overload the function:
>>
>> int isdigit(int c);
>> bool isdigit(char c);
>>
>> No idea if that is a good idea.
>>
>>>
>>> --
>> Be seeing you,
>> Tony
>>
>
> That breaks anything that expects ::isdigit to be unambiguous (e.g., pass
> it to an algorithm).
>

I thought the standard doesn't sanction such uses of standard library
facilities, unless I'm mistaken.

--
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/CANh8DEmWMr0u%3D%3DFPgaw4mnpv1UHCMnPfvonhJpwjTxuxw%2BLa%3Dg%40mail.gmail.com.

--001a1143f082e0e3bc053fc681c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Oct 26, 2016 at 11:34 AM, T. C. <span dir=3D"ltr">&lt;<a href=
=3D"mailto:rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On We=
dnesday, October 26, 2016 at 9:19:15 AM UTC-4, Tony V E wrote:<span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br=
><div class=3D"gmail_quote">On Wed, Oct 26, 2016 at 4:28 AM, T. C. <span di=
r=3D"ltr">&lt;<a rel=3D"nofollow">rs2...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><br><br>On Wednesday=
, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br>On Wednesday, October 26, 2016 =
at 9:11:26 AM UTC+2, T. C. wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><br></div><div>Because they are meant to be used as isd=
igit((unsigned char) c).</div></div></blockquote><div>=C2=A0</div><div>Grea=
t, in that case I&#39;m sure there is no opposition to changing the signatu=
re to reflect this requirement? It&#39;s a much cleaner solution than requi=
ring a cast in every invocation, after all.<br><br><br></div></div></blockq=
uote><div><br></div></span><div>The reason they take int is because they al=
so accept EOF. That&#39;s C&#39;s style, for better or worse.</div><div><br=
></div><div>In any event, there&#39;s no way in hell C++ is going to change=
 this. It&#39;s a massive C compatibility break.</div></div></blockquote><d=
iv><br></div><div>We could maybe overload the function:<br><br></div><div>i=
nt isdigit(int c);<br></div><div>bool isdigit(char c);<br><br></div><div>No=
 idea if that is a good idea.<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
>

<p></p></span><br></blockquote></div>-- <br><div><div dir=3D"ltr"><div>Be s=
eeing you,<br></div>Tony<br></div></div></div></div></blockquote><div><br><=
/div></span><div>That breaks anything that expects ::isdigit=C2=A0to be una=
mbiguous (e.g., pass it to an algorithm).=C2=A0</div></div></blockquote><di=
v><br></div><div>I thought the standard doesn&#39;t sanction such uses of s=
tandard library facilities, unless I&#39;m mistaken.=C2=A0</div></div></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/CANh8DEmWMr0u%3D%3DFPgaw4mnpv1UHCMnPf=
vonhJpwjTxuxw%2BLa%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmW=
Mr0u%3D%3DFPgaw4mnpv1UHCMnPfvonhJpwjTxuxw%2BLa%3Dg%40mail.gmail.com</a>.<br=
 />

--001a1143f082e0e3bc053fc681c1--

.

------=_Part_1889_685078059.1477497331824
Content-Type: multipart/alternative;
 boundary="----=_Part_1890_1139757925.1477497331824"

------=_Part_1890_1139757925.1477497331824
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 26, 2016 at 11:45:09 AM UTC-4, Matt Calabrese wrote:
>
>
>
> On Wed, Oct 26, 2016 at 11:34 AM, T. C. <rs2...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Wednesday, October 26, 2016 at 9:19:15 AM UTC-4, Tony V E wrote:
>>>
>>>
>>>
>>> On Wed, Oct 26, 2016 at 4:28 AM, T. C. <rs2...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, October 26, 2016 at 3:20:55 AM UTC-4, Hans Guijt wrote:
>>>>>
>>>>>
>>>>> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>>>>>>
>>>>>>
>>>>>> Because they are meant to be used as isdigit((unsigned char) c).
>>>>>>
>>>>>
>>>>> Great, in that case I'm sure there is no opposition to changing the
>>>>> signature to reflect this requirement? It's a much cleaner solution than
>>>>> requiring a cast in every invocation, after all.
>>>>>
>>>>>
>>>>>
>>>> The reason they take int is because they also accept EOF. That's C's
>>>> style, for better or worse.
>>>>
>>>> In any event, there's no way in hell C++ is going to change this. It's
>>>> a massive C compatibility break.
>>>>
>>>
>>> We could maybe overload the function:
>>>
>>> int isdigit(int c);
>>> bool isdigit(char c);
>>>
>>> No idea if that is a good idea.
>>>
>>>>
>>>> --
>>> Be seeing you,
>>> Tony
>>>
>>
>> That breaks anything that expects ::isdigit to be unambiguous (e.g., pass
>> it to an algorithm).
>>
>
> I thought the standard doesn't sanction such uses of standard library
> facilities, unless I'm mistaken.
>

I don't recall anything that says you can't do it. (You can't take the
address of *member* functions, but nonmembers is another matter.)

In any event, it can also make existing calls ambiguous (with an argument
that converts equally well to int and char), so there's a need to check how
much this will break.

--
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/0f446da6-6374-487e-b41e-5435f0dfa2c6%40isocpp.org.

------=_Part_1890_1139757925.1477497331824
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 26, 2016 at 11:45:09 AM UTC-=
4, Matt Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Wed, Oct 26, 2016 at =
11:34 AM, T. C. <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"W1u9WzJ8AQAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">rs2...@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, Octob=
er 26, 2016 at 9:19:15 AM UTC-4, Tony V E wrote:<span><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote"=
>On Wed, Oct 26, 2016 at 4:28 AM, T. C. <span dir=3D"ltr">&lt;<a rel=3D"nof=
ollow">rs2...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><span><br><br>On Wednesday, October 26, 2016 at 3:20:=
55 AM UTC-4, Hans Guijt wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br>On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></di=
v><div>Because they are meant to be used as isdigit((unsigned char) c).</di=
v></div></blockquote><div>=C2=A0</div><div>Great, in that case I&#39;m sure=
 there is no opposition to changing the signature to reflect this requireme=
nt? It&#39;s a much cleaner solution than requiring a cast in every invocat=
ion, after all.<br><br><br></div></div></blockquote><div><br></div></span><=
div>The reason they take int is because they also accept EOF. That&#39;s C&=
#39;s style, for better or worse.</div><div><br></div><div>In any event, th=
ere&#39;s no way in hell C++ is going to change this. It&#39;s a massive C =
compatibility break.</div></div></blockquote><div><br></div><div>We could m=
aybe overload the function:<br><br></div><div>int isdigit(int c);<br></div>=
<div>bool isdigit(char c);<br><br></div><div>No idea if that is a good idea=
..<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span>

<p></p></span><br></blockquote></div>-- <br><div><div dir=3D"ltr"><div>Be s=
eeing you,<br></div>Tony<br></div></div></div></div></blockquote><div><br><=
/div></span><div>That breaks anything that expects ::isdigit=C2=A0to be una=
mbiguous (e.g., pass it to an algorithm).=C2=A0</div></div></blockquote><di=
v><br></div><div>I thought the standard doesn&#39;t sanction such uses of s=
tandard library facilities, unless I&#39;m mistaken.=C2=A0</div></div></div=
></div></blockquote><div><br></div><div>I don&#39;t recall anything that sa=
ys you can&#39;t do it. (You can&#39;t take the address of *member* functio=
ns, but nonmembers is another matter.)</div><div><br></div><div>In any even=
t, it can also make existing calls ambiguous (with an argument that convert=
s equally well to int and char), so there&#39;s a need to check how much th=
is will break.</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/0f446da6-6374-487e-b41e-5435f0dfa2c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f446da6-6374-487e-b41e-5435f0dfa2c6=
%40isocpp.org</a>.<br />

------=_Part_1890_1139757925.1477497331824--

------=_Part_1889_685078059.1477497331824--

.

On 2016-10-26 09:20, Hans Guijt wrote:
>
> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
>
>
>     Because they are meant to be used as isdigit((unsigned char) c).
>
>
> Great, in that case I'm sure there is no opposition to changing the
> signature to reflect this requirement? It's a much cleaner solution than
> requiring a cast in every invocation, after all.
>

This goes all the way back to "implicit int" in K&R C, where a call f(c)
to an undeclared function f was assumed to implicitly declare "int f(int)".

If that wasn't fixable in the 1980's, because of expected code breakage,
it is WAY too late to change that now.


     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/nur234%24m5a%241%40blaine.gmane.org.

.

On quarta-feira, 26 de outubro de 2016 00:20:54 PDT Hans Guijt wrote:
> On Wednesday, October 26, 2016 at 9:11:26 AM UTC+2, T. C. wrote:
> > Because they are meant to be used as isdigit((unsigned char) c).
>
> Great, in that case I'm sure there is no opposition to changing the
> signature to reflect this requirement? It's a much cleaner solution than
> requiring a cast in every invocation, after all.

The ctype functions are required to work for EOF too. So you can't use
unsigned char, as you need one more representable value besides all possible
unsigned char values.

--
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/1866299.zrCQmoYHp2%40tjmaciei-mobl1.

.

On quarta-feira, 26 de outubro de 2016 08:34:06 PDT T. C. wrote:
> That breaks anything that expects ::isdigit to be unambiguous (e.g., pass
> it to an algorithm).

Is it even required to be a function in the first place? Many implementations
in C define it to be a macro that reads from an array. Even glibc:

# define __isctype(c, type) \
  ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
[...]
# define isdigit(c) __isctype((c), _ISdigit)

Though glibc only does that in C mode, not in C++.
--
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/1612025.rPhQNZgPHV%40tjmaciei-mobl1.

.

------=_Part_358_1045427501.1477616426407
Content-Type: multipart/alternative;
 boundary="----=_Part_359_449600356.1477616426407"

------=_Part_359_449600356.1477616426407
Content-Type: text/plain; charset=UTF-8


>
> Is [isdigit] even required to be a function in the first place?
>

I think so; isdigit is described as a function and its synopsis is a
function declaration. But in C (and maybe C++), there may also be a macro
if it can be defined in such a way that the argument is evaluated only once:

"[...] Any function declared in a header may be additionally implemented as
a function-like macro [...] Any invocation of a library function that is
implemented as a macro shall expand to code that evaluates each of its
arguments exactly once, fully protected by parentheses where necessary, so
it is generally safe to use arbitrary expressions as arguments. [...]" (C,
7.1.4/1)

"Names that are defined as functions in C shall be defined as functions in
the C ++ standard library." (C++, [headers]/6)

--
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/aa0feb46-de22-4839-90a3-90189935181c%40isocpp.org.

------=_Part_359_449600356.1477616426407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Is [isdigit] =
even required to be a function in the first place?<br></blockquote><div><br=
>I think so; isdigit is described as a function and its synopsis is a funct=
ion declaration. But in C (and maybe C++), there may also be a macro if it =
can be defined in such a way that the argument is evaluated only once:<br><=
br>&quot;[...] Any function declared in a header may be additionally implem=
ented as a function-like macro [...] Any invocation of a library function t=
hat is implemented as a macro shall expand to code that evaluates each of i=
ts arguments exactly once, fully protected by parentheses where necessary, =
so it is generally safe to use arbitrary expressions as arguments. [...]&qu=
ot; (C, 7.1.4/1)<br><br>&quot;Names that are defined as functions in C shal=
l be defined as functions in the C ++ standard library.&quot; (C++, [header=
s]/6)</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/aa0feb46-de22-4839-90a3-90189935181c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa0feb46-de22-4839-90a3-90189935181c=
%40isocpp.org</a>.<br />

------=_Part_359_449600356.1477616426407--

------=_Part_358_1045427501.1477616426407--

.

------=_Part_305_1642736588.1477616738489
Content-Type: multipart/alternative;
 boundary="----=_Part_306_635862812.1477616738489"

------=_Part_306_635862812.1477616738489
Content-Type: text/plain; charset=UTF-8


On Thursday, October 27, 2016 at 9:00:26 PM UTC-4, Chris Hallock wrote:
>
> "Names that are defined as functions in C shall be defined as functions in
> the C ++ standard library." (C++, [headers]/6)
>

The footnote in the very same paragraph explains that "This disallows the
practice, allowed in C, of providing a masking macro in addition to the
function prototype. "

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/d2a97408-3e34-4878-9797-9b532070984b%40isocpp.org.

------=_Part_306_635862812.1477616738489
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Thursday, October 27, 2016 at 9:00:26 PM UTC-4, Chr=
is Hallock wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>&quot;Names that are defined as functions in C shall be defined as=
 functions in the C ++ standard library.&quot; (C++, [headers]/6)</div></di=
v></blockquote><div><br></div>The footnote in the very same paragraph expla=
ins that &quot;This disallows the practice, allowed in C, of providing a ma=
sking macro in addition to the function prototype. &quot;<div><br><div styl=
e=3D"z-index: 2; opacity: 1; transform: translate(1081.56px, 581.467px);" c=
lass=3D"_9b5ef6-textarea_btn _9b5ef6-show _9b5ef6-errors _9b5ef6-has_errors=
 _9b5ef6-field_hovered" data-grammarly-reactid=3D".0"><div class=3D"_9b5ef6=
-transform_wrap" data-grammarly-reactid=3D".0.0"><div title=3D"Found 1 erro=
r in text" class=3D"_9b5ef6-status" data-grammarly-reactid=3D".0.0.0">1</di=
v></div></div></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/d2a97408-3e34-4878-9797-9b532070984b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2a97408-3e34-4878-9797-9b532070984b=
%40isocpp.org</a>.<br />

------=_Part_306_635862812.1477616738489--

------=_Part_305_1642736588.1477616738489--

.