🚀 go-pugleaf

> 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)

> 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

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