0o for Octal?

[Olaf van der Spek]

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..

[Tony V E]

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.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Jens Maurer]

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

[Shachar Shemesh]

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

[3dw...@verizon.net]

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.

[John Bytheway]

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

[Olaf van der Spek]

2015-06-24 20:35 GMT+02:00 Tony V E <tvan...@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.

[David Krauss]

On 2015–06–26, at 12:51 PM, Olaf van der Spek <olafv...@gmail.com> wrote:

2015-06-24 20:35 GMT+02:00 Tony V E <tvan...@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.

Except when calling POSIX ::stat, which seems beyond the reach of WG21. What’s the status of namespace posix, by the way? Has interest dwindled 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 unspecified,” in POSIX:2004, to "The <sys/stat.h> header shall define the following symbolic constants for the file mode bits encoded in type mode_t, with the indicated numeric values,” in POSIX:2013. 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" {}?

[Jens Maurer]

On 06/26/2015 07:35 AM, David Krauss wrote:
>
>> On 2015–06–26, at 12:51 PM, Olaf van der Spek <olafv...@gmail.com <mailto:olafv...@gmail.com>> wrote:
>>
>> 2015-06-24 20:35 GMT+02:00 Tony V E <tvan...@gmail.com <mailto:tvan...@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.
>
> Except when calling POSIX ::stat, which seems beyond the reach of WG21. What’s the status of namespace posix, by the way? Has interest dwindled to nothing?

There have been a few meetings of a small group trying to come up with standardized
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 have vanished.

I'd call this dead for now.

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

And then, there's the desire of C++ to actually create a higher-level interface
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 bits and the contents of the remaining members of the stat structure are unspecified,” in POSIX:2004 <http://pubs.opengroup.org/onlinepubs/009695399/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 mode_t, with the indicated numeric values,” 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.

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

Jens

[David Krauss]

Unfortunately, it looks like the octal constants went from "File mode bits and the contents of the remaining members of the stat structure are unspecified,” in POSIX:2004 <http://pubs.opengroup.org/onlinepubs/009695399/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 mode_t, with the indicated numeric values,” 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.

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

I don’t see anything to that effect. Why would they introduce something if they didn’t want it to be used?

It says that the macros don’t need an explicit cast to mode_t, which is handy if mode_t is long. However, it appears to be short on Mac/BSD and Windows, and int on Linux. I guess it could be long on a Linux-like system 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. Unfortunately, that’s probably among the more invincible POSIX headers. I don’t suppose it can ever be completely replaced by a C++ binding, since it’s the access point for so many OS-specific features.

My 2¢, octal numbers have done enough damage already without 0o. (Alternate spelling 0O, right?)

[Thiago Macieira]

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

[inkwizyt...@gmail.com]

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

[Olaf van der Spek]

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

No alternate spelling. :p



--
Olaf

[Thiago Macieira]

On Friday 26 June 2015 10:12:31 inkwizyt...@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.

[Olaf van der Spek]

2015-06-26 19:34 GMT+02:00 Thiago Macieira <thi...@macieira.org>:
> On Friday 26 June 2015 10:12:31 inkwizyt...@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

[Nevin Liber]

On 26 June 2015 at 12:36, Olaf van der Spek <olafv...@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:ne...@eviloverlord.com>  (847) 691-1404

[Thiago Macieira]

On Friday 26 June 2015 12:45:05 Nevin Liber wrote:
> On 26 June 2015 at 12:36, Olaf van der Spek <olafv...@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.

[Tony V E]

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

2015-06-24 20:35 GMT+02:00 Tony V E <tvan...@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.

[Olaf van der Spek]

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? 

 

[Arthur O'Dwyer]

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.

[David Krauss]

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… and proposing alternative trigraphs. Oh wait, that actually happened.

(To be pedantic, see POSIX 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 enumerations at the implementation’s discretion. The problem is completely unsolvable except by decoupling the C++ interface from the C header. I didn’t mention this earlier because the discussion seemed to be over…)

[Thiago Macieira]

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).

[Olaf van der Spek]

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

[Ed Smith-Rowland]

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.

[Olaf van der Spek]

2015-06-27 16:57 GMT+02:00 Ed Smith-Rowland <3dw...@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

[Ed Smith-Rowland]

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.

[John Bytheway]

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 <3dw...@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

[Myriachan]

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

[Olaf van der Spek]

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

