trinity/src
1
0
Fork 0
Code

fix article

Browse Source
This commit is contained in:
dtb 2022-05-31 21:24:59 -04:00
parent d59fd50600
commit a13fbc7d6d
1 changed files with 36 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
homepage/knowledge/c78.html
View File

@ -48,38 +48,56 @@ This page documents those incompatibilities and relative oddities.
I have never done (and probably never will do) extensive programming in pre-ANSI C.
These incompatibilities were discovered out of Appendix C in <I>The C Programming Language, 2nd ed.</I> but are described further.
</P>
<!--<H2 ID="octal89"><CODE>8</CODE> and <CODE>9</CODE> as valid octal digits</H2>
<H2 ID="octal89"><CODE>8</CODE> and <CODE>9</CODE> as valid octal digits</H2>
<UL>
<LI><A HREF="https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c">UNIX V6 C compiler source directory</A></LI>
</UL>
<PRE>
main()
{
int i;
for(i = 0; i &lt; 10; ++i)
printf("%c\t%o\n", i + '0', i);
printf("%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n",
00, 01, 02, 03, 04, 05, 06, 07, 08, 09
);
}
</PRE>
<P>
In pre-ANSI C, <CODE>8</CODE> and <CODE>9</CODE> were valid octal digits corresponding to <CODE>10</CODE> and <CODE>11</CODE>.
On my machine, the GNU C compiler emits the following errors (this omits warnings) for the preceding piece of code:
</P>
<PRE>
snippet.c:4:49: error: invalid digit "8" in octal constant
4 | 00, 01, 02, 03, 04, 05, 06, 07, 08, 09
| ^~
snippet.c:4:53: error: invalid digit "9" in octal constant
4 | 00, 01, 02, 03, 04, 05, 06, 07, 08, 09
| ^~
</PRE>
<P>
This is because in C (both pre-standardization and post-ANSI) integer constants with leading zeroes are parsed as octal (base 8) numbers.
In pre-ANSI C, <CODE>8</CODE> and <CODE>9</CODE> were valid octal digits corresponding to <CODE>010</CODE>(b8) and <CODE>11</CODE>(0b8).
This is documented in <I>The C Programming Language</I>, Appendix A, subsection 2.4.1, and evidenced by the preceding code block.
The following is output of the compiled program in UNIX V6 on an emulated PDP-11:
</P>
<PRE>
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 10
9 11
0
1
2
3
4
5
6
7
8
9
</PRE>
<P>
This behavior exists within <CODE>/usr/source/c/c0t.s</CODE>, which is a PDP-11 assembler file that parses integer constants (as far as I can tell).
This file provides <CODE>getnum</CODE>, a function used in <CODE>/usr/source/c/c00.c</CODE>.
My theory is that this behavior is a side-effect of a very efficient but imperfect method of parsing integer constants from a file stream,
and that this implementation was "good enough" and informally the behavior of a C compiler supplied invalid octal constants was just undefined.
My theory is that this behavior is a side-effect of a very efficient but imperfect method of parsing integer constants from a file stream.
</P>
<P>
This wouldn't be a significant or even noticeable error; most programmers wouldn't use <CODE>8</CODE> or <CODE>9</CODE> as octal digits anyway.
If not for its documentation within <I>The C Programming Language</I> it would probably be an obscure bug.
This is also mentioned in <I>The C Programming Language, 2nd ed.</I> in Appendix C.
</P>
-->
</BODY>
</HTML>