Hacker News Reader

You know I can think of a handful of examples where main is not true. C to my understanding does not define that the implementation does and think this is kind of exactly what the other is saying that this implied assumptions lead to issues in C development. This albeit is an extremely superficial assumption that isn't in 99% of cases going to matter except in of course security and embedded systems

I think the biggest issue with C is that it's taught as the programs you are building is foundation of everything while brushing under the rug that in also all course work you are not build C on bare metal you almost always are building on on OS which runs an implemented hardware which are extremely important. But by teaching your building on this all powerful language makes overconfident programmers. I've known so many developers who jump the gun and think they are write what will happen on the computer without understanding how high in the clouds they normally are.

> The order of the function definitions in the source code makes no difference to the program’s meaning.

Not exactly true. Consider:

    #include <stdio.h>
    int foo(double d) { return (int)d; }
    int main() { printf("%d\n", foo(3)); return 0; }
    /*int foo(double d) { return (int)d; }*/

This prints different results depending on whether `foo` is defined before `main` or after `main`. This is caused by implicit function declaration.

gcc will warn about this if the -std=c11 switch is thrown, but by default it will compile without error or warning.

Amusingly, the ImportC compiler I wrote will produce the same result regardless of the order, because it allows forward references.

Here gcc (9.4.0) throws a warning if the first declaration is commented and the second one uncommented, but it prints "0". Care to explain why?

Because foo() gets implicitly declared as accepting int arguments, when it actually accepts a double. The double bits interpreted as an int are 0.

On x64, foo(double) expects its argument in xmm0, but foo(int) expects it in rdi. So the 3 passed in rdi is ignored and it operates on whatever happened to be in xmm0.

Yes, you're right. Thanks for the correction. I was thinking of the Windows C ABI.

Strictly speaking he's correct as "definition" is distinct from "declaration", but yeah.

I wrote definitions in the example, and the order dependence is clear.

But if you declare the foo function before main, it works correctly regardless of where it's defined. The definition just has the effect of also declaring it, which is what makes the difference.

(Of course you know all this much better than I do, but someone younger reading this thread might be mystified.)

That wasn't the statement in the book, though. The thing is, this is a serious misfeature which isn't present in other languages, and can cause bizarre problems to the poor newbie user.

This order dependency is why C source code tends to be written bottom-up, rather than the more natural top-down.

Agreed on all four points.

gcc 12.2 on Arch warns about it with no switches - sure RMS did not put a disclaimer on his claim but one can reasonably assume he meant if you write correct C the order will not matter. (Btw I have a feeling every statement about C would need to carry that disclaimer lol - main will be called if you did not LD_PRELOAD a .so that caused premature exit in init function etc.)

    gcc /tmp/testf.c 
    /tmp/testf.c: In function ‘main’:
    /tmp/testf.c:4:18: warning: implicit declaration of function ‘foo’ [-Wimplicit-function-declaration]
    4 |   printf("%d\n", foo(3));
      |                  ^~~

Can anyone link me to the pdf directly. I don't find it on the link above. I am stupid.

There is no PDF.

There is no pdf. Following the chain, you get to a git you can download. But this guy has a tar of it as a single html page.

https://forums.linuxmint.com/viewtopic.php?t=381284

There's no direct PDF, you have to build it yourself w/ TeX by cloning the repo:

  git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
  cd c-intro-and-ref/
  make c.pdf

Someone has uploaded a PDF to github, here:

https://github.com/VernonGrant/gnu-c-language-manual

I am stupid, too. I generally do not use git(1). I wrote a short script to download the manual as a single 639K text file. I do not use a GUI or mouse so this makes it easier for me to work with code snippets. I also reformat the text to match personal preferences. Here is an example script using popular curl program to make the HTTP requests.

    # requirements: curl, links, perl, texinfo (Linux), texi2html (BSD)

    #!/bin/sh
    set -v;
    x0=c-intro-and-ref.git;
    x1=https://git.savannah.nongnu.org/cgit/;
    test -d $x0||mkdir $x0;cd $x0||exit;
    for x2 in Makefile c.texi cpp.texi fdl.texi fp.texi texinfo.tex;do
    echo url=$x1$x0/plain/$x2;
    echo output=$x2;
    echo user-agent=\"\";
    done|curl -K/dev/stdin -s;
    case $(uname) in :)
    ;;*BSD) texi2html --no-headers --no-split --html c.texi
    ;;Linux) makeinfo --no-headers --no-split --html c.texi
    esac;
    # personal preference for ~15-inch screen: 4 space indent, 60-70 max chars per line
    links -width 70 -dump .html \
    |sed '/^ *Link:/d;/^ *\*/s/\*//;s/^/    /;/Jump to: /{N;N;d;}' > c.txt;
    exec less c.txt;

    printf 'the form\n' \
    | tr a-z A-Z

golfs to

    printf 'the form\n' |
    tr a-z A-Z

but that only saves like one or two keystrokes but is probably good to know for shell trivia questions or when implementing something that supposedly can handle shell continuation lines

djb used this style when shell scripting and I believe that is where I picked it up.^1 I have not seen (m)any HN commenters publishing their work for public scrutiny who are more skilled in programming, including C, than djb. Other programmers, good ones, but not a large number, copied his C style.

1. An extreme example

https://raw.githubusercontent.com/drudru/qhasm/master/qhasm-...

Would be nicer if RMS can add TOC on the PDF, to make navigation _much_ easier.

thank you for this!