[Revised] Missing sigaction proto in <sys/signal.h>

[Revised] Missing sigaction proto in <sys/signal.h>

[Mumit Khan]

Please replace the previous patch (mailed to the list an hour or so ago) 
with the following one. The last one conflicts with the proto in 
winsup/winsup.h (parameter const'ness). Only found it when rebuilding
the whole bit.

*** signal.h.~1 Tue Mar 25 22:32:25 1997
--- signal.h    Tue Mar 25 23:46:39 1997
***************
*** 24,29 ****
--- 24,33 ----
  #define sigaddset(what,sig) (*(what) |= (1<<(sig)))
  #define sigemptyset(what)   (*(what) = 0)
  
+ /* From winsup/winsup.h */
+ int _EXFUN(sigaction, (int signum,
+              const struct sigaction *newaction,
+              struct sigaction *oldaction));
  int sigprocmask (int how, const sigset_t *a, sigset_t *b);
  #endif /* _STRICT_ANSI */


Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

POSIX signal fn & setitimer

[Chin Chee-Kai]

Eh, gonna ask a "sensitive" question innocently...

Point (1):
I've ploughed through the header files in search for some of the
more elaborate signal handling functions such as sigset(), sighold(),
sigpause(), .. etc, but couldn't find any of such.  Are these
somewhere in the libraries?  Or when will they become available
(any hints from Cygnus people please?)?

Point (2):
In <sys/signal.h>, I can see some of those conditional #if's for
different platforms.  In particular, I'm confused by line 107
(of <sys/signal.h>)
	#if defined(__svr4__)

See, I thought files in <sys/> directory should describe the
environment in which programs are compiled, and should be very
specific to the system.  So in this case, 
	(a) is gnu-win32 gcc assuming that the environment
	    may be compiled in SVR4?
	(b) is gnu-win32 gcc assuming Win95/NT are SVR4?  Or could be?
	    If there's this assumption, then when does gnu-win32
	    expect the macro to be defined?
	(c) I wanted my programs to recognise POSIX signals
	    (as I also run them on SGI).  So I now have to
	    rather dangerously put a "#define __svr4__"
	    before "#include <signal.h>" (which includes <sys/signal.h>
	    But this approach is really queer since I'm telling the
	    compiler midway that the environment has suddenly become
	    SVR4.  Has anyone else dealt with this in a better way?

Finally, I can't find the lovely  "setitimer()" function.
"nm lib*.a" in /usr/lib returns nothing and I can't run a timer
test.  Has someone already found a way around it?

Thanks.


Chin Chee-Kai (Last, First)
Internet Email-ID:	cheekai@gen.co.jp

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: POSIX signal fn & setitimer

[Jim Balter]

Chin Chee-Kai wrote:
> 
> Eh, gonna ask a "sensitive" question innocently...
> 
> Point (1):
> I've ploughed through the header files in search for some of the
> more elaborate signal handling functions such as sigset(), sighold(),
> sigpause(), .. etc, but couldn't find any of such.  Are these
> somewhere in the libraries?  Or when will they become available
> (any hints from Cygnus people please?)?

signal handling has a convoluted history in unix.  The routines
you mention are an older interface not available in gnu-win32.  All
previous signal functionality has been subsumed under the POSIX
sigaction and friends.  Time to visit your local technical reference
center (see below).

Note though, that while cygwin is aimed toward the POSIX functionality,
it is not by any means a complete or accurate implementation.  A number
of bugs have been reported to this list, and there are many others.
 
> Point (2):
> In <sys/signal.h>, I can see some of those conditional #if's for
> different platforms.  In particular, I'm confused by line 107
> (of <sys/signal.h>)
>         #if defined(__svr4__)
> 
> See, I thought files in <sys/> directory should describe the
> environment in which programs are compiled, and should be very
> specific to the system.  So in this case,

Header files are no different from other C code that has multiple
targets, selected via ifdefs.  The header files are very specific
to the environment, but they are made that way by defining the
appropriate symbols.  The gcc spec file for gnu-win32 defines
_WIN32, which selects the appropriate sections.  It does not define
__svr4__, so those sections are not included.

*Why* do you think the files should be "very specific to the system"?
Maintaining multiple copies of the header files goes against sound
principles of software engineering.  When I worked for a unix operating
system vendor, we did in fact "sanitize" the header files (and the
source distributions) so that ifdefed out code was actually physically
removed, but that was primarily due to licensing issues; it is rarely
done, and certainly not in "free" software where the point is to
share all the sources in encourage porting to new targets.  But we
still maintained a single ifdefed source.

You are asking a pretty basic question about software engineering.
Take off your users hat for a moment and put on a developer's hat.
The developer only wants to have a single source for the header files,
since the vast majority of their content is common among targets.
For those few lines, such as signal numbers, that differ among targets,
they are ifdefed to be included only on that target.


>         (a) is gnu-win32 gcc assuming that the environment
>             may be compiled in SVR4?

This is somewhat conceptually confused.  gcc doesn't assume anything,
people assume things.  The authors of those header files wrote them with
several different systems in mind.  gcc just does what it is told;
if it is told to include stuff within ifdef _WIN32, it will.  If it is
told to include stuff within ifdef __srv4__, it will, even if told to
do that on a gnu-win32 system where it won't work.

>         (b) is gnu-win32 gcc assuming Win95/NT are SVR4?  Or could be?

__svr4__ is not defined in the gcc specification file for gnu-win32.
gnu-win32 does not provide a SVR4 environment beyond what SVR4
shares with POSIX, and perhaps a few other common routines.


>             If there's this assumption, then when does gnu-win32
>             expect the macro to be defined?

There isn't and it doesn't.

>         (c) I wanted my programs to recognise POSIX signals
>             (as I also run them on SGI).  So I now have to
>             rather dangerously put a "#define __svr4__"
>             before "#include <signal.h>" (which includes <sys/signal.h>

That won't affect sys/signal.h since the ifdef(__svr4__) is ifdefed out
by the elif defined(_WIN32) that precedes it.  But it is dangerous and
wrong, so don't do it.

>             But this approach is really queer since I'm telling the
>             compiler midway that the environment has suddenly become
>             SVR4.

Not only that, but you haven't changed the underlying system to
which the header file is merely an interface, so if your __svr4__
did affect anything, it would only be to break it.  There *are*
environments where various "feature ifdefs" can be defined to
include different useful portions of header files that are normally
excluded in order to avoid name clashes, but gnu-win32 is not
such an environment.

>  Has anyone else dealt with this in a better way?

Dealt with what, exactly?  All the __svr4__ define in sys/signal.h
does is define the signal numbers to match an SVR4 kernel.
Since gnu-win32 doesn't contain an SVR4 kernel, you don't want that.

If what you want to deal with is sighold, sigpause, etc., you need
to read the documentation for sigaction and related POSIX routines
and implement your code using those.  If you can't find it at the Cygnus
site, there is such information available with GNU's glibc, with linux,
and at various other places around the web.  Here's something from
the first page of an altavista search (it gave me "about 1000" matches;
learn to search the web, it is your friend):

  http://earthcube.mit.edu:1526/sigaction (2)


> Finally, I can't find the lovely  "setitimer()" function.
> "nm lib*.a" in /usr/lib returns nothing and I can't run a timer
> test.  Has someone already found a way around it?

It's not implemented in gnu-win32.  You might try your hand at
writing one.

Or, if you are trying to do real work and are not just playing and are
not a starving student and have no principled objection to paying for
trade secret software (there may be other reasons, but I can't think
of them offhand), consider one of the alternatives to gnu-win32, such as
OpenNT or Nutcracker.  OpenNT is blessed/commissioned by Microsoft,
but I haven't actually installed it.  Beta versions are available
at www.softway.com.  Their page mentions SVID shared memory and
semaphores, so perhaps they support SVID signal handling too
(SVID is a series of operating system standards; SVR4 is an
implementation of one in that series; SVID was one of the sources from
which POSIX was drawn).


--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".