[Thiago Macieira]

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.

[Ron]

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.

[David Krauss]

On 2015–07–02, at 9:43 AM, Thiago Macieira <thi...@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.

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

This appears to be in error. Boost, at least, treats __HP_aCC as a decimal literal:

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

This also mentions a prior version A.03.80, which couldn’t have been encoded in octal at all. Your quote includes a useless “-0” 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 octal from Qt, we’re left with only file permissions.

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 backward-compatibility code, with #ifdef EXTENDED_SDB_BASIC_TYPES switching it to hexadecimal. It’s likely already due for removal.

It’s valid to consider GCC here, because it’s transitioning to C++, but I don’t think the Linux kernel is ever likely to switch.

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… if they can filter out permissions.

[Arthur O'Dwyer]

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

On 2015–07–02, at 9:43 AM, Thiago Macieira <thi...@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.

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

This appears to be in error. Boost, at least, treats __HP_aCC as a decimal literal:

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

This also mentions a prior version A.03.80, which couldn’t have been encoded in octal at all. Your quote includes a useless “-0” 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.

–Arthur

[Thiago Macieira]

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.

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

> It’s valid to consider GCC here, because it’s transitioning to C++, but I
> don’t 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
fixed too. There must be two orders of magnitude more hex than octal in the
kernel, if you exclude the permissions.

The problem is that the file permissions are *everywhere* due to "everything is
a file" and virtual filesystem support. 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.

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

[David Krauss]

On 2015–07–02, at 2:04 PM, Thiago Macieira <thi...@macieira.org> wrote:

The problem is that the file permissions are *everywhere* due to "everything is 
a file" and virtual filesystem support.

Where is everywhere? I’m curious, do they ever really support much application-level behavior, or are they only viral inside lower levels of the software stack?

I notice that Qt translates permission bits to hex.

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.

In the other thread, “POSIX binding,” I make a case for disconnecting 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.

[Bjorn Reese]

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.

[Olaf van der Spek]

2015-07-02 3:43 GMT+02:00 Thiago Macieira <thi...@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

[Olaf van der Spek]

2015-07-02 5:02 GMT+02:00 David Krauss <pot...@gmail.com>:
> 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… if 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...


--
Olaf

[Thiago Macieira]

On Thursday 02 July 2015 15:37:02 David Krauss wrote:
> > On 2015–07–02, at 2:04 PM, Thiago Macieira <thi...@macieira.org> wrote:
> >
> > The problem is that the file permissions are *everywhere* due to
> > "everything is a file" and virtual filesystem support.
>
> Where is everywhere? I’m curious, do they ever really support much
> 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" means
"everywhere inside the Linux kernel sources". If you grep for 0444, 0644 and
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
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.
>
> In the other thread, “POSIX binding,” I make a case for disconnecting 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 permissions
is in open / creat. Sure, there are other calls, but they must happen two or
more orders of magnitude less frequently.

And to be honest, I wouldn't worry too much about the POSIX open function when
creating a file, since that's usually wrapped around a class that will manage
doing so correctly under a transaction (à la QSaveFile).

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

[Thiago Macieira]

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

Another compiler that used to use decimal was Sun Studio. Then they switched
to hex: 509 → 0x50a.

[Thiago Macieira]

On Thursday 02 July 2015 13:21:49 Olaf van der Spek wrote:
> 2015-07-02 3:43 GMT+02:00 Thiago Macieira <thi...@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.

[Ed Smith-Rowland]

On 07/01/2015 11:31 PM, Arthur O'Dwyer wrote:

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

On 2015–07–02, at 9:43 AM, Thiago Macieira <thi...@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 = 644o;

 auto perms1 = "644"o;

 auto perms2 = '\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 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 __HP_aCC as a decimal literal:

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

This also mentions a prior version A.03.80, which couldn’t have been encoded in octal at all. Your quote includes a useless “-0” 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.

–Arthur

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit 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 std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Bjorn Reese]

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 pretty
> 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 = 1
_PA_RISC2_0 = 1
__HP_CXD_SPP = 1
__HP_aCC = 36000
__STDCPP__ = 1
__TaligentCPlusPlus__ = 0x100
__cplusplus = 199711L
__hp9000s800 = 1
__hppa = 1
__hpux = 1
__parisc = 1
__unix = 1

> Another compiler that used to use decimal was Sun Studio. Then they switched
> to hex: 509 → 0x50a.

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