010 is 8 and not 10 :(

[karthikbalaguru]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

Thx,
Karthik Balaguru

 

[Ian Collins]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

Such as?

The convention goes back a long way and is never likely to change.

 

[karthikbalaguru]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

Thx,
Karthik Balaguru

It should be : (No comma in the earlier snapshot of code)

Example -
int numbers[] = { 001,
010 // This is treated as 8 and not as 10 :
( Strange
};

Thx,
Karthik Balaguru

 

[Richard Bos]

I find that numbers beginning with a zero are evaluated in base 8.

No shit, Sherlock. This is how C is, and always has been. Deal.

Richard

 

[Martin Ambuhl]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Exactly as defined by the language.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange

No it's not. Anyone who was awake during the first day of their lessons
in C knows that integers represented by 0 followed by digits are octal
and integers represented by 0x or 0X followed by digits are hex.
But some people don't stay awake in class or read their textbooks and
then call the obvious strange.

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

You were shocked by what you should have known, had you not been
comatose. How strange.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

That things are just fine as they are, as long as you don't ever get a
programming job, or at least until your attention span grows to, say, 15
seconds.

 

[Mark Bluemel]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Just as it says in the section entitled "Constants" in my copy of
Kernighan and Ritchie? How surprising...

There should be someother convention ? What do you think ?

I think you need to read the manual...

 

[Philip Potter]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

If you find that this is a problem, there are editors which highlight octal
constants (such as 010) in a different colour to decimal constants (such as 10)
to make it obvious that it means something different.

Philip

 

[karthikbalaguru]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

If you find that this is a problem, there are editors which highlight octal
constants (such as 010) in a different colour to decimal constants (such as 10)
to make it obvious that it means something different.

Philip

Thats a coool idea to avoid mistakes without requesting a change in C
Language.
Thx.

Karthik Balaguru

 

[Mark Bluemel]

Thats a coool idea to avoid mistakes without requesting a change in C
Language.

I think you should request the change, just to see what response you get...

 

[Chris Hills]

Hi,

I find that numbers beginning with a zero are evaluated in base 8.

Example -
int numbers[] = { 001,
010, // This is treated as 8 and
not as 10 Strange
};

I find that compiler does not complain and continues performing after
converting the octal to the corresponding decimal value .
Initially i was shocked , But later practised to it.

This option of '0' before a number to treat it as octal in C causes
problem sometimes(Easy path for error) .
Octal, we just have a 0 infront of the number in 'C' .
There should be someother convention ? What do you think ?

If you find that this is a problem, there are editors which highlight octal
constants (such as 010) in a different colour to decimal constants
(such as 10)
to make it obvious that it means something different.

Philip

Thats a coool idea to avoid mistakes without requesting a change in C
Language.
Thx.

Karthik Balaguru

1
"cool" wasn't cool the first time it was in fashion 40 years ago. I
remind my "cool" sons about that. "Man" and "dude" are also back.
Nostalgia isn't etc...

2
Syntax highlighting has been around almost as long as colour monitors.
(About 25 years.) Strangely that is no recognised standard for colour
highlighting.

3
Octal constants have always been in the C language. If you did not know
that you need a BASIC course in C programming.

4
Many coding standards ban the use of Octal constants

5
0.123 is a FLOAT not an Octal number

6
Request for change in C language denied

 

[Philip Potter]

1
"cool" wasn't cool the first time it was in fashion 40 years ago. I
remind my "cool" sons about that. "Man" and "dude" are also back.
Nostalgia isn't etc...

Strange, I can't find any reference to "cool" in the C standard. It must be a
compiler extension on his platform

2
Syntax highlighting has been around almost as long as colour monitors.
(About 25 years.) Strangely that is no recognised standard for colour
highlighting.

Yes, but some syntax highlighters do not distinguish octal constants from
decimal constants. The OP may have this problem.

3
Octal constants have always been in the C language. If you did not know
that you need a BASIC course in C programming.

Or perhaps he forgot? Quite reasonable for a beginner; he might have read the
relevant section, but since octal constants are so rarely used there's little to
back up the learning process. I only really remember about octal constants
because my editor colours them in.

5
0.123 is a FLOAT not an Octal number

Actually, it's a double. 0.123f is a float.

 

[Richard Tobin]

I find that numbers beginning with a zero are evaluated in base 8.

Yes, this is the convention used by C. There's no chance of changing
it - it would break existing programs - but I doubt anyone designing
a programming language now would use such an error-prone convention.

-- Richard

 

[Mark Bluemel]

Yes, this is the convention used by C. There's no chance of changing
it - it would break existing programs - but I doubt anyone designing
a programming language now would use such an error-prone convention.

dmr should probably have used a convention analogous to that for
hexadecimal. Hex is indicated by a zero followed by a letter 'x', I
suggest octal could have been indicated by a zero followed by a letter
'o'...

 

[Kenny McCormack]

That things are just fine as they are, as long as you don't ever get a
programming job, or at least until your attention span grows to, say, 15
seconds.

Paramedics are being dispatched to the home of "Martin Ambuhl" as we speak.

Don't worry; help is on the way.

 

[Charlie Gordon]

dmr should probably have used a convention analogous to that for
hexadecimal. Hex is indicated by a zero followed by a letter 'x', I
suggest octal could have been indicated by a zero followed by a letter
'o'...

I have a more general suggestion, compatible with the preprocessor token
definitions:

[decimal number between 0 and 36] 'x' [digits or letters within the
constraint of the base specified before the x]

for example the decimal value 10 could be represented as:

2x1010 3x101 4x22 5x20 6x14 7x13 8x12 9x11 10x10 11xa 11xA ...

base 1 is a special case: 1x1111111111 but also 1x101010101011111000 ... and
infinitely many variations.

 

[Joachim Schmitz]

dmr should probably have used a convention analogous to that for
hexadecimal. Hex is indicated by a zero followed by a letter 'x', I
suggest octal could have been indicated by a zero followed by a letter
'o'...

I have a more general suggestion, compatible with the preprocessor token
definitions:

[decimal number between 0 and 36] 'x' [digits or letters within the
constraint of the base specified before the x]

for example the decimal value 10 could be represented as:

2x1010 3x101 4x22 5x20 6x14 7x13 8x12 9x11 10x10 11xa 11xA ...

base 1 is a special case: 1x1111111111 but also 1x101010101011111000 ...
and infinitely many variations.

base 1 won't have 1s, only 0s would it?

 

[Old Wolf]

Paramedics are being dispatched to the home of "Martin Ambuhl" as we speak.

Don't worry; help is on the way.

Are they riding in an Ambuhlance?

 

[Chris Dollin]

base 1 won't have 1s, only 0s would it?

`1` is the traditional token.

 

[David Mathog]

dmr should probably have used a convention analogous to that for
hexadecimal. Hex is indicated by a zero followed by a letter 'x', I
suggest octal could have been indicated by a zero followed by a letter
'o'...

Maybe he was concerned about "oh" vs. "zero" confusion? I don't know
about you folks, but I try to never mix "oh" and "zero" in variable
names specifically to avoid this particular problem.
Still, I do agree in spirit with the OP that the C use of a leading zero
to have a special meaning was a bit daft. It's almost like it was an
inside joke: often one can't distinguish "oh" from "zero", so rather
than having an octal constant be "oh"37 we'll make it "zero"37.

Not that this will ever change at this late date but I always thought
the syntax from (most versions?) of Fortran to be much clearer: '0A'x,
'13'o, or 10. Apparently in recent versions of Fortran the letter can
also precede the string.

Regards,

David Mathog

 

[Ben Bacarisse]

dmr should probably have used a convention analogous to that for
hexadecimal.

The leading 0 notation comes from B into C so maybe K Thompson is the
one who decided on that (although DMR had a hand in B too).

It does not come from BCPL into B (BCPL was often cited as a precursor
to B). BCPL has #o77, #b11111 and #x3F together with the convenience
of having _ ignored in numbers (1_234_567 and #x_FF_FE_EB are all
legal). It seems a shame that newer languages do not always have the
best from the older ones!