stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: replacement
Date Sat, 15 Jul 2006 00:57:41 GMT
Andrew Black wrote:
> I have been working on a replacement for the 
> script.

I get the following result when I run it on Solaris 9 (note that
I don't have '.' in my PATH -- I believe the program assume that
and doesn't work otherwise; I think I fixed it in my copy but I
still get the same result):

$ ./runall ./runall

runall             SIGSEGV

A few high-level comments:

1. Please make sure the code is const-correct. It's much easier
to follow that way. It's good to also declare const any and all
local variables (other than function arguments) that aren't
modified by the function.

2. As far as formatting goes, please try to follow the informal
(and still unwritten) stdcxx guidelines, in particular

    -- opening brace is in column 1 for file-scope functions and
       structs, but it follows the declared name in local scope
    -- closing brace is always alone on a line
    -- separate opening brace from whatever precedes it by one
    -- use a single space between operators and operands
    -- separate function names from the opening parenthesis by
       a single space (ditto for for, if, switch, and while
    -- each statement should be on a line of its own, including
       the body of the if statement:
           if (condition)
               return -1;   // okay
           if (condition) return -1;   // NOT okay

3. Other suggestions:
    -- prefer functions to macros (e.g., define a single helper
       function instead of the ALLOC_TEST and FILE_TEST macros)
    -- avoid complicated expressions or modifying variables when
       passing arguments to function calls (e.g., avoid things
           foo (a = b, bar ())
       and instead write
           a = b;
           c = bar ();
           foo (a, c);
       to avoid being bitten by function-like macros, and for
       better readability)
    -- always check the return value of malloc() and handle null
       pointers (by issuing an error message and exiting with a
       non-zero status)
    -- define a single function to report errors and (optionally)
       exit the program (with the appropriate exit status) instead
       of calling exit() from multiple places
    -- in diagnostic messages use text understandable to users no
       familiar with the implementation of the program (e.g., prefer
       "failed to open file: %s" to "open(%s) failed")
    -- use the name of the program (i.e., argv[0]) in diagnostic
       messages (to make it possible to identify the source of
       the diagnostic in pipelines such as foo | bar)
    -- prefer the C standard library calls to POSIX calls (i.e.,
       prefer fopen() to open())

> This executable is written in c, and it should be possible to compile it 
> using roughly the same set of flags as the library.  Note that there 
> will be a few warnings, but I believe them to be harmless.  (I have been 
> using the following as my compile line)
>  > gcc -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
> -Wcast-align --pedantic runall.c -o runall

These are good, although -Winline won't do anything unless you
also enable optimization.


View raw message