Loading ...
Sorry, an error occurred while loading the content.

Learning C

Expand Messages
  • Aaron Kulkis
    A recently joined member said he s interested in learning to program in C on Linux. Here are some resources: If you have any questions, ask immediately. I
    Message 1 of 1 , Mar 2, 2009
      A recently joined member said he's interested in learning
      to program in C on Linux.

      Here are some resources:

      If you have any questions, ask immediately.
      I learned C on 4.3 BSD systems, programming both natively
      on VAX-11 and also for a Motorola 6809-based development
      system made by HP. Linux is almost identical, the only
      significant difference are these:

      1: The C Compiler.
      On Unix, it is cc (located at /usr/bin/cc)
      On Linux, it is gcc (located at /usr/bin/gcc)

      cc hello.c /(produces an executable
      gcc hello.c \file called a.out)

      cc hello.c -o hello /(same as above, but the
      gcc hello.c -o hello \exectable is called hello)

      2: Lint.
      Unix systems have a program called lint, which checks
      for both compiler errors and inconsistancies which
      are legal but could produce bugs. It would be called
      like so

      Examples of legal but "dangerous" coding are such as
      calling with two arguments a function that takes 3, or
      calling a function with a float as an argument, and
      the function expects an int (been there -- it leads to
      extremely confusing output. Had I just run lint, it
      would have been flagged as a warning, and I wouldn't
      have wasted over an HOUR on it)).

      On linux, the equivalent of lint is:
      gcc -pedantic [* see the man page excerpt below]

      You can create a shell script that works just like lint:

      Typically, I make a directory ~/bin and put it in my path
      [Note that $ is the shell prompt, and NOT part of the command]

      $ mkdir ~/bin

      and then put the following line at the END of your .bashrc
      and other shell initialization files:

      This can be accomplished by cutting and pasting this onto
      the command line (MAKE SURE you use >> (append)):
      For bash:
      $ echo "PATH=$PATH:~/bin" >> ~/.bashrc
      For Bourne shell (sh) and Korn Shell (ksh):
      $ echo "PATH=$PATH:~/bin" >> ~/.profile
      For C-shell (csh) and tcsh:
      $ echo

      Then create a shell script called lint:

      $ cd ~/bin
      $ cat > lint
      # lint: c program checker
      # gcc replacement for lint
      # Date Author Remarks
      # ---------- --------------- ------------------------------
      # 2002-04-22 Aaron R. Kulkis First version
      # pass all arguments
      $GCC $LINTFLAGS $*

      [ Now type a ctrl-D as the 1st character on the line]
      Now, to finish up, you need to make this file executable:

      $ chmod 755 lint

      Now you have a replacement for lint which I feel is
      superior to the original -- the original lint was a
      completely different program from the C compiler, and
      were therefore maintained seperately, even if by the
      same people in parallel. In contrast, no separate
      maintenance effort is needed for my version. Whenever
      gcc is updated, then of course gcc -pedantic is, too.

      From the gcc manual page:
      Issue all the warnings demanded by strict ISO C and
      ISO C++; reject all programs that use forbidden
      extensions, and some other programs that do not
      follow ISO C and ISO C++. For ISO C, follows the
      version of the ISO C standard specified by any -std
      option used.

      Valid ISO C and ISO C++ programs should compile
      properly with or without this option (though a rare
      few will require -ansi or a -std option specifying
      the required version of ISO C). However, without
      this option, certain GNU extensions and traditional
      C and C++ features are supported as well. With
      this option, they are rejected.

      -pedantic does not cause warning messages for use
      of the alternate keywords whose names begin and
      end with __. Pedantic warnings are also disabled
      in the expression that follows "__extension__".
      However, only system header files should use these
      escape routes; application programs should avoid

      Some users try to use -pedantic to check programs
      for strict ISO C conformance. They soon find that
      it does not do quite what they want: it finds some
      non-ISO practices, but not all---only those for
      which ISO C requires a diagnostic, and some others
      for which diagnostics have been added.

      A feature to report any failure to conform to ISO C
      might be useful in some instances, but would require
      considerable additional work and would be quite
      different from -pedantic. We don't have plans to
      support such a feature in the near future.

      Where the standard specified with -std represents
      a GNU extended dialect of C, such as gnu89 or gnu99,
      there is a corresponding base standard, the version
      of ISO C on which the GNU extended dialect is based.
      Warnings from -pedantic are given where they are
      required by the base standard. (It would not make
      sense for such warnings to be given only for
      features not in the specified GNU C dialect, since
      by definition the GNU dialects of C include all
      features the compiler supports with the given option,
      and there would be nothing to warn about.)

      Like -pedantic, except that errors are produced
      rather than warnings.
    Your message has been successfully submitted and would be delivered to recipients shortly.