Earlier quoted context omitted.
Never using a space before the paren is more consistent. I don't know why people put a space there...
I don't want my function calls to be consistent with control structures.
Dennis Ritchie's first C compiler on Github
61–70 of 88 posts
Re: Dennis Ritchie's first C compiler on Github
#62I don't understand this main(argc, argv) int argv[]; { Is that still valid today?
The int argv[]; is where the declaration for argv is happening and is being declared as an pointer for ints.
You can also see elsewhere in the code where they are passing pointer addresses (as int params) into functions and then using the address to build pointers referencing that data.
Re: Dennis Ritchie's first C compiler on Github
#63I don't understand this main(argc, argv) int argv[]; { Is that still valid today?
int foo(int i, int j) {...}
in Fortran you would do (! is comment) function foo(i, j)
integer :: foo !return type
integer :: i
integer :: j
!body goes here
Early C stuck to that style, so you would just put the names of the variables in the declaration, and then before the body give them types. The reason only argv is mentioned in that example is that C assumes a variable is an int if not declared otherwise, so there's no reason to put "int argc" like "int argv[]".Re: Dennis Ritchie's first C compiler on Github
#64I don't understand this main(argc, argv) int argv[]; { Is that still valid today?
All modern C compilers still accept this style for backwards compatibility. I'm not sure about C++ compilers.
Re: Dennis Ritchie's first C compiler on Github
#65He already used the right brace style (hanging braces, cuddled else) and the right indentation (tabs, not spaces).
tabs are an infinite source of pain and inconsistencies... Everyone must support the space character, it cannot be banned. But a simple commit hook to ban tabs can make indentation and alignment not get messed up over time with many collaborators with default-configured editors (that mess up and use tabs for alignment).
The tab character is a nice idea, but they do not seem to have worked out at all. I'd much rather have syntax-aware indenting in the editor, now that available compiler technology and CPU power make it practical.
Re: Dennis Ritchie's first C compiler on Github
#66What happens when you have more then 9 substitutions specified in the string? :D
edit: decided the code was a bit long to have pasted into my post. Can find it at the bottom of http://cm.bell-labs.com/cm/cs/who/dmr/last1120c/c03.c
Re: Dennis Ritchie's first C compiler on Github
#67I'm ashamed for having to google his name but for others like me here's a glimpse: "Dennis MacAlistair Ritchie (born September 9, 1941; found dead October 12, 2011) was an American computer scientist who "helped shape the digital era." He created the C programming language and, with long-time colleague Ken Thompson, the Unix operating system" http://en.wikipedia.org/wiki/Dennis_Ritchie
Re: Dennis Ritchie's first C compiler on Github
#68Earlier quoted context omitted.
tabs are an infinite source of pain and inconsistencies... Everyone must support the space character, it cannot be banned. But a simple commit hook to ban tabs can make indentation and alignment not get messed up over time with many collaborators with default-configured editors (that mess up and use tabs for alignment).
The inventor of the tab character is on my list of people to assassinate when they're young if I ever get access to a time machine, the other people on the list being Hitler and Charles Douglass. The tab character is a nice idea, but they do not seem to have worked out at all. I'd much rather have syntax-aware indenting in the editor, now that available compiler technology and CPU power make it practical.
You could even make a plugin that works without collaboration by others: check out the file in your preferred style and transform the changes back into the original style.
Re: Dennis Ritchie's first C compiler on Github
#69Can anyone explain the naming of files? c00.c, c01.c etc
Re: Dennis Ritchie's first C compiler on Github
#70I don't understand this main(argc, argv) int argv[]; { Is that still valid today?
To explain further:
main(argc, argv)
int argv[]; {
is equivalent to: int main(int argc, int argv[]) {
The old style definition works because C had a default type of int, so the type specifications for the function main and the parameter argc could be omitted.As for int argv[]? What that actually represents is an array of memory addresses that hold the command line arguments given. Obviously this becomes a problem if you're on a 64-bit system, where int and (void * ) are two different sizes. However, I checked this out on my 64-bit machine and it works just fine:
int main(int argc, unsigned long long argv[]) {
char *firstarg = (void *)(argv[1]);
printf("%s", firstarg);
}
which, given "./a.out pickles" will print "pickles" (argv[0] gives the memory address of the cstring "./a.out"). I'm guessing that, in the case of a compiler, the memory addresses of arguments are more relevant to have than the arguments themselves.