[m-rev.] for review: implement C version of mmc

[Peter Moulder]

Can we use exec rather than system?

system introduces extra problems with escaping (which the current code
mainly doesn't address); ignores SIGINT and SIGQUIT, which is annoying
for long compiles (particularly `mmc --make' :) ); uses more resources
(e.g. creating an extra process); hides signal termination information
from the caller; and perhaps other things.

Standards conformance: Only system is ANSI C, but this is of limited use
given that neither the parsing of the string nor even the meaning of the
return code (e.g.  whether errors result in non-zero) is specified by
this standard.

In practice: I don't have any Windows machines for testing, but I get
the impression from the web that execv exists on Windows.  I haven't
found the parsing rules for system on Windows (and hence what quoting
should be done).  There's some evidence (viz. python documentation) that
system returns 0 unconditionally on some windows systems (Win95, Win98),
which would obviously be a problem for make-like tools.

(MacOS: My understanding is that each MacOS system can either be treated
 like POSIX (e.g. MacOS X) or is so non-POSIX that mmc isn't practical
 (e.g. not allowing option-passing through argv).)


Currently the code returns the raw return value of system, which
presents a couple of problems:

  - On ~all Un*x systems, the status indicated by wait() and system()
    indicates both the exit status and signal value of the called
    program.  Thus, given that int is a fixed size, and signal
    information requires a positive number of bits, some truncation must
    occur.  On my system (and I'd guess ~all Un*x systems), if the
    invoked compiler exits due to a signal, then system returns
    something with 0 in the low 8 bits, and only the low 8 bits of the
    program's exit status are reported by wait, so the caller of mmc
    would believe that mmc had succeeded!
  
  - More generally, it is expected that programs return 0 for success
    and 1 (or perhaps 2) on failure; the ANSI standard goes further and
    recommends only returning either EXIT_SUCCESS or EXIT_FAILURE,
    without relying on the values of those macros.


Readability:

> +#if @MMC_STANDALONE@
...
> +#else /* @MMC_STANDALONE@ */
...
> +#endif /* @MMC_STANDALONE@ */

I can't find any Mercury coding standards for C code (other than a
couple of notes in compiler/notes/coding_standards.html), but I suggest
prepending `not ' into those else/endif comments, as per Gnu coding
standards.  This makes it clearer to the reader what the condition of
the #else code is.  (Use of english `not' rather than `!' makes it
fairly clear that the #if condition is `@...' rather than `! @...'.)

pjrm.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------