www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 0nnn octal notation considered harmful

reply spir <denis.spir gmail.com> writes:
Hello,

Just had a strange bug --in a test func!-- caused by this notation. This is due 
in my case to the practice (common, I guess) of "pretty printing" int numbers 
using %0nd or %0ns format, to get a nice alignment. Then, if one feeds back 
results into D code, they are interpreted as octal...
Now, i know it: will pad with spaces instead ;-)

Copying a string'ed integer is indeed not the only this notation is bug-prone: 
prefixing a number with '0' should not change its value (!). Several 
programming languages switched to another notation; like 0onnn, which is 
consistent with common hex & bin notations and cannot lead to 
misinterpretation. Such a change would be, I guess, backward compatible; and 
would not be misleading for C coders.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
next sibling parent Jim <bitcirkel yahoo.com> writes:
spir Wrote:


 Hello,
 
 Just had a strange bug --in a test func!-- caused by this notation. This is
due 
 in my case to the practice (common, I guess) of "pretty printing" int numbers 
 using %0nd or %0ns format, to get a nice alignment. Then, if one feeds back 
 results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)
 
 Copying a string'ed integer is indeed not the only this notation is bug-prone: 
 prefixing a number with '0' should not change its value (!). Several 
 programming languages switched to another notation; like 0onnn, which is 
 consistent with common hex & bin notations and cannot lead to 
 misinterpretation. Such a change would be, I guess, backward compatible; and 
 would not be misleading for C coders.



Fine with me. I've never used octal numbers (intently!). I guess some notation
is needed for them, if not for historical reasons.
Feb 11 2011
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
We actually have a library replacement for octal literals:

http://dpldocs.info/octal

But until the C style syntax is disallowed, it doesn't change
anything. But, Walter is resistant to the change, last I knew.
Feb 11 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:


 like 0onnn, which is 
 consistent with common hex & bin notations and cannot lead to 
 misinterpretation. Such a change would be, I guess, backward compatible; and 
 would not be misleading for C coders.



The 0nnn octal syntax is bug-prone, and not explicit, it's out of place in a
language like D that's designed to be a bit safer than C.
The 0onnn syntax adopted by Python3 is safer, more explicit, it's good enough.
But the leading zero syntax can't be kept in D for backwards C compatibility,
so it needs to be just disallowed statically...

Walter likes the C octal syntax as a personal thing. Andrei prefers a syntax
like octal!xxxx that's less compact, even more explicit, library-defined, and
it has a corner case (when numbers become very large you need a string):
http://www.digitalmars.com/d/2.0/phobos/std_conv.html#octal

Bye,
bearophile
Feb 11 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1504.1297453559.4748.digitalmars-d puremagic.com...

 Hello,

 Just had a strange bug --in a test func!-- caused by this notation. This 
 is due in my case to the practice (common, I guess) of "pretty printing" 
 int numbers using %0nd or %0ns format, to get a nice alignment. Then, if 
 one feeds back results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)

 Copying a string'ed integer is indeed not the only this notation is 
 bug-prone: prefixing a number with '0' should not change its value (!). 
 Several programming languages switched to another notation; like 0onnn, 
 which is consistent with common hex & bin notations and cannot lead to 
 misinterpretation. Such a change would be, I guess, backward compatible; 
 and would not be misleading for C coders.



Yea, octal!"nnn" has already made the exceedingly rare uses of octal 
literals completely obsolete *long* ago. I know I for one am getting really 
tired of this completely unnecessary landmine in the language continuing to 
exist. The heck with std.xml, if anything, *this* needs nuked. If silently 
changed behavior is a problem, then just make it an error. Done. Minefield 
cleared.
Feb 11 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
spir napisa=B3:


 Just had a strange bug --in a test func!-- caused by this notation. This =




 in my case to the practice (common, I guess) of "pretty printing" int num=




 using %0nd or %0ns format, to get a nice alignment. Then, if one feeds ba=




 results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)
=20
 Copying a string'ed integer is indeed not the only this notation is bug-p=




 prefixing a number with '0' should not change its value (!). Several=20
 programming languages switched to another notation; like 0onnn, which is=




 consistent with common hex & bin notations and cannot lead to=20
 misinterpretation. Such a change would be, I guess, backward compatible; =




 would not be misleading for C coders.



This has been discussed before. There's octal!123 in Phobos if you don't li=
ke these confusing literals but they stay because Walter likes them.=20

