From: jqb AT netcom DOT com (Jim Balter) Subject: Re: POSIX signal fn & setitimer 27 Mar 1997 16:52:04 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <333A6C87.1D79.cygnus.gnu-win32@netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: Chin Chee-Kai Original-CC: gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 , I can see some of those conditional #if's for > different platforms. In particular, I'm confused by line 107 > (of ) > #if defined(__svr4__) > > See, I thought files in 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 " (which includes 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). -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".