------=_Part_434_1425329086.1435169337820
Content-Type: multipart/alternative;
 boundary="----=_Part_435_325866117.1435169337820"

------=_Part_435_325866117.1435169337820
Content-Type: text/plain; charset=UTF-8

In the parsing numbers thread we have been discussing about prefixes for
bases. John brought up a Python proposal proposing some updates to the
rules for octal numbers.
https://www.python.org/dev/peps/pep-3127/

If I read the proposal correctly the idea (for Python 3) was to add 0o as a
prefix for octal numbers and to disallow the old prefix by disallowing
leading zeros..
The arguments seem sound and I'm wondering, should we propose the same for
C++?

Allowing 0o for octal seems simple.
Deprecating 0 is a bit harder..

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>In the parsing numbers thread we have been discussing=
 about prefixes for bases. John brought up a Python proposal proposing some=
 updates to the rules for octal numbers.</div><div>https://www.python.org/d=
ev/peps/pep-3127/<br></div><div><br></div><div>If I read the proposal corre=
ctly the idea (for Python 3) was to add 0o as a prefix for octal numbers an=
d to disallow the old prefix by disallowing leading zeros..</div><div>The a=
rguments seem sound and I'm wondering, should we propose the same for C++?<=
/div><div><br></div><div>Allowing 0o for octal seems simple.</div><div>Depr=
ecating 0 is a bit harder..</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_435_325866117.1435169337820--
------=_Part_434_1425329086.1435169337820--

.

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

Deprecating 0 just isn't going to happen, I think.
So the benefit of adding 0o seems low.  And 0O is hard to read (although it
just looks like 00 and the meaning is the same).

Is it worth committee time? I personally don't think so.

On Wed, Jun 24, 2015 at 2:08 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> In the parsing numbers thread we have been discussing about prefixes for
> bases. John brought up a Python proposal proposing some updates to the
> rules for octal numbers.
> https://www.python.org/dev/peps/pep-3127/
>
> If I read the proposal correctly the idea (for Python 3) was to add 0o as
> a prefix for octal numbers and to disallow the old prefix by disallowing
> leading zeros..
> The arguments seem sound and I'm wondering, should we propose the same for
> C++?
>
> Allowing 0o for octal seems simple.
> Deprecating 0 is a bit harder..
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><div>Deprecating 0 just isn&#39;t going to happen, I =
think.<br></div>So the benefit of adding 0o seems low.=C2=A0 And 0O is hard=
 to read (although it just looks like 00 and the meaning is the same).<br><=
br></div>Is it worth committee time? I personally don&#39;t think so.<br></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 2=
4, 2015 at 2:08 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"mail=
to:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@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"><div>In the p=
arsing numbers thread we have been discussing about prefixes for bases. Joh=
n brought up a Python proposal proposing some updates to the rules for octa=
l numbers.</div><div><a href=3D"https://www.python.org/dev/peps/pep-3127/" =
target=3D"_blank">https://www.python.org/dev/peps/pep-3127/</a><br></div><d=
iv><br></div><div>If I read the proposal correctly the idea (for Python 3) =
was to add 0o as a prefix for octal numbers and to disallow the old prefix =
by disallowing leading zeros..</div><div>The arguments seem sound and I&#39=
;m wondering, should we propose the same for C++?</div><div><br></div><div>=
Allowing 0o for octal seems simple.</div><div>Deprecating 0 is a bit harder=
...</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div></fon=
t></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01227ec0a75eae051947c5d7--

.

On 06/24/2015 08:08 PM, Olaf van der Spek wrote:
> In the parsing numbers thread we have been discussing about prefixes for bases. John brought up a Python proposal proposing some updates to the rules for octal numbers.
> https://www.python.org/dev/peps/pep-3127/
>
> If I read the proposal correctly the idea (for Python 3) was to add 0o as a prefix for octal numbers and to disallow the old prefix by disallowing leading zeros..
> The arguments seem sound and I'm wondering, should we propose the same for C++?
>
> Allowing 0o for octal seems simple.

Yes.

> Deprecating 0 is a bit harder..

Some people think that "deprecation" means we have the considered
intention to remove the feature in one of the next standards.
I'm dubious whether we'll ever be able to remove the
0 prefix for octal numbers from C and C++.

I'd love to have a way to express octal literals in a more obvious
way than with a leading 0 (as rare as octals are in my code).

Jens

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------040800010903060009010602
Content-Type: text/plain; charset=UTF-8

This email contains language some might find crude and offensive. My
apologies in advance.

On 24/06/15 21:36, Jens Maurer wrote:
> I'd love to have a way to express octal literals in a more obvious way
> than with a leading 0 (as rare as octals are in my code). Jens
#define OCT(num) (0##num)

Shachar

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------040800010903060009010602
Content-Type: text/html; charset=UTF-8

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">This email contains language some might
      find crude and offensive. My apologies in advance.<br>
      <br>
      On 24/06/15 21:36, Jens Maurer wrote:<br>
    </div>
    <blockquote cite="mid:558AF8B0.5090800@gmx.net" type="cite">
      I'd love to have a way to express octal literals in a more obvious
      way than with a leading 0 (as rare as octals are in my code).
      Jens
    </blockquote>
    #define OCT(num) (0##num)<br>
    <br>
    Shachar<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------040800010903060009010602--

.

------=_Part_968_1831611757.1435176351339
Content-Type: multipart/alternative;
 boundary="----=_Part_969_1868203801.1435176351339"

------=_Part_969_1868203801.1435176351339
Content-Type: text/plain; charset=UTF-8

Actually, this proposal would have 0o0 or 0O0 for 0 which looks like an
emiticon of some sort.  This wouldn't scream Octal!

I thought about 0c or 0C prefixes but that's probably just too cute.

I don't think the committee would touch either.  I could be wrong though.
They hashed out digit separators.

On Wednesday, June 24, 2015 at 2:35:35 PM UTC-4, Tony V E wrote:
>
> Deprecating 0 just isn't going to happen, I think.
> So the benefit of adding 0o seems low.  And 0O is hard to read (although
> it just looks like 00 and the meaning is the same).
>
> Is it worth committee time? I personally don't think so.
>
> On Wed, Jun 24, 2015 at 2:08 PM, Olaf van der Spek <olafv...@gmail.com
> <javascript:>> wrote:
>
>> In the parsing numbers thread we have been discussing about prefixes for
>> bases. John brought up a Python proposal proposing some updates to the
>> rules for octal numbers.
>> https://www.python.org/dev/peps/pep-3127/
>>
>> If I read the proposal correctly the idea (for Python 3) was to add 0o as
>> a prefix for octal numbers and to disallow the old prefix by disallowing
>> leading zeros..
>> The arguments seem sound and I'm wondering, should we propose the same
>> for C++?
>>
>> Allowing 0o for octal seems simple.
>> Deprecating 0 is a bit harder..
>>
>>  --
>>
>> ---
>> 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Actually, this proposal would have 0o0 or 0O0 for 0 which =
looks like an emiticon of some sort.&nbsp; This wouldn't scream Octal!<br><=
br>I thought about 0c or 0C prefixes but that's probably just too cute.<br>=
<br>I don't think the committee would touch either.&nbsp; I could be wrong =
though.&nbsp; They hashed out digit separators.<br><br>On Wednesday, June 2=
4, 2015 at 2:35:35 PM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div>Deprecating 0 just isn't going to =
happen, I think.<br></div>So the benefit of adding 0o seems low.&nbsp; And =
0O is hard to read (although it just looks like 00 and the meaning is the s=
ame).<br><br></div>Is it worth committee time? I personally don't think so.=
<br></div><div><br><div class=3D"gmail_quote">On Wed, Jun 24, 2015 at 2:08 =
PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Zdvx_wnISbMJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">olafv...@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>In the parsing numbers thread=
 we have been discussing about prefixes for bases. John brought up a Python=
 proposal proposing some updates to the rules for octal numbers.</div><div>=
<a href=3D"https://www.python.org/dev/peps/pep-3127/" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-3127%2F\46sa\75D\46sntz\0751\=
46usg\75AFQjCNE4Ow68HQqrib34aQpLkzXcAXTvXg';return true;" onclick=3D"this.h=
ref=3D'https://www.google.com/url?q\75https%3A%2F%2Fwww.python.org%2Fdev%2F=
peps%2Fpep-3127%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNE4Ow68HQqrib34aQpLkzX=
cAXTvXg';return true;">https://www.python.org/dev/<wbr>peps/pep-3127/</a><b=
r></div><div><br></div><div>If I read the proposal correctly the idea (for =
Python 3) was to add 0o as a prefix for octal numbers and to disallow the o=
ld prefix by disallowing leading zeros..</div><div>The arguments seem sound=
 and I'm wondering, should we propose the same for C++?</div><div><br></div=
><div>Allowing 0o for octal seems simple.</div><div>Deprecating 0 is a bit =
harder..</div><span><font color=3D"#888888"><div><br></div></font></span></=
div><span><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Zdvx_wnISbMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Zdvx_wnISbMJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_969_1868203801.1435176351339--
------=_Part_968_1831611757.1435176351339--

.

On 2015-06-24 14:08, Olaf van der Spek wrote:
> In the parsing numbers thread we have been discussing about prefixes for
> bases. John brought up a Python proposal proposing some updates to the
> rules for octal numbers.
> https://www.python.org/dev/peps/pep-3127/

To be clear, I believe this proposal was indeed implemented as given for
Python 3.  A little playing around in a Python 3 shell can convince you
of this.

> If I read the proposal correctly the idea (for Python 3) was to add 0o
> as a prefix for octal numbers and to disallow the old prefix by
> disallowing leading zeros..
>
> The arguments seem sound and I'm wondering, should we propose the same
> for C++?
>
> Allowing 0o for octal seems simple.
> Deprecating 0 is a bit harder..

I would love to see 0o as an octal prefix.  Deprecating 0 is probably a
non-starter, but we could aspire to not perpetuate it in new functions
(such as any new conversion functions).