--=20
Tomek
Feb 11 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/11/2011 10:54 PM, Nick Sabalausky wrote:

 "spir"<denis.spir gmail.com>  wrote in message
 news:mailman.1504.1297453559.4748.digitalmars-d puremagic.com...

 Hello,

 Just had a strange bug --in a test func!-- caused by this notation. This
 is due in my case to the practice (common, I guess) of "pretty printing"
 int numbers using %0nd or %0ns format, to get a nice alignment. Then, if
 one feeds back results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)

 Copying a string'ed integer is indeed not the only this notation is
 bug-prone: prefixing a number with '0' should not change its value (!).
 Several programming languages switched to another notation; like 0onnn,
 which is consistent with common hex&  bin notations and cannot lead to
 misinterpretation. Such a change would be, I guess, backward compatible;
 and would not be misleading for C coders.



 Yea, octal!"nnn" has already made the exceedingly rare uses of octal
 literals completely obsolete *long* ago. I know I for one am getting really
 tired of this completely unnecessary landmine in the language continuing to
 exist. The heck with std.xml, if anything, *this* needs nuked. If silently
 changed behavior is a problem, then just make it an error. Done. Minefield
 cleared.



Thanks you (and Bearohile, IIRC) for the tip about octal!"nnn". Useless for me, 
unfortunately, since my problem (as you suggest) is not with how to write them, 
but the sheer existence of this $%*£µ#! notation ;-) What we need is a time 
bomb sent to ~ 1973.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 11 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
spir wrote:

 Hello,
 
 Just had a strange bug --in a test func!-- caused by this notation. This 
 is due in my case to the practice (common, I guess) of "pretty printing" 
 int numbers using %0nd or %0ns format, to get a nice alignment. Then, if 
 one feeds back results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)
 
 Copying a string'ed integer is indeed not the only this notation is 
 bug-prone: prefixing a number with '0' should not change its value (!). 
 Several programming languages switched to another notation; like 0onnn, 
 which is consistent with common hex & bin notations and cannot lead to 
 misinterpretation. Such a change would be, I guess, backward compatible; 
 and would not be misleading for C coders.
 
 Denis



Octal should just be dropped entirely. Retaining built-in octal literals 
is like retaining support for EBCDIC. It's a relic of a time before 
hexadecimal was invented.
Feb 12 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 12/02/2011 18:27, Don wrote:

 spir wrote:




 Copying a string'ed integer is indeed not the only this notation is bug-prone:
prefixing
 a number with '0' should not change its value (!).






Indeed.  Even more confusing is that when it's a floating point it doesn't. 
But see
http://d.puremagic.com/issues/show_bug.cgi?id=3251


 Several programming languages switched to another notation; like 0onnn, which
is
 consistent with common hex & bin notations and cannot lead to
misinterpretation. Such
 a change would be, I guess, backward compatible; and would not be misleading
for C
 coders.






Indeed, does anyone know why the 0xxx notation was chosen in the first place?


 Octal should just be dropped entirely. Retaining built-in octal literals is
like retaining
 support for EBCDIC. It's a relic of a time before hexadecimal was invented.



I once recall hearing that octal's main use lay on old mainframes that worked
in 15-bit 
units.

But it lives on in Unix file permission settings.  And is it still the form of
CompuServe 
user IDs?

Stewart.
Feb 16 2011
parent "Nick Sabalausky" <a a.a> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:ijgpgb$1apc$1 digitalmars.com...

 And is [octal] still the form of CompuServe user IDs?



Do those still exist?
Feb 17 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Feb 2011 17:52:34 -0500, Tomek Sowiński <just ask.me> wrote:


 spir napisał:


 Just had a strange bug --in a test func!-- caused by this notation.  
 This is due
 in my case to the practice (common, I guess) of "pretty printing" int  
 numbers
 using %0nd or %0ns format, to get a nice alignment. Then, if one feeds  
 back
 results into D code, they are interpreted as octal...
 Now, i know it: will pad with spaces instead ;-)

 Copying a string'ed integer is indeed not the only this notation is  
 bug-prone:
 prefixing a number with '0' should not change its value (!). Several
 programming languages switched to another notation; like 0onnn, which is
 consistent with common hex & bin notations and cannot lead to
 misinterpretation. Such a change would be, I guess, backward  
 compatible; and
 would not be misleading for C coders.



 This has been discussed before. There's octal!123 in Phobos if you don't  
 like these confusing literals but they stay because Walter likes them.



I think the point is he *doesn't* want to use octal literals.

-Steve
Feb 14 2011