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