John

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-06-24 20:35 GMT+02:00 Tony V E <tvaneerd@gmail.com>:
> Deprecating 0 just isn't going to happen, I think.

Compiler warnings might be a good start.

People just don't expect 010 == 8 to be true.

> So the benefit of adding 0o seems low.  And 0O is hard to read (although it
> just looks like 00 and the meaning is the same).

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_F0149972-3089-4638-8BE1-0198EC197B86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9326, at 12:51 PM, Olaf van der Spek <olafvdspek=
@gmail.com <mailto:olafvdspek@gmail.com>> wrote:
>=20
> 2015-06-24 20:35 GMT+02:00 Tony V E <tvaneerd@gmail.com <mailto:tvaneerd@=
gmail.com>>:
>> Deprecating 0 just isn't going to happen, I think.
>=20
> Compiler warnings might be a good start.
>=20
> People just don't expect 010 =3D=3D 8 to be true.

Except when calling POSIX ::stat, which seems beyond the reach of WG21. Wha=
t=E2=80=99s the status of namespace posix, by the way? Has interest dwindle=
d to nothing?

Unfortunately, it looks like the octal constants went from "File mode bits =
and the contents of the remaining members of the stat structure are unspeci=
fied,=E2=80=9D in POSIX:2004 <http://pubs.opengroup.org/onlinepubs/00969539=
9/basedefs/sys/stat.h.html>, to "The <sys/stat.h> header shall define the f=
ollowing symbolic constants for the file mode bits encoded in type mode_t, =
with the indicated numeric values,=E2=80=9D in POSIX:2013 <http://pubs.open=
group.org/onlinepubs/9699919799/basedefs/sys_stat.h.html>. There might have=
 been a window in the C++03 timeframe when deprecation of octal would have =
encouraged users to conform to POSIX, but now the tables have turned.

Perhaps octal numbers should only exist inside extern "C" {}?

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_F0149972-3089-4638-8BE1-0198EC197B86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9306=E2=80=9326, at 12:51 PM, Olaf van der Spek &lt;<a href=3D"mailto:o=
lafvdspek@gmail.com" class=3D"">olafvdspek@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><div class=3D"">2015-06-24 20:35 GMT+=
02:00 Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" class=3D"">tvaneer=
d@gmail.com</a>&gt;:<br class=3D""><blockquote type=3D"cite" class=3D"">Dep=
recating 0 just isn't going to happen, I think.<br class=3D""></blockquote>=
<br class=3D"">Compiler warnings might be a good start.<br class=3D""><br c=
lass=3D"">People just don't expect 010 =3D=3D 8 to be true.<br class=3D""><=
/div></blockquote></div><br class=3D""><div class=3D"">Except when calling =
POSIX <font face=3D"Courier" class=3D"">::stat</font>, which seems beyond t=
he reach of WG21. What=E2=80=99s the status of <font face=3D"Courier" class=
=3D"">namespace posix</font>, by the way? Has interest dwindled to nothing?=
</div><div class=3D""><br class=3D""></div><div class=3D"">Unfortunately, i=
t looks like the octal constants went from "File mode bits and the contents=
 of the remaining members of the <font face=3D"Courier" class=3D"">stat</fo=
nt> structure are
unspecified,=E2=80=9D in&nbsp;<a href=3D"http://pubs.opengroup.org/onlinepu=
bs/009695399/basedefs/sys/stat.h.html" class=3D"">POSIX:2004</a>, to "The <=
i class=3D"">&lt;sys/stat.h&gt;</i> header shall define the following symbo=
lic constants for the file mode bits encoded in type
<font face=3D"Courier" class=3D"">mode_t</font>, with the indicated numeric=
 values,=E2=80=9D in&nbsp;<a href=3D"http://pubs.opengroup.org/onlinepubs/9=
699919799/basedefs/sys_stat.h.html" class=3D"">POSIX:2013</a>. There might =
have been a window in the C++03 timeframe when deprecation of octal would h=
ave encouraged users to conform to POSIX, but now the tables have turned.</=
div><div class=3D""><br class=3D""></div><div class=3D"">Perhaps octal numb=
ers should only exist inside <font face=3D"Courier" class=3D"">extern "C" {=
}</font>?</div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_F0149972-3089-4638-8BE1-0198EC197B86--

.

On 06/26/2015 07:35 AM, David Krauss wrote:
>=20
>> On 2015=E2=80=9306=E2=80=9326, at 12:51 PM, Olaf van der Spek <olafvdspe=
k@gmail.com <mailto:olafvdspek@gmail.com>> wrote:
>>
>> 2015-06-24 20:35 GMT+02:00 Tony V E <tvaneerd@gmail.com <mailto:tvaneerd=
@gmail.com>>:
>>> Deprecating 0 just isn't going to happen, I think.
>>
>> Compiler warnings might be a good start.
>>
>> People just don't expect 010 =3D=3D 8 to be true.
>=20
> Except when calling POSIX ::stat, which seems beyond the reach of WG21. W=
hat=E2=80=99s the status of namespace posix, by the way? Has interest dwind=
led to nothing?

There have been a few meetings of a small group trying to come up with stan=
dardized
mappings of C++ standard features to POSIX (e.g. mutexes), and vice versa (=
using
namespace posix) some years ago, but the chair, Ulrich Drepper, seems to ha=
ve vanished.

I'd call this dead for now.

I'd say lack of general interest and lack of time of participants to actual=
ly
create proposals have all contributed.

And then, there's the desire of C++ to actually create a higher-level inter=
face
than a simple C++ mapping to POSIX facilities.  For example, C++ networking
turns out to be several layers above POSIX facilities, not at all mirroring
the conceptual approach.

> Unfortunately, it looks like the octal constants went from "File mode bit=
s and the contents of the remaining members of the stat structure are unspe=
cified,=E2=80=9D in POSIX:2004 <http://pubs.opengroup.org/onlinepubs/009695=
399/basedefs/sys/stat.h.html>, to "The /<sys/stat.h>/ header shall define t=
he following symbolic constants for the file mode bits encoded in type mode=
_t, with the indicated numeric values,=E2=80=9D in POSIX:2013 <http://pubs.=
opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html>. There might =
have been a window in the C++03 timeframe when deprecation of octal would h=
ave encouraged users to conform to POSIX, but now the tables have turned.

Well, you're still encourage to use the symbolic constants, rights?

Jens

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_42B2F6C5-FEB1-4801-96A2-49B24A5123FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


>> Unfortunately, it looks like the octal constants went from "File mode bi=
ts and the contents of the remaining members of the stat structure are unsp=
ecified,=E2=80=9D in POSIX:2004 <http://pubs.opengroup.org/onlinepubs/00969=
5399/basedefs/sys/stat.h.html>, to "The /<sys/stat.h>/ header shall define =
the following symbolic constants for the file mode bits encoded in type mod=
e_t, with the indicated numeric values,=E2=80=9D in POSIX:2013 <http://pubs=
..opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html>. There might=
 have been a window in the C++03 timeframe when deprecation of octal would =
have encouraged users to conform to POSIX, but now the tables have turned.
>=20
> Well, you're still encourage to use the symbolic constants, rights?

I don=E2=80=99t see anything to that effect. Why would they introduce somet=
hing if they didn=E2=80=99t want it to be used?

It says that the macros don=E2=80=99t need an explicit cast to mode_t, whic=
h is handy if mode_t is long. However, it appears to be short on Mac/BSD an=
d Windows, and int on Linux. I guess it could be long on a Linux-like syste=
m with 16-bit int, but likely few people care.

Just one lame use case, and the whole language is stuck with broken leading=
 zeroes forever. Well, as long as someone is using <sys/stat.h>, anyway. Un=
fortunately, that=E2=80=99s probably among the more invincible POSIX header=
s. I don=E2=80=99t suppose it can ever be completely replaced by a C++ bind=
ing, since it=E2=80=99s the access point for so many OS-specific features.

My 2=C2=A2, octal numbers have done enough damage already without 0o. (Alte=
rnate spelling 0O, right?)

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_42B2F6C5-FEB1-4801-96A2-49B24A5123FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D""><blockquote type=3D"=
cite" class=3D"">Unfortunately, it looks like the octal constants went from=
 "File mode bits and the contents of the remaining members of the stat stru=
cture are unspecified,=E2=80=9D in POSIX:2004 &lt;<a href=3D"http://pubs.op=
engroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html" class=3D"">http:=
//pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html</a>&gt;,=
 to "The /&lt;sys/stat.h&gt;/ header shall define the following symbolic co=
nstants for the file mode bits encoded in type mode_t, with the indicated n=
umeric values,=E2=80=9D in POSIX:2013 &lt;<a href=3D"http://pubs.opengroup.=
org/onlinepubs/9699919799/basedefs/sys_stat.h.html" class=3D"">http://pubs.=
opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html</a>&gt;. There=
 might have been a window in the C++03 timeframe when deprecation of octal =
would have encouraged users to conform to POSIX, but now the tables have tu=
rned.<br class=3D""></blockquote><br class=3D"">Well, you're still encourag=
e to use the symbolic constants, rights?<br class=3D""></div></blockquote><=
/div><br class=3D""><div class=3D"">I don=E2=80=99t see anything to that ef=
fect. Why would they introduce something if they didn=E2=80=99t want it to =
be used?</div><div class=3D""><br class=3D""></div><div class=3D"">It says =
that the macros don=E2=80=99t need an explicit cast to <font face=3D"Courie=
r" class=3D"">mode_t</font>, which is handy if <font face=3D"Courier" class=
=3D"">mode_t</font> is <font face=3D"Courier" class=3D"">long</font>. Howev=
er, it appears to be&nbsp;<font face=3D"Courier" class=3D"">short</font>&nb=
sp;on Mac/BSD and Windows, and <font face=3D"Courier" class=3D"">int</font>=
 on Linux. I guess it could be&nbsp;<font face=3D"Courier" class=3D"">long<=
