map1@ukc.UUCP (01/22/86)
I would be very grateful and happy if the 'net' would clarify a few
points for me. This is my first posting, please forgive any blunders :-)
I am using Fortran under a 4.1BSD Unix. My intention is to to able to
catch interrupts from within an F77 program, and to supply my own handler.
In intro(3) it says "these functions together with those from section 2
are automatically loaded by cc and f77". I took this to be reason enough
that I could access signal(2) from a Fortran 77 program. Someone pointed
out that "Ah yes! Loaded but not accessible" Huh? Can a clear explanation
be given.
A small test program (after several lager ones failed) was quickly written:
external junk,signal
call signal(SIGFPE,junk)
a=1.0
do 10 i=1,150
a=a/2.0
if (i.gt.120)print*,a
10 continue
end
subroutine junk(s,subs)
integer s,subs
print*,"s= ",s,"subs= ",subs
end
On execution it failed with the messages:
floating underflow
Illegal instruction(core dumped)
I then changed SIGFPE to 8 as defined in <signal.h>
I now get:
Segmentation fault (core dumped)
Is this getting me any closer? I'm quite lost. For mild flames and/or
discussion I offer the following.
(1) Am I correct in assumming I can access signal in this way?
If not,....why?
(2) If one can access signal(2) what am I doing wrong? I'm lost as to
whether I'm entering _signal (found in libc.a) or _signal_ (found
in libF77.a) when setting everything up and on subsequent calls.
(3) What are the inner workings involved here, or what should happen
if things work?
(4) If the program is a farce could someone supply a small program
that is known to work. Hopefully I'll understand things more clearly
if I see it working.
(5) Yes, I have been told many times "Ha! Fortran, write it in C" O.K
but no one has told be that it is definitely impossible from F77.
I have the bit between my teeth and I'm trying hard, I want a
definitive yes it's possible or no it is not.
Many thanks for your help
Mark Pralatguy@sun.uucp (Guy Harris) (01/25/86)
> In intro(3) it says "these functions together with those from section 2 > are automatically loaded by cc and f77". I took this to be reason enough > that I could access signal(2) from a Fortran 77 program. Someone pointed > out that "Ah yes! Loaded but not accessible" Huh? Can a clear explanation > be given. You can't call a section 2 or 3 C library routine from FORTRAN. A FORTRAN call to "foo" would be a call to a C routine called "foo_", and there's no way to generate a call to a C routine called "foo". As such, you can't get at "signal(2)" from a FORTRAN program. > A small test program (after several lager ones failed) was quickly written: > > external junk,signal > call signal(SIGFPE,junk) ... First, put away the lager - never program when drunk. :-) The problem with this is twofold: 1) SIGFPE is not declared, and in the grand (yecch) tradition of FORTRAN, this means it creates a REAL variable (assuming no "implicit" statement) - uninitialized, of course - and passes its address as the first argument either to a FORTRAN routine "signal" or a C routine "signal_". 2) According to the 4.2BSD manual, the FORTRAN routine "signal" (actually implemented as a C routine "signal_" takes three arguments, not two. 4.1BSD may be the same; I don't know. Look in your manual for a section on FORTRAN library routines; "signal" will probably be in something called "signal(3F)". This manual page will give more details on how to use "signal" from FORTRAN. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy%gorodish@sun.arpa (yes, really)
woods@hao.UUCP (Greg Woods) (01/27/86)
> I am using Fortran under a 4.1BSD Unix. We use 4.2 here. That may or may not make a difference. > In intro(3) it says "these functions together with those from section 2 > are automatically loaded by cc and f77". The term "automatically loaded" means that the library(s) containing them are searched by default and do not need to be specified when your program is linked. They will not actually be loaded unless you reference them. In addition, f77 also loads the functions from section 3F of the manual. > external junk,signal > call signal(SIGFPE,junk) > (1) Am I correct in assumming I can access signal in this way? > If not,....why? > > (2) If one can access signal(2) what am I doing wrong? I'm lost as to > whether I'm entering _signal (found in libc.a) or _signal_ (found > in libF77.a) when setting everything up and on subsequent calls. f77 ALWAYS appends an underscore to routine names. Therefore, the above call must reference signal_ from libF77.a. I don't know about 4.1, but in 4.2 the arguments to signal(3F) are different from those to signal(3C). Specifically, a third argument is required. If this is also the case for 4.1 (perhaps someone still using 4.1 could enlighten us?) then that might explain why you get a segmentation fault. Missing arguments can do that! :-) I would suggest that you get out your manual and look under signal(3F). This is the only version of "signal" that you will be able to access from FORTRAN. It has a return value which you should check to make sure your call was correct. It is an integer function. > (3) What are the inner workings involved here, or what should happen > if things work? If it does work, and the designated signal is received, your handler will be invoked. Upon return from the handler, your program will continue execution from the point where the signal occurred. The default action of a signal is restored when a handler is invoked, so if you still want to catch the signal on subsequent occurences, you will need to have another call to signal inside your handler. The handler, unfortunately, may NOT have any arguments. If you need values passed to it you will have to do it through a common block. One problem with catching interrupts using signal calls becomes apparent here. Since the default action is restored when the handler is invoked (in this case, with interrupt, program termination) if the user hits repeated interrupt signals from the keyboard, the timing may work out such that the program is terminated anyway (if the second interrupt is received before your handler can call signal again). In 4.2 this has been fixed with the ability to "mask" signals (i.e. delay receiving a signal) but that isn't much help to you right now. Well, this is a very quick and very dirty introduction to signals from the user point of view. If you REALLY want to know how they work, it will be necessary to take a course in the internals of the operating system. --Greg -- {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA
torre@ur-helheim.UUCP (Fernando Torre) (01/31/86)
In article <611@eagle.ukc.UUCP> map1@ukc.UUCP (M.A.Pralat) writes: > >(4) If the program is a farce could someone supply a small program > that is known to work. Hopefully I'll understand things more clearly > if I see it working. From Unix 4.1BSD signal(3F) manual page, and tested in 4.2BSD : c c signal function arguments: c c 2 - signal number ( see signal(2) manual page ) c handler - user defined subroutine name c -1 - neg. number to indicate that user defined handling c routine is to be used c external handler iret = signal(2,handler,-1) 1 print*,' hi there ' go to 1 2 stop end subroutine handler(intsignal) print*,' Interrupt received. STOP' stop end -- Fernando Torre ARPA : ur-helheim!torre@rochester.arpa UUCP : {allegra,cmcl2,decvax,seismo}!rochester!ur-helheim!torre