010 is 8 and not 10 :(

[Kenny McCormack]

Are they riding in an Ambuhlance?

You may have a point there.

And note, BTW, that MHA actually posts like a human being on other
groups (specifically, RGB, where I find his posts worth reading).
But, for some reason, CLC just brings out the lunatic in him.

 

[Al Balmer]

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 ?

It's more than a convention, it's part of the C language standard.

Numbers starting with '0' are octal, numbers starting with '0x' or
'0X' are hexadecimal.

 

[Keith Thompson]

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.

I use octal constants all the time. Well, actually, only one
particular octal constant.

0

 

[Mark Bluemel]

Mark Bluemel wrote: ....

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.

Whoosh!

 

[Army1987]

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.

Python uses it, too.

 

[Mark Bluemel]

Python uses it, too.

As does Java, unsurprisingly.

 

[Philip Potter]

I use octal constants all the time. Well, actually, only one
particular octal constant.

0

Is that really an octal constant? After all, 0x isn't a hex constant...

 

[Richard Heathfield]

Philip Potter said:

Is that really an octal constant?

Yes. The Standard says, in 6.4.4.1 (this is C99 btw but it's the same
deal in C90):
3 A decimal constant begins with a nonzero digit and consists of a
sequence of decimal digits. An octal constant consists of the prefix 0
optionally followed by a sequence of the digits 0 through 7 only. A
hexadecimal constant consists of the prefix 0x or 0X followed by a
sequence of the decimal digits and the letters a (or A) through f (or
F) with values 10 through 15 respectively.

After all, 0x isn't a hex
constant...

True enough, although it can be as much as two thirds of a hex constant.

 

[slebetman]

As does Java, unsurprisingly.

Actually, due to the influence of C and due to the fact that most
newer and modern languages are in fact implemented in C this
convention is the norm. Perl use it, Javascript use it, even the new-
kid-on-the-block Ruby use it.
Tcl is one language that currently also use this convention but is in
the process of getting rid of it - the consensus in the tcl community
is that this is a bug and nobody really uses it. Of course, such raise-
your-hand voting stunt to check if removing 0 octals breaks anyone's
code and getting them to agree to fix it when the change comes is not
feasible for C or any other language with a user base larger than Tcl.

 

[Charlie Gordon]

Actually, due to the influence of C and due to the fact that most
newer and modern languages are in fact implemented in C this
convention is the norm. Perl use it, Javascript use it, even the new-
kid-on-the-block Ruby use it.

The case of Javascript is not final:

ECMA 262 (ECMAScript, the Standard for javascript)

B.1 Additional Syntax

Past editions of ECMAScript have included additional syntax and semantics
for specifying octal literals and
octal escape sequences. These have been removed from this edition of
ECMAScript. This non-normative
annex presents uniform syntax and semantics for octal literals and octal
escape sequences for compatibility
with some older ECMAScript programs.

The C octal syntax is no longer recognized except for the number 0.

 

[Army1987]

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.

Not everyone who teaches C or writes books about C knows C. For
example, I was never told about octal constants in my class, and
the textbook I used didn't know about them (or about the fact that
main() returns an int, either...)
[snip insults to the OP]

 

[Peter 'Shaggy' Haywood]

Groovy hepcat David Mathog was jivin' in comp.lang.c on Fri, 14 Sep 2007
1:44 am. It's a cool scene! Dig it.

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.

I am guessing, but I reckon I know why zero was chosen. When a C
parser fetches a token from a lexical analyser, how does the lexical
analyser determine whether to send back an identifier or an octal
number? A token consisting of the letter 'o' (upper or lower case)
followed by one or more digits is an identifier, not a number. Thus, an
octal number must be a token consisting of a zero optionally followed
by digits from 0 to 7.
It's simple when you think about it, really.

 

[Willem]

Peter wrote:
) I am guessing, but I reckon I know why zero was chosen. When a C
) parser fetches a token from a lexical analyser, how does the lexical
) analyser determine whether to send back an identifier or an octal
) number? A token consisting of the letter 'o' (upper or lower case)
) followed by one or more digits is an identifier, not a number. Thus, an
) octal number must be a token consisting of a zero optionally followed
) by digits from 0 to 7.
) It's simple when you think about it, really.

Or you could have had 0x for hex, 0o for octal and 0b for binary.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

Peter wrote:
) I am guessing, but I reckon I know why zero was chosen. When a C
) parser fetches a token from a lexical analyser, how does the lexical
) analyser determine whether to send back an identifier or an octal
) number? A token consisting of the letter 'o' (upper or lower case)
) followed by one or more digits is an identifier, not a number. Thus, an
) octal number must be a token consisting of a zero optionally followed
) by digits from 0 to 7.
) It's simple when you think about it, really.

Or you could have had 0x for hex, 0o for octal and 0b for binary.

Yes (and Perl does use 0b for binary), but 0o could be written as 0O
unless you specifically disallow it.

 

[Dik T. Winter]

> Peter wrote:
> ) I am guessing, but I reckon I know why zero was chosen. When a C
> ) parser fetches a token from a lexical analyser, how does the lexical
> ) analyser determine whether to send back an identifier or an octal
> ) number? A token consisting of the letter 'o' (upper or lower case)
> ) followed by one or more digits is an identifier, not a number. Thus, an
> ) octal number must be a token consisting of a zero optionally followed
> ) by digits from 0 to 7.
> ) It's simple when you think about it, really.
>
> Or you could have had 0x for hex, 0o for octal and 0b for binary.

Of course. But when C started developing, there was no need for hex, but
there was need for octal. On most machines of that time addresses and
contents of words were expressed in octal. So the preceding 0 for octal
is legacy.

 

[Charlie Gordon]

Of course. But when C started developing, there was no need for hex, but
there was need for octal. On most machines of that time addresses and
contents of words were expressed in octal. So the preceding 0 for octal
is legacy.

The reason for octal preference then probably stems from historical word
sizes:
36 bit words = 12 octal digits
18 bit half-words = 6 octal digits
6 or 9 bit chars = 2 or 3 octal digits
and of course unix permissions in groups of 3 bits.

 

[Dik T. Winter]

> "Dik T. Winter" <[email protected]> a écrit dans le message de news: ....
>
> The reason for octal preference then probably stems from historical word
> sizes:
> 36 bit words = 12 octal digits
> 18 bit half-words = 6 octal digits
> 6 or 9 bit chars = 2 or 3 octal digits
> and of course unix permissions in groups of 3 bits.

Not really. I think it is the other wise around. The (later) preference
of word-sizes that were a multiple of three came from the easily understood
octal arithmetic. Very early machines had strange word-sizes, like 41 (I
think that was the KDF-9). The first machine I ever did work on had a
word-size of 27, the next had 60 bit words. But octal was thoroughly
used in computers, even if the words had 16 bits. (Look at any PDP-11
manual: all information is in octal while it was a 16-bits machine, or
for that matter at the manuals for the Intel 8008 and 8080.) Still now
on Intel processors instructions are better understood if you interprete
them in octal.