/font> on a Linux-like system with 16-bit <font face=3D"Courier" class=3D""=
>int</font>, but likely few people care.</div><div class=3D""><br class=3D"=
"></div><div class=3D"">Just one lame use case, and the whole language is s=
tuck with broken leading zeroes forever. Well, as long as someone is using =
<font face=3D"Courier" class=3D"">&lt;sys/stat.h&gt;</font>, anyway. Unfort=
unately, that=E2=80=99s probably among the more invincible POSIX headers. I=
 don=E2=80=99t suppose it can ever be completely replaced by a C++ binding,=
 since it=E2=80=99s the access point for so many OS-specific features.</div=
><div class=3D""><br class=3D""></div><div class=3D"">My 2=C2=A2, octal num=
bers have done enough damage already without <font face=3D"Courier" class=
=3D"">0o</font>. (Alternate spelling <font face=3D"Courier" class=3D"">0O</=
font>, right?)</div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_42B2F6C5-FEB1-4801-96A2-49B24A5123FC--

.

On Friday 26 June 2015 13:35:31 David Krauss wrote:
> Perhaps octal numbers should only exist inside extern "C" {}?

And we should convince all POSIX implementations to change all their #defines
to enums, otherwise the warning triggers where the macro is used, not where it
got defined.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2080_1830554075.1435338751215
Content-Type: multipart/alternative;
 boundary="----=_Part_2081_218956677.1435338751215"

------=_Part_2081_218956677.1435338751215
Content-Type: text/plain; charset=UTF-8

If I recall correctly compiler can ignore macros when generating
errors/warnings like  `#pragma GCC poison` that allow usage in macros
defined before it.

On Friday, June 26, 2015 at 6:00:04 PM UTC+2, Thiago Macieira wrote:
>
> On Friday 26 June 2015 13:35:31 David Krauss wrote:
> > Perhaps octal numbers should only exist inside extern "C" {}?
>
> And we should convince all POSIX implementations to change all their
> #defines
> to enums, otherwise the warning triggers where the macro is used, not
> where it
> got defined.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">If I recall correctly compiler can ignore macros when gene=
rating errors/warnings like&nbsp; `#pragma GCC poison` that allow usage in =
macros defined before it.<br><br>On Friday, June 26, 2015 at 6:00:04 PM UTC=
+2, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On F=
riday 26 June 2015 13:35:31 David Krauss wrote:
<br>&gt; Perhaps octal numbers should only exist inside extern "C" {}?
<br>
<br>And we should convince all POSIX implementations to change all their #d=
efines=20
<br>to enums, otherwise the warning triggers where the macro is used, not w=
here it=20
<br>got defined.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2081_218956677.1435338751215--
------=_Part_2080_1830554075.1435338751215--

.

2015-06-26 11:39 GMT+02:00 David Krauss <potswa@gmail.com>:
> My 2=C2=A2, octal numbers have done enough damage already without 0o. (Al=
ternate
> spelling 0O, right?)

No alternate spelling. :p



--=20
Olaf

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Friday 26 June 2015 10:12:31 inkwizytoryankes@gmail.com wrote:
> If I recall correctly compiler can ignore macros when generating
> errors/warnings like  `#pragma GCC poison` that allow usage in macros
> defined before it.

Now you're imposing further compiler changes than just 0o and a diagnostic.

It can be done, but the barrier of entry for 0o has just gone up considerably.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-06-26 19:34 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On Friday 26 June 2015 10:12:31 inkwizytoryankes@gmail.com wrote:
>> If I recall correctly compiler can ignore macros when generating
>> errors/warnings like  `#pragma GCC poison` that allow usage in macros
>> defined before it.
>
> Now you're imposing further compiler changes than just 0o and a diagnostic.
>
> It can be done, but the barrier of entry for 0o has just gone up considerably.

If 0o is available the system header could use it and no pragmas would
be necessary, right?


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On 26 June 2015 at 12:36, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> If 0o is available the system header could use it and no pragmas would
> be necessary, right?
>

Only if C were to adopt it and OS vendors required a new enough version of
C, because those headers tend to be C headers...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
6 June 2015 at 12:36, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">If 0o is available the syste=
m header could use it and no pragmas would<br>
be necessary, right?<br></blockquote><div><br></div><div>Only if C were to =
adopt it and OS vendors required a new enough version of C, because those h=
eaders tend to be C headers...</div></div>-- <br><div class=3D"gmail_signat=
ure">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c37f7e39a53d05196f4ff6--

.

On Friday 26 June 2015 12:45:05 Nevin Liber wrote:
> On 26 June 2015 at 12:36, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > If 0o is available the system header could use it and no pragmas would
> > be necessary, right?
>
> Only if C were to adopt it and OS vendors required a new enough version of
> C, because those headers tend to be C headers...

Not to mention often they come from a different source than the compiler
vendor.

Example: on Linux, constants like O_RDWR actually come from a kernel header
and are defined in octal. So even if you updated your compiler and you updated
your libc, those constants would still "leak" to your code.

If we added Oo to C++17 and C17, we may be able to add the warning sometime
around 2025 and then make it an error by 2030.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Jun 26, 2015 at 12:51 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> 2015-06-24 20:35 GMT+02:00 Tony V E <tvaneerd@gmail.com>:
> > Deprecating 0 just isn't going to happen, I think.
>
> Compiler warnings might be a good start.
>
> People just don't expect 010 == 8 to be true.
>
>
Thanks for the example.  Maybe the need should have been obvious, but
wasn't to me.  I never use octals.
I'm not sure it is enough motivation to get us anywhere, but I do think it
is a nice, clear, concise motivation.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3493079fd330519713b1d
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 Fri, Jun 26, 2015 at 12:51 AM, Olaf van der Spek <span dir=3D"ltr">&=
lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gma=
il.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"><span class=
=3D"">2015-06-24 20:35 GMT+02:00 Tony V E &lt;<a href=3D"mailto:tvaneerd@gm=
ail.com">tvaneerd@gmail.com</a>&gt;:<br>
&gt; Deprecating 0 just isn&#39;t going to happen, I think.<br>
<br>
</span>Compiler warnings might be a good start.<br>
<br>
People just don&#39;t expect 010 =3D=3D 8 to be true.<br>
<span class=3D"im HOEnZb"></span><br></blockquote></div><br></div><div clas=
s=3D"gmail_extra">Thanks for the example.=C2=A0 Maybe the need should have =
been obvious, but wasn&#39;t to me.=C2=A0 I never use octals.<br></div><div=
 class=3D"gmail_extra">I&#39;m not sure it is enough motivation to get us a=
nywhere, but I do think it is a nice, clear, concise motivation.<br></div><=
div class=3D"gmail_extra"><br><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3493079fd330519713b1d--

.

------=_Part_2462_1869432414.1435360019974
Content-Type: multipart/alternative;
 boundary="----=_Part_2463_1864826488.1435360019974"

------=_Part_2463_1864826488.1435360019974
Content-Type: text/plain; charset=UTF-8



Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:
>
> Example: on Linux, constants like O_RDWR actually come from a kernel
> header
> and are defined in octal. So even if you updated your compiler and you
> updated
> your libc, those constants would still "leak" to your code.
>

Why are they using octal for those?


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thi=
ago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Example: on Linux=
, constants like O_RDWR actually come from a kernel header=20
<br>and are defined in octal. So even if you updated your compiler and you =
updated=20
<br>your libc, those constants would still "leak" to your code.
<br></blockquote><div><br></div><div>Why are they using octal for those?&nb=
sp;</div><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2463_1864826488.1435360019974--
------=_Part_2462_1869432414.1435360019974--

.

------=_Part_2994_2027058723.1435363987547
Content-Type: multipart/alternative;
 boundary="----=_Part_2995_1095381453.1435363987547"

------=_Part_2995_1095381453.1435363987547
Content-Type: text/plain; charset=UTF-8

On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der Spek wrote:
>
> Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:
>>
>> Example: on Linux, constants like O_RDWR actually come from a kernel
>> header
>> and are defined in octal. So even if you updated your compiler and you
>> updated
>> your libc, those constants would still "leak" to your code.
>>
>
> Why are they using octal for those?
>

Why is anyone debating "removal of octal notation from C++" who's never
heard of file permissions?
`man 2 chmod` and have your mind blown.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der=
 Spek 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">O=
p vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">Example: on Linux, constants like O_RDWR actuall=
y come from a kernel header=20
<br>and are defined in octal. So even if you updated your compiler and you =
updated=20
<br>your libc, those constants would still "leak" to your code.
<br></blockquote><div><br></div><div>Why are they using octal for those? &n=
bsp;</div></div></blockquote><div><br></div><div>Why is anyone debating "re=
moval of octal notation from C++" who's never heard of file permissions?</d=
iv><div>`man 2 chmod` and have your mind blown.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2995_1095381453.1435363987547--
------=_Part_2994_2027058723.1435363987547--

.

--Apple-Mail=_0E50332D-7365-490D-9A25-E6E6B6C86BC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9327, at 8:13 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der Spek wrote:
>=20
> Why are they using octal for those? =20
>=20
> Why is anyone debating "removal of octal notation from C++" who's never h=
eard of file permissions?
> `man 2 chmod` and have your mind blown.

The incredible thing is the same folks debating adding an alternative octal=
 notation. Is there any other use for octal?

This is like saying trigraphs are bad=E2=80=A6 and proposing alternative tr=
igraphs. Oh wait, that actually happened.

