Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2003-06

sigaddset, sigfillset, sigaddset, sigdelset, sigismember... all missing?

7 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Stephen Hurd

I can't seem to find any correct way of manipulating SigSets in freepascal... although sigprocmask and sigpending are implemented, how have these been tested? How am I supposed to add something to a sigmask?

Reply by email

Michael Van Canneyt
to Stephen Hurd
Stephen Hurd wrote
I can't seem to find any correct way of manipulating SigSets in freepascal... although sigprocmask and sigpending are implemented, how have these been tested? How am I supposed to add something to a sigmask?

They have not been implemented but it should be easy to do it yourself, it's just setting some bits in an array.

in the 1.1 version, the functions have been implemented. Here is the implementation:

function fpsigaddset(var nset : tsigset;signo:cint): cint;
Begin
   if (signo<=0) or (signo > SIG_MAXSIG) Then
     Begin
       seterrno(ESysEINVAL);
       exit(-1);
     End;
   nset[(signo-1) shr ln2bitsinword]:=nset[(signo-1) shr ln2bitsinword] OR (1 shl ((signo-1) and ln2bitmask));
   fpsigaddset:=0;
End;
function fpsigdelset(var nset : tsigset;signo:cint): cint;
Begin
   if (signo<=0) or (signo > SIG_MAXSIG) Then
     Begin
       seterrno(ESysEINVAL);
       exit(-1);
     End;
   nset[(signo-1) shr ln2bitsinword]:=nset[(signo-1) shr ln2bitsinword] AND NOT (1 shl ((signo-1) and ln2bitmask));
   fpsigdelset:=0;
End;
function fpsigemptyset(var nset : tsigset):cint;
var i :longint;
Begin
  for i:=0 to wordsinsigset-1 DO nset[i]:=0;
  fpsigemptyset:=0;
End;
function fpsigfillset(var nset : tsigset):cint;
var i :longint;
Begin
  for i:=0 to wordsinsigset DO nset[i]:=NOT 0;
  fpsigfillset:=0;
End;
function fpsigismember(const nset : tsigset;signo:cint): cint;
Begin
   if (signo<=0) or (signo > SIG_MAXSIG) Then
     Begin
       seterrno(ESysEINVAL);
       exit(-1);
     End;
    if ((nset[(signo-1) shr ln2bitsinword]) and (1 shl ((signo-1) and ln2bitmask)))>0 Then
     fpsigismember:=1
    else
     fpsigismember:=0;
End;

Michael.

Reply by email

Stephen Hurd
to Michael Van Canneyt
Show quoted text 13 lines
On Mon, 2 Jun 2003, Stephen Hurd wrote: > I can't seem to find any correct way of manipulating SigSets in freepascal... > although sigprocmask and sigpending are implemented, how have these been > tested? How am I supposed to add something to a sigmask? They have not been implemented but it should be easy to do it yourself, it's just setting some bits in an array. in the 1.1 version, the functions have been implemented. Here is the implementation:

Excellent... I was just wondering if I was missing something. Thank you very much.

Reply by email

Marco van de Voort
to Stephen Hurd
Is sigpending broken on OpenBSD? It doesn't seem to be working here.

OpenBSD is pretty much a proof of concept port. I decided to not put too much time in it till OpenBSD/x86 got ELF, and updates its binutils a bit.

However if you have a specific problem, I will investigate it.

To make it easier, in the report

- Name your versions of as and ld.
- submit a working program that shows the bug.
- describe compiler options, and possible other conditions that trigger the bug.

Reply by email

Stephen Hurd
to Marco van de Voort
Show quoted text 13 lines
> Is sigpending broken on OpenBSD? It doesn't seem to be working here. OpenBSD is pretty much a proof of concept port. I decided to not put too much time in it till OpenBSD/x86 got ELF, and updates its binutils a bit. However if you have a specific problem, I will investigate it. To make it easier, in the report - Name your versions of as and ld. - submit a working program that shows the bug. - describe compiler options, and possible other conditions that trigger the bug.

I was just curious... I've dropped using sigpending/sigprocmask now have just switch to a global variable and a signal handler. Good enough until the sigset stuff is finalized... I've got a couple programs compiling/ running on FreeBSD, OpenBSD, NetBSD, and Linux and am currently banging my head against QNX. (I run my BBS on all five OSs)

The fun part looks like it's going to be getting a Linux unit (Should that perhaps be renamed NIX or something?), ncurses, oCrt, etc all working on the QNX system... the other four seemed to be no real problem. (I'm not even really sure what the Linux unit is built from)

Reply by email

Marco van de Voort
to Stephen Hurd
Show quoted text 11 lines
(Marco van de Voort) wrote: > - submit a working program that shows the bug. > - describe compiler options, and possible other conditions that trigger > the bug. I was just curious... I've dropped using sigpending/sigprocmask now have just switch to a global variable and a signal handler. Good enough until the sigset stuff is finalized... I've got a couple programs compiling/ running on FreeBSD, OpenBSD, NetBSD, and Linux and am currently banging my head against QNX. (I run my BBS on all five OSs)

The problem with OpenBSD seems to be that it is meant for making routers/firewalls using the base system. They seem less interested in applications.

Btw, you are the _first_ feedback on the OpenBSD port :-)

The fun part looks like it's going to be getting a Linux unit (Should that perhaps be renamed NIX or something?), ncurses, oCrt, etc all working on the QNX system... the other four seemed to be no real problem. (I'm not even really sure what the Linux unit is built from)

This is all because the first non-linux Unix port, FreeBSD, dates from somewhere between 1.0 and 1.0.2 (1.0 was may 2000 or so).

The early FreeBSD rtl was a mere patch on the linux rtl. When it started to stabilize, we already decided to not do any large new rearrangements in the 1.0.x branch.

In the 1.1 development branch, we renamed linux to "unix", but we are currently changing this even some more:

- The three BSDs have pretty much a "shared" RTL. Maybe the 4th BSD will be added (Darwin), but this depends on how big the overlap is, otherwise it gets its own copy of the BSD rtl.
- all real posix/unix functions move to new unit baseunix and
- get renamed to "fp<name under C>",
- are declared using unix typing (off_t, dev_t ino_t etc),
- overloaded variants of the base calls move too.
- In the future, a RTL recompile with a certain define should base all calls on libc (needed for Darwin)
- Some derivative functions (like shell()) will remain in unix in a cleaned up way. The exact division between unit Unix and Baseunix hasn't been decided yet.
- Processor specific functions go to a separate unit (the x86 port stuff ioperm and iopl)
- Real OS specific stuff, if any (like the "sysinfo" call) moves to the respective platform dependant unit. (linux, openbsd, netbsd etc) Maybe there will be a "bsd" unit too.

Some of these things (renaming, unix typing etc) should have done directly when FreeBSD was added, but that's in retrospect.

---
This means that 1.1.x will probably break all "linux" unit using programs, and it can only partially be resolved by renaming "uses" clauses and even functions (there is still the typing)

However there was no way to avoid this, since the number of platforms exploded, and even new architectures have been added. We now have (linux,netbsd,openbsd) on (i386,m68k,powerpc and in the future sparc), which is potentially already a 3x3 or 3x4 matrix in itself.

I assume that when the Sparc port becomes operational, Solaris will also get revived.

Ifdef'ing half of linux to 10-20 levels deep is simply not an option, so we decided to redesign it entirely before the next major version of FPC. (which will be 3-4 years after 1.0 anyway, so nobody will accuse us of rushing :-)

Reply by email