gore@nucsrl.UUCP (Jacob Gore) (11/19/86)
Well, I've applied James Lee Johnson's patch to CC (1.1, for 4.3BSD)
-- thanks! -- and that got me through 'make munch'.
Now I have a problem with making cfront, and also a question about some
code in src/main.c.
Here's the compilation error I get:
===================================
cd src; /bin/make CC=CC CCFLAGS="-O -DBSD"
CC -c main.c
CC main.c:
"/usr/include/CC/signal.h", line 10: error: signal() type mismatch: int (*() )() and int (*(int , PF ) )()
1 error
===================================
Since /usr/include/CC/signal.h includes /usr/include/sys/signal.h, the
conflict seems to arise in /usr/include/CC/signal.h itself (as opposed to
src/main.c). Line 10 there redeclares the function 'signal'.
Any suggestions?
The question I have is about a related portion of src/main.c:
===================================
typedef void (*ST)(...); // trick to circumvent problems with old
ST sick = ST(&signal); // (or C) versions <signal.h>
sick(SIGILL,core_dump);
...
===================================
Now, if I understand this correctly, 'sick' is a pointer to the 'signal'
function. In that case, shouldn't the call be "(*sick)(SIGILL,core_dump);"?
Jacob Gore
Northwestern University, Computer Science Research Lab
{ihnp4,chinet}!nucsrl!gorewescott@sauron.UUCP (Mike Wescott) (11/24/86)
In article <3960003@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: > Now I have a problem with making cfront, and also a question about some > code in src/main.c. > > The question I have is about a related portion of src/main.c: > =================================== > typedef void (*ST)(...); // trick to circumvent problems with old > ST sick = ST(&signal); // (or C) versions <signal.h> > sick(SIGILL,core_dump); > ... > =================================== > Now, if I understand this correctly, 'sick' is a pointer to the 'signal' > function. In that case, shouldn't the call be "(*sick)(SIGILL,core_dump);"? Not necessarily. Both expressions are equivalent in C++ as well as in C. For C++, see "The C++ Programming Language" by B. Stroustrup, from the Reference Manual section 7.1: " A function call is a primary expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the actual arguments to the function. The primary expression must be of type ``function returning ...'' or ``pointer to function returning'', and the result of the function call is of type ``...''. I can't find a similar blessing in K&R, but my reading of 3.3.2.2 of the July 9 draft of the ANSI-C standard leads me to believe that it is legit in C as well. Besides, the compilers take it. There is, however a bug in the way the statement is converted to C. The original code (version 1.1) would, on most machines work and produce reasonable C code. A recent fix to print.c posted by Dr. Stroustrup fixed one problem but made the situation worse for compiling this section of main.c. I am posting another article with this fix and another. -- -Mike Wescott ncrcae!wescott
news@cit-vax.Caltech.Edu (Usenet netnews) (11/25/86)
Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <765@sauron.UUCP> wescott@sauron.UUCP (Mike Wescott) writes: >In article <3960003@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: >> ... >> sick(SIGILL,core_dump); >> ... >> Now, if I understand this correctly, 'sick' is a pointer to the 'signal' >> function. In that case, shouldn't the call be "(*sick)(SIGILL,core_dump);"? > >Not necessarily. Both expressions are equivalent in C++ as well as in C. >... >I can't find a similar blessing in K&R, but my reading of 3.3.2.2 of the July 9 >draft of the ANSI-C standard leads me to believe that it is legit in C as >well. Besides, the compilers take it. ... ANSI C does not exist yet, and there are definitely compilers that do NOT take the first usage; for example the Amdahl UTS C compiler. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/