(To be pedantic, see POSIX <http://pubs.opengroup.org/onlinepubs/9699919799=
/basedefs/sys_stat.h.html> for the constants that tend to be octal, e.g. S_=
IRWXU not O_RDWR. And, these are required to be macros, they cannot be enum=
erations at the implementation=E2=80=99s discretion. The problem is complet=
ely unsolvable except by decoupling the C++ interface from the C header. I =
didn=E2=80=99t mention this earlier because the discussion seemed to be ove=
r=E2=80=A6)

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_0E50332D-7365-490D-9A25-E6E6B6C86BC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9327, at 8:13 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=
=3D"">On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der Spek wrote=
:<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" class=3D""><=
div class=3D""><br class=3D""></div><div class=3D"">Why are they using octa=
l for those? &nbsp;</div></div></blockquote><div class=3D""><br class=3D"">=
</div><div class=3D"">Why is anyone debating "removal of octal notation fro=
m C++" who's never heard of file permissions?</div><div class=3D"">`man 2 c=
hmod` and have your mind blown.</div></div></div></blockquote><br class=3D"=
"></div><div>The incredible thing is the same folks debating&nbsp;<i class=
=3D"">adding</i>&nbsp;an alternative octal notation. Is there any other use=
 for octal?</div><div><br class=3D""></div><div>This is like saying trigrap=
hs are bad=E2=80=A6 and proposing alternative trigraphs. Oh wait, that actu=
ally happened.</div><div><br class=3D""></div><div>(To be pedantic, see&nbs=
p;<a href=3D"http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_s=
tat.h.html" class=3D"">POSIX</a>&nbsp;for the constants that tend to be oct=
al, e.g. S_IRWXU not O_RDWR. And, these are <i class=3D"">required</i> to b=
e macros, they cannot be enumerations at the implementation=E2=80=99s discr=
etion. The problem is completely unsolvable except by decoupling the C++ in=
terface from the C header. I didn=E2=80=99t mention this earlier because th=
e discussion seemed to be over=E2=80=A6)</div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_0E50332D-7365-490D-9A25-E6E6B6C86BC2--

.

On Friday 26 June 2015 16:06:59 Olaf van der Spek wrote:
> Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:
> > Example: on Linux, constants like O_RDWR actually come from a kernel
> > header
> > and are defined in octal. So even if you updated your compiler and you
> > updated
> > your libc, those constants would still "leak" to your code.
>
> Why are they using octal for those?

It's one of those "it's always been like that".

http://www.oldlinux.org/Linux.old/Linux-0.01/sources/system/kernel/linux-0.01.tar.gz
see include/fcntl.h

I can't tell if MINIX already had it like that (it doesn't look like it had
POSIX API back in 1991).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-06-27 2:13 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
> On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der Spek wrote:
>>
>> Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:
>>>
>>> Example: on Linux, constants like O_RDWR actually come from a kernel
>>> header
>>> and are defined in octal. So even if you updated your compiler and you
>>> updated
>>> your libc, those constants would still "leak" to your code.
>>
>>
>> Why are they using octal for those?
>
>
> Why is anyone debating "removal of octal notation from C++" who's never
> heard of file permissions?
> `man 2 chmod` and have your mind blown.

I'm familiar with POSIX file permissions.. but O_RDWR isn't part of that is it?
Even for the real file permissions (0777 etc) octal doesn't seem necessary.


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 06/27/2015 06:39 AM, Olaf van der Spek wrote:
> 2015-06-27 2:13 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
>> On Friday, June 26, 2015 at 4:07:00 PM UTC-7, Olaf van der Spek wrote:
>>> Op vrijdag 26 juni 2015 20:12:31 UTC+2 schreef Thiago Macieira:
>>>> Example: on Linux, constants like O_RDWR actually come from a kernel
>>>> header
>>>> and are defined in octal. So even if you updated your compiler and you
>>>> updated
>>>> your libc, those constants would still "leak" to your code.
>>>
>>> Why are they using octal for those?
>>
>> Why is anyone debating "removal of octal notation from C++" who's never
>> heard of file permissions?
>> `man 2 chmod` and have your mind blown.
>>
> I'm familiar with POSIX file permissions.. but O_RDWR isn't part of that is it?
> Even for the real file permissions (0777 etc) octal doesn't seem necessary.
>
>
It wasn't necessary, but with three permission properties - read, write,
execute - the three bits naturally lead to octal.  It does allow you to
cram a bit of information in a small space.  And I think it's intuitive
for people to look at those perms and know what's going on.

At this point I think so much code expects the POSIX bit structure that
these numbers couldn't be changed.  I'm sure O_RDWR is masked and bit
twiddled with permissions, etc.

Another point: look at the filesystem proposal (now a TR).  Then just
made an enum (I guess they gave up on posix::)
   /// Bitmask type
   enum class perms : unsigned {
       none        =  0,
       owner_read    =  0400,
       owner_write    =  0200,
       owner_exec    =  0100,
       owner_all        =  0700,
       group_read    =   040,
       group_write    =   020,
       group_exec    =   010,
       group_all        =   070,
       others_read    =    04,
       others_write    =    02,
       others_exec    =    01,
       others_all    =    07,
       all        =  0777,
       set_uid        = 04000,
       set_gid        = 02000,
       sticky_bit    = 01000,
       mask        = 07777,
       unknown        =  0xFFFF,
       add_perms        = 0x10000,
       remove_perms    = 0x20000,
       resolve_symlinks    = 0x40000
   };

IIRC these are required to interact with POSIX and to support the bit ops.

Believe me, as someone whose first crash as I migrated from
Pascal/Fortran to C/C++ was to specify some array sizes:
   float a[100];
   float b[050]; // Surprise!
- zero padding the b array for aesthetics - I wish we could do better.

So:
1. I think we just have to accept current octal numbers till the trump
sounds even if C and C++ both added 0o (AND 0O) today.
2. I don't know how to trap an error like the above at compile time. I
think -Wold-style-octal would be too noisy and would never be turned on.
3. C++ library writers and the committee seem comfortable just charging
ahead with enums to help the few cases these octals show up in combat.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-06-27 16:57 GMT+02:00 Ed Smith-Rowland <3dw4rd@verizon.net>:
> On 06/27/2015 06:39 AM, Olaf van der Spek wrote:
>       owner_read    =  0400,

>       unknown        =  0xFFFF,

Octal and hex in a single enum? Sigh.

> 2. I don't know how to trap an error like the above at compile time. I think
> -Wold-style-octal would be too noisy and would never be turned on.

Why? Never is a long time and lots of programs don't use the POSIX stuff.
Where do we want to be in 2050?




--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 06/28/2015 12:39 PM, Olaf van der Spek wrote:
> 2015-06-27 16:57 GMT+02:00 Ed Smith-Rowland <3dw4rd@verizon.net>:
>> On 06/27/2015 06:39 AM, Olaf van der Spek wrote:
>>        owner_read    =  0400,
>>        unknown        =  0xFFFF,
> Octal and hex in a single enum? Sigh.
>
>> 2. I don't know how to trap an error like the above at compile time. I think
>> -Wold-style-octal would be too noisy and would never be turned on.
> Why? Never is a long time and lots of programs don't use the POSIX stuff.
> Where do we want to be in 2050?
>
>
>
>

Actually, now that you mention it, that flag would have helped my old error.
I do tend to crank warnings up and tidy things.  It just woud have
barfed on system headers like stdio.h etc.
The legit stuff might be hard to spot.

It would be useful if bug databases could be scanned to augment personal
lore to strengthen the case.

It would be trivial to implement this and fly it on a branch of gcc.  Hmmm.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-06-28 14:02, Ed Smith-Rowland wrote:
> On 06/28/2015 12:39 PM, Olaf van der Spek wrote:
>> 2015-06-27 16:57 GMT+02:00 Ed Smith-Rowland <3dw4rd@verizon.net>:
>>> On 06/27/2015 06:39 AM, Olaf van der Spek wrote:
>>>        owner_read    =  0400,
>>>        unknown        =  0xFFFF,
>> Octal and hex in a single enum? Sigh.
>>
>>> 2. I don't know how to trap an error like the above at compile time.
>>> I think
>>> -Wold-style-octal would be too noisy and would never be turned on.
>> Why? Never is a long time and lots of programs don't use the POSIX stuff.
>> Where do we want to be in 2050?
>>
>>
>>
>>
>
> Actually, now that you mention it, that flag would have helped my old
> error.
> I do tend to crank warnings up and tidy things.  It just woud have
> barfed on system headers like stdio.h etc.
> The legit stuff might be hard to spot.

Compilers are already good at not warning on things in system headers.
I wouldn't worry about that.

John

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_57_1025451999.1435625286028
Content-Type: multipart/alternative;
 boundary="----=_Part_58_1708212262.1435625286035"

------=_Part_58_1708212262.1435625286035
Content-Type: text/plain; charset=UTF-8

On Sunday, June 28, 2015 at 11:11:49 AM UTC-7, John Bytheway wrote:
>
>
> Compilers are already good at not warning on things in system headers.
> I wouldn't worry about that.
>
>
Unless your compiler vendor is from Redmond...

C:\Program Files (x86)\Windows Kits\8.1\include\um\propidl.h(154) : warning
C4820: 'tagCAI' : '4' bytes padding added after data member
'tagCAI::cElems'

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, June 28, 2015 at 11:11:49 AM UTC-7, John Bythew=
ay wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Compilers are alr=
eady good at not warning on things in system headers.
<br>I wouldn't worry about that.
<br>
<br></blockquote><div><br>Unless your compiler vendor is from Redmond...<br=
><br>C:\Program Files (x86)\Windows Kits\8.1\include\um\propidl.h(154) : wa=
rning C4820: 'tagCAI' : '4' bytes padding added after data member 'tagCAI::=
cElems' <br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_58_1708212262.1435625286035--
------=_Part_57_1025451999.1435625286028--

.

------=_Part_2384_1240102417.1435793245847
Content-Type: multipart/alternative;
 boundary="----=_Part_2385_1072528384.1435793245847"

------=_Part_2385_1072528384.1435793245847
Content-Type: text/plain; charset=UTF-8

What are people using octal for, other then Posix permissions?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2385_1072528384.1435793245847
Content-Type: text/html; charset=UTF-8

<div dir="ltr">What are people using octal for, other then Posix permissions?</div>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2385_1072528384.1435793245847--
------=_Part_2384_1240102417.1435793245847--

.

On Wednesday 01 July 2015 16:27:25 Olaf van der Spek wrote:
> What are people using octal for, other then Posix permissions?

A quick search of Qt and Qt Creator code found:
* a lot of \ooo escapes in strings, especially \0, followed by \1, \01, \001,
\033 and \377

* POSIX file permissions, as expected (vast majority behind \0)

* comparisons to octal macros, like:
#    if __HP_aCC-0 < 060000

* copy & paste from Linux kernel headers:
#  define O_NOSIGNAL 040000000

* API inspired in POSIX file permissions (thankfully, deprecated);
        ReadOwner = 00400, WriteOwner = 00200, ExeOwner = 00100,

* Unit tests dealing with formatting of octals and parsing of them

* Gratuitous use of octals (one case)
        char utf8[] = { char(0357), char(0267), char(0220 + i), 0 };
   This is probably because a few lines above, we have
    static const char utf8_5[] = "\360\220\210\203"; // U+010203
   Which are the octal escape in strings I noted before.

* accidental use (exacty one case):
    m.id = 0001;

Looking at Clang's source code, I couldn't find anything besides string escapes
and unit tests.

GCC, on the other hand, seems to have some gratuitous use of octals, like:
gcc/config/m68k/m68k.h:#define CC_OVERFLOW_UNUSABLE 01000
gcc/gsyms.h:  N_BTMASK = 017,
libgcc/config/libbid/bid_b2d.h:  { 0000000000ull, 1000000000ull, 2000000000ull,
3000000000ull,

But all "gratuitous" use is still no more than a handful.

Even looking at the Linux kernel, I could find very few gratuitous uses. There
are the POSIX file permissions, the POSIX termios.h constants, plus a couple
other constants from old standards that probably defined in octal (OMAGIC,
COFF_F_EXEC, etc.) and some disassembly code for MIPS, PowerPC and x86.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_7_2087202897.1435803912208
Content-Type: multipart/alternative;
 boundary="----=_Part_8_473716134.1435803912208"

------=_Part_8_473716134.1435803912208
Content-Type: text/plain; charset=UTF-8

Are all of those example cases meant for pure C or for C++?

Perhaps the 0o format should be added and a compiler warning issued for any
number starting with 0?
I think that would certainly help get rid of those hard to find bugs when
someone accidentally uses an octal.
Maybe even add a compiler switch or pragma to turn off the '0 is for octal'
formatting.


On Wednesday, July 1, 2015 at 6:43:05 PM UTC-7, Thiago Macieira wrote:
>
> On Wednesday 01 July 2015 16:27:25 Olaf van der Spek wrote:
> > What are people using octal for, other then Posix permissions?
>
> A quick search of Qt and Qt Creator code found:
> * a lot of \ooo escapes in strings, especially \0, followed by \1, \01,
> \001,
> \033 and \377
>
> * POSIX file permissions, as expected (vast majority behind \0)
>
> * comparisons to octal macros, like:
> #    if __HP_aCC-0 < 060000
>
> * copy & paste from Linux kernel headers:
> #  define O_NOSIGNAL 040000000
>
> * API inspired in POSIX file permissions (thankfully, deprecated);
>         ReadOwner = 00400, WriteOwner = 00200, ExeOwner = 00100,
>
> * Unit tests dealing with formatting of octals and parsing of them
>
> * Gratuitous use of octals (one case)
>         char utf8[] = { char(0357), char(0267), char(0220 + i), 0 };
>    This is probably because a few lines above, we have
>     static const char utf8_5[] = "\360\220\210\203"; // U+010203
>    Which are the octal escape in strings I noted before.
>
> * accidental use (exacty one case):
>     m.id = 0001;
>
> Looking at Clang's source code, I couldn't find anything besides string
> escapes
> and unit tests.
>
> GCC, on the other hand, seems to have some gratuitous use of octals, like:
> gcc/config/m68k/m68k.h:#define CC_OVERFLOW_UNUSABLE 01000
> gcc/gsyms.h:  N_BTMASK = 017,
> libgcc/config/libbid/bid_b2d.h:  { 0000000000ull, 1000000000ull,
> 2000000000ull,
> 3000000000ull,
>
> But all "gratuitous" use is still no more than a handful.
>
> Even looking at the Linux kernel, I could find very few gratuitous uses.
> There
> are the POSIX file permissions, the POSIX termios.h constants, plus a
> couple
> other constants from old standards that probably defined in octal (OMAGIC,
> COFF_F_EXEC, etc.) and some disassembly code for MIPS, PowerPC and x86.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Are all of those example cases meant for pure C or for C++=
?<div><br></div><div>Perhaps the 0o format should be added and a compiler w=
arning issued for any number starting with 0?</div><div>I think that would =
certainly help get rid of those hard to find bugs when someone accidentally=
 uses an octal.</div><div>Maybe even add a compiler switch or pragma to tur=
n off the '0 is for octal' formatting.<br><br><br>On Wednesday, July 1, 201=
5 at 6:43:05 PM UTC-7, Thiago Macieira wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On Wednesday 01 July 2015 16:27:25 Olaf van der Spek wrote:
<br>&gt; What are people using octal for, other then Posix permissions?
<br>
<br>A quick search of Qt and Qt Creator code found:
<br>* a lot of \ooo escapes in strings, especially \0, followed by \1, \01,=
 \001,=20
<br>\033 and \377
<br>
<br>* POSIX file permissions, as expected (vast majority behind \0)
<br>
<br>* comparisons to octal macros, like:
<br># &nbsp; &nbsp;if __HP_aCC-0 &lt; 060000
<br>
<br>* copy &amp; paste from Linux kernel headers:
<br># &nbsp;define O_NOSIGNAL 040000000
<br>
<br>* API inspired in POSIX file permissions (thankfully, deprecated);
<br>&nbsp; &nbsp; &nbsp; &nbsp; ReadOwner =3D 00400, WriteOwner =3D 00200, =
ExeOwner =3D 00100,
<br>
<br>* Unit tests dealing with formatting of octals and parsing of them
<br>
<br>* Gratuitous use of octals (one case)
<br>&nbsp; &nbsp; &nbsp; &nbsp; char utf8[] =3D { char(0357), char(0267), c=
har(0220 + i), 0 };
<br>&nbsp; &nbsp;This is probably because a few lines above, we have
<br>&nbsp; &nbsp; static const char utf8_5[] =3D "\360\220\210\203"; // U+0=
10203
<br>&nbsp; &nbsp;Which are the octal escape in strings I noted before.
<br>
<br>* accidental use (exacty one case):
<br>&nbsp; &nbsp; <a href=3D"http://m.id" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fm.=
id\46sa\75D\46sntz\0751\46usg\75AFQjCNFqyZrbx8Ze6f7iTCPv2uoeAivXQw';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fm=
..id\46sa\75D\46sntz\0751\46usg\75AFQjCNFqyZrbx8Ze6f7iTCPv2uoeAivXQw';return=
 true;">m.id</a> =3D 0001;
<br>
<br>Looking at Clang's source code, I couldn't find anything besides string=
 escapes=20
<br>and unit tests.
<br>
<br>GCC, on the other hand, seems to have some gratuitous use of octals, li=
ke:
<br>gcc/config/m68k/m68k.h:#define CC_OVERFLOW_UNUSABLE 01000
<br>gcc/gsyms.h: &nbsp;N_BTMASK =3D 017,
<br>libgcc/config/libbid/bid_b2d.<wbr>h: &nbsp;{ 0000000000ull, 1000000000u=
ll, 2000000000ull,=20
<br>3000000000ull,
<br>
<br>But all "gratuitous" use is still no more than a handful.
<br>
<br>Even looking at the Linux kernel, I could find very few gratuitous uses=
.. There=20
<br>are the POSIX file permissions, the POSIX termios.h constants, plus a c=
ouple=20
<br>other constants from old standards that probably defined in octal (OMAG=
IC,=20
<br>COFF_F_EXEC, etc.) and some disassembly code for MIPS, PowerPC and x86.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_8_473716134.1435803912208--
------=_Part_7_2087202897.1435803912208--

.

--Apple-Mail=_5315EAE6-5D13-4B9A-8A94-2B7752B31C53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9302, at 9:43 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> * a lot of \ooo escapes in strings, especially \0, followed by \1, \01, \=
001,=20
> \033 and \377

String and character literals are an entirely different topic from integer =
literals.

Actually, they could be used as a migration path. L'\644' is a valid third =
argument to open(2) unless sizeof(wchar_t) > sizeof(int). '\360' is a more =
straightforward version of char(0360) which you found.

> * comparisons to octal macros, like:
> #    if __HP_aCC-0 < 060000


This appears to be in error. Boost, at least, treats <http://www.boost.org/=
doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp> __HP_aCC as a decimal lit=
eral:

> #if (__HP_aCC >=3D 60000) || ((__HP_aCC > 38000) && defined(__hpxstd98))


This also mentions a prior version A.03.80, which couldn=E2=80=99t have bee=
n encoded in octal at all. Your quote includes a useless =E2=80=9C-0=E2=80=
=9D which looks vaguely like a superstitious octal-banishing incantation. I=
'm inclined to believe Boost here.

Removing the cases of erroneous usage, characters, and support of runtime o=
ctal from Qt, we=E2=80=99re left with only file permissions.

From GCC, note that your last example is actually decimal. The first one se=
ems genuine, but seems to be part of a set of flags with its brethren used =
but not defined. The second one appears part of some backward-compatibility=
 code, with #ifdef EXTENDED_SDB_BASIC_TYPES switching it to hexadecimal. It=
=E2=80=99s likely already due for removal.

It=E2=80=99s valid to consider GCC here, because it=E2=80=99s transitioning=
 to C++, but I don=E2=80=99t think the Linux kernel is ever likely to switc=
h.


TL;DR: Octal deprecation is ripe for proposal, if we could just get rid of =
those pesky UNIX permissions. Current octal usage correlates strongly with =
errors, so implementations should consider warning diagnostics=E2=80=A6 if =
they can filter out permissions.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_5315EAE6-5D13-4B9A-8A94-2B7752B31C53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9302, at 9:43 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: non=
e; display: inline !important;" class=3D"">* a lot of \ooo escapes in strin=
gs, especially \0, followed by \1, \01, \001,<span class=3D"Apple-converted=
-space">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size:=
 12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; float: none; display: inline !important;" class=3D"">\033 and =
\377</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br c=
lass=3D""><div class=3D"">String and character literals are an entirely dif=
ferent topic from integer literals.</div><div class=3D""><br class=3D""></d=
iv><div class=3D"">Actually, they could be used as a migration path. <font =
face=3D"Courier" class=3D"">L'\644'</font> is a valid third argument to ope=
n(2) unless <font face=3D"Courier" class=3D"">sizeof(wchar_t) &gt; sizeof(i=
nt)</font>. <font face=3D"Courier" class=3D"">'\360'</font> is a more strai=
ghtforward version of&nbsp;<font face=3D"Courier" class=3D"">char(0360)</fo=
nt>&nbsp;which you found.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D""><blockquote type=3D"cite" class=3D""><span class=3D"" style=3D"flo=
at: none; display: inline !important;">* comparisons to octal macros, like:=
</span><br class=3D""><font face=3D"Courier" class=3D""><span class=3D"" st=
yle=3D"float: none; display: inline !important;"># &nbsp;&nbsp;&nbsp;if __H=
P_aCC-0 &lt; 060000</span><br class=3D""></font></blockquote></div><div cla=
ss=3D""><span class=3D"" style=3D"float: none; display: inline !important;"=
><br class=3D""></span></div><div class=3D""><span class=3D"" style=3D"floa=
t: none; display: inline !important;">This appears to be in error. Boost, a=
t least,&nbsp;<a href=3D"http://www.boost.org/doc/libs/1_58_0/boost/config/=
compiler/hp_acc.hpp" class=3D"">treats</a>&nbsp;<font face=3D"Courier" clas=
s=3D"">__HP_aCC</font> as a decimal literal:</span></div><div class=3D""><s=
pan class=3D"" style=3D"float: none; display: inline !important;"><br class=
=3D""></span></div><div class=3D""><blockquote type=3D"cite" class=3D""><sp=
an class=3D"" style=3D"float: none; display: inline !important;"><font face=
=3D"Courier" class=3D"">#if (__HP_aCC &gt;=3D 60000) || ((__HP_aCC &gt; 380=
00) &amp;&amp; defined(__hpxstd98))</font><br class=3D""></span></blockquot=
e></div><div class=3D""><span class=3D"" style=3D"float: none; display: inl=
ine !important;"><br class=3D""></span></div><div class=3D""><span class=3D=
"" style=3D"float: none; display: inline !important;">This also mentions a =
prior version A.03.80, which couldn=E2=80=99t have been encoded in octal at=
 all.&nbsp;</span>Your quote includes a useless =E2=80=9C<font face=3D"Cour=
ier" class=3D"">-0</font>=E2=80=9D which looks vaguely like a superstitious=
 octal-banishing incantation. I'm inclined to believe Boost here.</div><div=
 class=3D""><span class=3D"" style=3D"float: none; display: inline !importa=
nt;"><br class=3D""></span></div><div class=3D"">Removing the cases of erro=
neous usage, characters, and support of runtime octal from Qt, we=E2=80=99r=
e left with only file permissions.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">From GCC, note that your last example is actually decimal=
.. The first one seems genuine, but seems to be part of a set of flags with =
its brethren used but not defined. The second one appears part of some back=
ward-compatibility code, with <font face=3D"Courier" class=3D"">#ifdef EXTE=
NDED_SDB_BASIC_TYPES</font> switching it to hexadecimal. It=E2=80=99s likel=
y already due for removal.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">It=E2=80=99s valid to consider GCC here, because it=E2=80=99s tra=
nsitioning to C++, but I don=E2=80=99t think the Linux kernel is ever likel=
y to switch.</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">TL;DR: Octal deprecation is ripe for propo=
sal, if we could just get rid of those pesky UNIX permissions. Current octa=
l usage correlates strongly with errors, so implementations should consider=
 warning diagnostics=E2=80=A6 if they can filter out permissions.</div><div=
 class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_5315EAE6-5D13-4B9A-8A94-2B7752B31C53--

.

--f46d0438940d8a96070519dc14d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 1, 2015 at 8:02 PM, David Krauss <potswa@gmail.com> wrote:

> On 2015=E2=80=9307=E2=80=9302, at 9:43 AM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>
> * a lot of \ooo escapes in strings, especially \0, followed by \1, \01,
> \001,
> \033 and \377
>
>
> String and character literals are an entirely different topic from intege=
r
> literals.
>
> Actually, they could be used as a migration path. L'\644' is a valid
> third argument to open(2) unless sizeof(wchar_t) > sizeof(int). '\360' is
> a more straightforward version of char(0360) which you found.
>
> * comparisons to octal macros, like:
> #    if __HP_aCC-0 < 060000
>
>
> This appears to be in error. Boost, at least, treats
> <http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp>
> __HP_aCC as a decimal literal:
>
> #if (__HP_aCC >=3D 60000) || ((__HP_aCC > 38000) && defined(__hpxstd98))
>
>
> This also mentions a prior version A.03.80, which couldn=E2=80=99t have b=
een
> encoded in octal at all. Your quote includes a useless =E2=80=9C-0=E2=80=
=9D which looks
> vaguely like a superstitious octal-banishing incantation. I'm inclined to
> believe Boost here.
>

I believe "-0" is an incantation to deal with the situation where __HP_aCC
is #defined as the empty string.
If it expands to empty-string, then indeed (-0 < 060000) is true, instead
of being a syntax error.
However, I think you're right that this octal was unintended.

=E2=80=93Arthur

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Wed, Jul 1, 2015 at 8:02 PM, David Krauss <span dir=3D"=
ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail=
..com</a>&gt;</span> wrote:<div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><sp=
an class=3D""><div><blockquote type=3D"cite"><div>On 2015=E2=80=9307=E2=80=
=9302, at 9:43 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.or=
g" target=3D"_blank">thiago@macieira.org</a>&gt; wrote:</div><br><div><span=
 style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-=
align:start;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px;float:none;display:inline!important">* a lot of \ooo escapes in st=
rings, especially \0, followed by \1, \01, \001,<span>=C2=A0</span></span><=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><span style=3D"font-family:Helvetica;font-size:12px;font-style:=
normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-he=
ight:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;float:none;display:inline!important">\033 and \37=
7</span><br style=3D"font-family:Helvetica;font-size:12px;font-style:normal=
;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px"></div></blockquote></div><br></span><div>String and ch=
aracter literals are an entirely different topic from integer literals.</di=
v><div><br></div><div>Actually, they could be used as a migration path. <fo=
nt face=3D"Courier">L&#39;\644&#39;</font> is a valid third argument to ope=
n(2) unless <font face=3D"Courier">sizeof(wchar_t) &gt; sizeof(int)</font>.=
 <font face=3D"Courier">&#39;\360&#39;</font> is a more straightforward ver=
sion of=C2=A0<font face=3D"Courier">char(0360)</font>=C2=A0which you found.=
</div><span class=3D""><div><br></div><div><blockquote type=3D"cite"><span =
style=3D"float:none;display:inline!important">* comparisons to octal macros=
, like:</span><br><font face=3D"Courier"><span style=3D"float:none;display:=
inline!important"># =C2=A0=C2=A0=C2=A0if __HP_aCC-0 &lt; 060000</span><br><=
/font></blockquote></div><div><span style=3D"float:none;display:inline!impo=
rtant"><br></span></div></span><div><span style=3D"float:none;display:inlin=
e!important">This appears to be in error. Boost, at least,=C2=A0<a href=3D"=
http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp" targ=
et=3D"_blank">treats</a>=C2=A0<font face=3D"Courier">__HP_aCC</font> as a d=
ecimal literal:</span></div><div><span style=3D"float:none;display:inline!i=
mportant"><br></span></div><div><blockquote type=3D"cite"><span style=3D"fl=
oat:none;display:inline!important"><font face=3D"Courier">#if (__HP_aCC &gt=
;=3D 60000) || ((__HP_aCC &gt; 38000) &amp;&amp; defined(__hpxstd98))</font=
><br></span></blockquote></div><div><span style=3D"float:none;display:inlin=
e!important"><br></span></div><div><span style=3D"float:none;display:inline=
!important">This also mentions a prior version A.03.80, which couldn=E2=80=
=99t have been encoded in octal at all.=C2=A0</span>Your quote includes a u=
seless =E2=80=9C<font face=3D"Courier">-0</font>=E2=80=9D which looks vague=
ly like a superstitious octal-banishing incantation. I&#39;m inclined to be=
lieve Boost here.</div></div></blockquote><div><br></div><div>I believe &qu=
ot;-0&quot; is an incantation to deal with the situation where __HP_aCC is =
#defined as the empty string.</div><div>If it expands to empty-string, then=
 indeed (-0 &lt; 060000) is true, instead of being a syntax error.</div><di=
v>However, I think you&#39;re right that this octal was unintended.</div><d=
iv><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d0438940d8a96070519dc14d3--

.

On Thursday 02 July 2015 11:02:25 David Krauss wrote:
> > #    if __HP_aCC-0 < 060000
>=20
> This appears to be in error. Boost, at least, treats
> <http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp>
> __HP_aCC as a decimal literal:

I was surprised to see it too (especially considering I'm probably the one =
who=20
wrote it). I agree it's a mistake.

No one must have caught it because aCC 3.8 is too old to compile modern Qt=
=20
anyway. And no one has tested aCC in at least 4 years. The macro is=20
historical, from when we supported HPUX and HPUXi.

> It=E2=80=99s valid to consider GCC here, because it=E2=80=99s transitioni=
ng to C++, but I
> don=E2=80=99t think the Linux kernel is ever likely to switch.

Aside from the file permissions, I don't see why the other macros couldn't =
be=20
fixed too. There must be two orders of magnitude more hex than octal in the=
=20
kernel, if you exclude the permissions.

The problem is that the file permissions are *everywhere* due to "everythin=
g is=20
a file" and virtual filesystem support. We could convince people that the u=
api=20
headers should be fixed[*], but asking to change anything else is going to =
hit=20
a wall until a solution is found for file permissions.

[*] we'd need to get C to change too, otherwise we're going to just run int=
o=20
Linus's disli^H^H^H^H^Hhate for C++

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_6DA0A5C4-0726-4EE1-B1B0-70AB92DF0A11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9302, at 2:04 PM, Thiago Macieira <thiago@maciei=
ra.org> wrote:
>=20
> The problem is that the file permissions are *everywhere* due to "everyth=
ing is=20
> a file" and virtual filesystem support.

Where is everywhere? I=E2=80=99m curious, do they ever really support much =
application-level behavior, or are they only viral inside lower levels of t=
he software stack?

I notice that Qt translates permission bits to hex.

> We could convince people that the uapi=20
> headers should be fixed[*], but asking to change anything else is going t=
o hit=20
> a wall until a solution is found for file permissions.

In the other thread, =E2=80=9CPOSIX binding,=E2=80=9D I make a case for dis=
connecting C++ from platform headers. The solution would be a translation s=
tep turning C headers into C++. The inputs would be ordinary /usr/include a=
nd a platform-independent POSIX binding. Platforms could, for instance, imp=
lement one flag to disable the raw POSIX headers and octal together. Non-PO=
SIX platform extensions would need treatment, too. The translation could pu=
ll unknown interfaces into some kind of quarantine namespace.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_6DA0A5C4-0726-4EE1-B1B0-70AB92DF0A11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9302, at 2:04 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago@macie=
ira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: non=
e; display: inline !important;" class=3D"">The problem is that the file per=
missions are *everywhere* due to "everything is<span class=3D"Apple-convert=
ed-space">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-siz=
e: 12px; font-style: normal; font-variant: normal; font-weight: normal; let=
ter-spacing: normal; line-height: normal; orphans: auto; text-align: start;=
 text-indent: 0px; text-transform: none; white-space: normal; widows: auto;=
 word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; float: none; display: inline !important;" class=3D"">a file" a=
nd virtual filesystem support. </span></div></blockquote><div><br class=3D"=
"></div><div>Where is everywhere? I=E2=80=99m curious, do they ever really =
support much application-level behavior, or are they only viral inside lowe=
r levels of the software stack?</div><div><br class=3D""></div><div>I notic=
e that Qt translates permission bits to hex.</div><br class=3D""><blockquot=
e type=3D"cite" class=3D""><div class=3D""><span style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: n=
one; display: inline !important;" class=3D"">We could convince people that =
the uapi<span class=3D"Apple-converted-space">&nbsp;</span></span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inli=
ne !important;" class=3D"">headers should be fixed[*], but asking to change=
 anything else is going to hit<span class=3D"Apple-converted-space">&nbsp;<=
/span></span><br style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; floa=
t: none; display: inline !important;" class=3D"">a wall until a solution is=
 found for file permissions.</span><br style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div>=
</blockquote></div><br class=3D""><div class=3D"">In the other thread, =E2=
=80=9CPOSIX binding,=E2=80=9D I make a case for disconnecting C++ from plat=
form headers. The solution would be a translation step turning C headers in=
to C++. The inputs would be ordinary&nbsp;<font face=3D"Courier" class=3D""=
>/usr/include</font> and a platform-independent POSIX binding. Platforms co=
uld, for instance, implement one flag to disable the raw POSIX headers and =
octal together. Non-POSIX platform extensions would need treatment, too. Th=
e translation could pull unknown interfaces into some kind of quarantine na=
mespace.</div><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_6DA0A5C4-0726-4EE1-B1B0-70AB92DF0A11--

.

On 07/02/2015 08:04 AM, Thiago Macieira wrote:
> On Thursday 02 July 2015 11:02:25 David Krauss wrote:
>>> #    if __HP_aCC-0 < 060000
>>
>> This appears to be in error. Boost, at least, treats
>> <http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp>
>> __HP_aCC as a decimal literal:
>
> I was surprised to see it too (especially considering I'm probably the one who
> wrote it). I agree it's a mistake.

I think that the HP aC++ documentation is to blame. Notice its example:

  "__HP_aCC identifies the HP aC++ compiler driver version. It is
   represented as a six digit number in the format mmnnxx. Where mm is
   the major version number, nn is the minor version number, and xx is
   any extension. For example, for version A.01.21, __HP_aCC=012100"

I just fixed this in the predef.sourceforge.net pages.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-07-02 3:43 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On Wednesday 01 July 2015 16:27:25 Olaf van der Spek wrote:
>> What are people using octal for, other then Posix permissions?
>
> A quick search of Qt and Qt Creator code found:
> * a lot of \ooo escapes in strings, especially \0, followed by \1, \01, \001,
> \033 and \377

27 and 255, ANSI terminal escapes or something?
Why not use \x1b and \xff?

Anyway, it's unrelated to the 0 prefix for normal numbers.

> * POSIX file permissions, as expected (vast majority behind \0)

What do you mean by behind \0?



--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-07-02 5:02 GMT+02:00 David Krauss <potswa@gmail.com>:
> TL;DR: Octal deprecation is ripe for proposal, if we could just get rid o=
f
> those pesky UNIX permissions. Current octal usage correlates strongly wit=
h
> errors, so implementations should consider warning diagnostics=E2=80=A6 i=
f they can
> filter out permissions.

Can't we deprecate Posix file permissions themselves while we're at it? :p
They're not simple enough and too simple...


--=20
Olaf

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Thursday 02 July 2015 15:37:02 David Krauss wrote:
> > On 2015=E2=80=9307=E2=80=9302, at 2:04 PM, Thiago Macieira <thiago@maci=
eira.org> wrote:
> >=20
> > The problem is that the file permissions are *everywhere* due to
> > "everything is a file" and virtual filesystem support.
>=20
> Where is everywhere? I=E2=80=99m curious, do they ever really support muc=
h
> application-level behavior, or are they only viral inside lower levels of
> the software stack?

I was talking in the context of porting the kernel, so that "everywhere" me=
ans=20
"everywhere inside the Linux kernel sources". If you grep for 0444, 0644 an=
d=20
other common permissions, you'll find hundreds of occurrences.

> I notice that Qt translates permission bits to hex.

A few people have got bitten by it by trying POSIX permissions, but in all=
=20
it's worked fine.

> > We could convince people that the uapi
> > headers should be fixed[*], but asking to change anything else is going=
 to
> > hit a wall until a solution is found for file permissions.
>=20
> In the other thread, =E2=80=9CPOSIX binding,=E2=80=9D I make a case for d=
isconnecting C++
> from platform headers. The solution would be a translation step turning C
> headers into C++. The inputs would be ordinary /usr/include and a
> platform-independent POSIX binding. Platforms could, for instance,
> implement one flag to disable the raw POSIX headers and octal together.
> Non-POSIX platform extensions would need treatment, too. The translation
> could pull unknown interfaces into some kind of quarantine namespace.

Again, I was talking in context of the kernel.

For general software, the only times you generally deal with file permissio=
ns=20
is in open / creat. Sure, there are other calls, but they must happen two o=
r=20
more orders of magnitude less frequently.

And to be honest, I wouldn't worry too much about the POSIX open function w=
hen=20
creating a file, since that's usually wrapped around a class that will mana=
ge=20
doing so correctly under a transaction (=C3=A0 la QSaveFile).

As for having a POSIX-API wrapper... IMHO that would be a waste of time.=20
People will just write POSIX C instead. Just look at how often people use=
=20
<string.h> and <math.h> instead of <cstring> and <cmath>.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Thursday 02 July 2015 12:04:28 Bjorn Reese wrote:
> On 07/02/2015 08:04 AM, Thiago Macieira wrote:
> > On Thursday 02 July 2015 11:02:25 David Krauss wrote:
> >>> #    if __HP_aCC-0 < 060000
> >>=20
> >> This appears to be in error. Boost, at least, treats
> >> <http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hpp=
>
> >=20
> >> __HP_aCC as a decimal literal:
> > I was surprised to see it too (especially considering I'm probably the =
one
> > who wrote it). I agree it's a mistake.
>=20
> I think that the HP aC++ documentation is to blame. Notice its example:
>=20
>   "__HP_aCC identifies the HP aC++ compiler driver version. It is
>    represented as a six digit number in the format mmnnxx. Where mm is
>    the major version number, nn is the minor version number, and xx is
>    any extension. For example, for version A.01.21, __HP_aCC=3D012100"
>=20
> I just fixed this in the predef.sourceforge.net pages.

Would be nice if you tested aC++, if you still have access to it. I'm prett=
y=20
sure I'd have tested aCC back when I wrote that code, but my tests might ha=
ve=20
been false positives.

Another compiler that used to use decimal was Sun Studio. Then they switche=
d=20
to hex: 509 =E2=86=92 0x50a.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Thursday 02 July 2015 13:21:49 Olaf van der Spek wrote:
> 2015-07-02 3:43 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> > On Wednesday 01 July 2015 16:27:25 Olaf van der Spek wrote:
> >> What are people using octal for, other then Posix permissions?
> >
> > A quick search of Qt and Qt Creator code found:
> > * a lot of \ooo escapes in strings, especially \0, followed by \1, \01,
> > \001, \033 and \377
>
> 27 and 255, ANSI terminal escapes or something?
> Why not use \x1b and \xff?

Yes, ANSI escape sequences. The reason it's \033 instead of \x1b is probably
because all the documentation out there uses \033.

But the main reason to use octal is that octal is length-limited and hex
isn't.

 "\04040"  is " 40"
 "\xffff" is an overflow

When I originally wrote the "pretty C string dumper" for QDebug, I had used
octal because it was stateless and I could just use \ooo. Then the reviewer
had me use hex, so now I had to introduce a state and detect when the last
character was an hex escape sequence and the next is another such character.

See http://code.woboq.org/qt5/qtbase/src/corelib/io/qdebug.cpp.html#183

> Anyway, it's unrelated to the 0 prefix for normal numbers.
>
> > * POSIX file permissions, as expected (vast majority behind \0)
>
> What do you mean by behind \0?

The most frequent use of octal is \0, then POSIX file permissions, then the
other non-zero string escapes.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.

--Boundary_(ID_C6NOrEBngYKHPzQtL+dLQg)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable

On 07/01/2015 11:31 PM, Arthur O'Dwyer wrote:
> On Wed, Jul 1, 2015 at 8:02 PM, David Krauss <potswa@gmail.com=20
> <mailto:potswa@gmail.com>> wrote:
>
>>     On 2015=E2=80=9307=E2=80=9302, at 9:43 AM, Thiago Macieira <thiago@m=
acieira.org
>>     <mailto:thiago@macieira.org>> wrote:
>>
>>     * a lot of \ooo escapes in strings, especially \0, followed by
>>     \1, \01, \001,
>>     \033 and \377
>
>     String and character literals are an entirely different topic from
>     integer literals.
>
>     Actually, they could be used as a migration path. L'\644' is a
>     valid third argument to open(2) unless sizeof(wchar_t) >
>     sizeof(int). '\360' is a more straightforward version of
>     char(0360) which you found.
>
A user-defined literal operator for oct:

unsigned int
   operator""o(unsigned long long n)
  {}

unsigned int
   operator""o(const char *str, size_t len)
  {}

unsigned int
   operator""o(char c)
  {}

auto perms0 =3D 644o;

  auto perms1 =3D "644"o;

auto perms2 =3D '\644'o;

Or have a perms literal operator since that is the greatest use of octal.
This could be part of filesystem_v2

filesystem::perms
   operator""perm(.)
  {}

etc.

Then with the new 0o644 format, compiler warnings of old-style octal, we=20
could fix some bugs and have a migration path.

>>     * comparisons to octal macros, like:
>>     #    if __HP_aCC-0 < 060000
>
>     This appears to be in error. Boost, at least, treats
>     <http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.hp=
p>
>     __HP_aCC as a decimal literal:
>
>>     #if (__HP_aCC >=3D 60000) || ((__HP_aCC > 38000) &&
>>     defined(__hpxstd98))
>
>     This also mentions a prior version A.03.80, which couldn=E2=80=99t ha=
ve
>     been encoded in octal at all. Your quote includes a useless =E2=80=9C=
-0=E2=80=9D
>     which looks vaguely like a superstitious octal-banishing
>     incantation. I'm inclined to believe Boost here.
>
>
> I believe "-0" is an incantation to deal with the situation where=20
> __HP_aCC is #defined as the empty string.
> If it expands to empty-string, then indeed (-0 < 060000) is true,=20
> instead of being a syntax error.
> However, I think you're right that this octal was unintended.
>
> =E2=80=93Arthur
> --=20
>
> ---
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IXXXDo3Y1rA/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Boundary_(ID_C6NOrEBngYKHPzQtL+dLQg)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 07/01/2015 11:31 PM, Arthur O'Dwyer
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CADvuK0Lv0czK+rGVr3M1wyg4y1w01Sc4HR-9W0g4HPob_ZS-ig@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">On Wed, Jul 1, 2015 at 8:02 PM, David Krauss <span
          dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
            href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail=
..com</a>&gt;</span>
        wrote:
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div style=3D"word-wrap:break-word"><span class=3D"">
                  <div>
                    <blockquote type=3D"cite">
                      <div>On 2015=E2=80=9307=E2=80=9302, at 9:43 AM, Thiag=
o Macieira
                        &lt;<a moz-do-not-send=3D"true"
                          href=3D"mailto:thiago@macieira.org"
                          target=3D"_blank">thiago@macieira.org</a>&gt;
                        wrote:</div>
                      <br>
                      <div><span
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;float:none;display:inline!important">*
                          a lot of \ooo escapes in strings, especially
                          \0, followed by \1, \01, \001,<span>=C2=A0</span>=
</span><br
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px">
                        <span
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;float:none;display:inline!important">\033
                          and \377</span><br
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varian=
t:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px">
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </span>
                <div>String and character literals are an entirely
                  different topic from integer literals.</div>
                <div><br>
                </div>
                <div>Actually, they could be used as a migration path. <fon=
t
                    face=3D"Courier">L'\644'</font> is a valid third
                  argument to open(2) unless <font face=3D"Courier">sizeof(=
wchar_t)
                    &gt; sizeof(int)</font>. <font face=3D"Courier">'\360'<=
/font>
                  is a more straightforward version of=C2=A0<font
                    face=3D"Courier">char(0360)</font>=C2=A0which you found=
..</div>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <tt>A user-defined literal operator for oct:</tt><tt><br>
    </tt><tt><br>
    </tt><tt>unsigned int</tt><tt><br>
    </tt><tt>=C2=A0 operator""o(unsigned long long n</tt><tt>)</tt><tt><br>
    </tt><tt>=C2=A0{}</tt><tt><br>
    </tt><tt><br>
    </tt><tt>unsigned int</tt><tt><br>
    </tt><tt>=C2=A0 operator""o(const char *</tt><tt> str, size_t len)</tt>=
<tt><br>
    </tt><tt>=C2=A0{}</tt><tt><br>
    </tt><tt><br>
    </tt><tt>unsigned int</tt><tt><br>
    </tt><tt>=C2=A0 operator""o(char c</tt><tt>)</tt><tt><br>
    </tt><tt>=C2=A0{}</tt><tt><br>
    </tt><tt><br>
      =C2=A0</tt><tt>auto perms0 =3D 644o;<br>
      <br>
    </tt><tt>=C2=A0auto perms1 =3D "</tt><tt>644"o;</tt><tt><br>
      <br>
      =C2=A0</tt><tt><tt>auto perms2 =3D '\</tt><tt>644'o;</tt><tt><br>
      </tt></tt><tt><br>
    </tt><tt>Or have a perms literal operator since that is the greatest
      use of octal.</tt><tt><br>
      This could be part of filesystem_v2<br>
      <br>
      filesystem::perms<br>
    </tt><tt>=C2=A0 operator""perm(</tt><font face=3D"Courier">.)<br>
      =C2=A0{}<br>
      <br>
      etc.<br>
      <br>
      Then with the new 0o644 format, compiler warnings of old-style
      octal, we could fix some bugs and have a migration path.<br>
      <br>
    </font>
    <blockquote
cite=3D"mid:CADvuK0Lv0czK+rGVr3M1wyg4y1w01Sc4HR-9W0g4HPob_ZS-ig@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div style=3D"word-wrap:break-word"><span class=3D"">
                  <div>
                    <blockquote type=3D"cite"><span
                        style=3D"float:none;display:inline!important">*
                        comparisons to octal macros, like:</span><br>
                      <font face=3D"Courier"><span
                          style=3D"float:none;display:inline!important">#
                          =C2=A0=C2=A0=C2=A0if __HP_aCC-0 &lt; 060000</span=
><br>
                      </font></blockquote>
                  </div>
                  <div><span style=3D"float:none;display:inline!important">=
<br>
                    </span></div>
                </span>
                <div><span style=3D"float:none;display:inline!important">Th=
is
                    appears to be in error. Boost, at least,=C2=A0<a
                      moz-do-not-send=3D"true"
href=3D"http://www.boost.org/doc/libs/1_58_0/boost/config/compiler/hp_acc.h=
pp"
                      target=3D"_blank">treats</a>=C2=A0<font face=3D"Couri=
er">__HP_aCC</font>
                    as a decimal literal:</span></div>
                <div><span style=3D"float:none;display:inline!important"><b=
r>
                  </span></div>
                <div>
                  <blockquote type=3D"cite"><span
                      style=3D"float:none;display:inline!important"><font
                        face=3D"Courier">#if (__HP_aCC &gt;=3D 60000) ||
                        ((__HP_aCC &gt; 38000) &amp;&amp;
                        defined(__hpxstd98))</font><br>
                    </span></blockquote>
                </div>
                <div><span style=3D"float:none;display:inline!important"><b=
r>
                  </span></div>
                <div><span style=3D"float:none;display:inline!important">Th=
is
                    also mentions a prior version A.03.80, which
                    couldn=E2=80=99t have been encoded in octal at all.=C2=
=A0</span>Your
                  quote includes a useless =E2=80=9C<font face=3D"Courier">=
-0</font>=E2=80=9D
                  which looks vaguely like a superstitious
                  octal-banishing incantation. I'm inclined to believe
                  Boost here.</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I believe "-0" is an incantation to deal with the
              situation where __HP_aCC is #defined as the empty string.</di=
v>
            <div>If it expands to empty-string, then indeed (-0 &lt;
              060000) is true, instead of being a syntax error.</div>
            <div>However, I think you're right that this octal was
              unintended.</div>
            <div><br>
            </div>
            <div>=E2=80=93Arthur</div>
          </div>
        </div>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to a topic in
      the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this topic, visit <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IXXXDo=
3Y1rA/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/IXXXDo3Y1rA/unsubscribe</a>.<br>
      To unsubscribe from this group and all its topics, send an email
      to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Boundary_(ID_C6NOrEBngYKHPzQtL+dLQg)--

.

On 07/02/2015 06:28 PM, Thiago Macieira wrote:

> Would be nice if you tested aC++, if you still have access to it. I'm pre=
tty
> sure I'd have tested aCC back when I wrote that code, but my tests might =
have
> been false positives.

I no longer have access to the compiler, but I still have the output of
the pre-defined macros for version A.03.60, which confirms that the
number is decimal:

_ILP32 =3D 1
_PA_RISC2_0 =3D 1
__HP_CXD_SPP =3D 1
__HP_aCC =3D 36000
__STDCPP__ =3D 1
__TaligentCPlusPlus__ =3D 0x100
__cplusplus =3D 199711L
__hp9000s800 =3D 1
__hppa =3D 1
__hpux =3D 1
__parisc =3D 1
__unix =3D 1

> Another compiler that used to use decimal was Sun Studio. Then they switc=
hed
> to hex: 509 =E2=86=92 0x50a.

AFAIK, they went from 0x509 (5.9) to 0x5100 (5.10).

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.