Conference hydra::axp-developer

John,
	I've looked into th eproblem you raised, and the uswitch()
function works OK for me...

$> cat usw.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/uswitch.h>

main()
{
    size_t  retval;
    int     uswitch_val;

    uswitch_val = uswitch(USC_GET,0);
    printf ("uswitch_val: %x\n", uswitch_val);
    uswitch(USC_SET, uswitch_val | USW_NULLP);
    uswitch_val = uswitch(USC_GET,0);
    printf ("uswitch_val: %x\n", uswitch_val);
    retval = strlen(NULL);
    printf ("retval: %x\n", retval);
}

$> cc -o usw usw.c
$> usw
uswitch_val: 0
uswitch_val: 100
retval: 0
$>

There is an error in the example, uswitch strictly returns a long, not
an int, but this shouldn't prevent compilation or operation, since only
the first nine bits are currently defined.

Regarding the problem you raised about SIG_IGN, we supply signal() for
compatibility with older versions, we recommend sigaction() as the
preferred method for signal handling. Nevertheless, SIG_IGN should
still work.  Are you by any chance linking with libsys5 or libbsd since
these do modify the action   of SIG_IGN? See the signal () man page for
details. Extract enclosed below..  
 
 [Digital]  The effect of calling the signal function behavior differs
  depending on whether the calling program is linked with either of the spe-
  cial libraries, libbsd or libsys5, which supply BSD or System V signaling
  characteristics respectively. If neither library is used, the behavior is
  the same as that of the sigaction function with all the flags set to 0
  (zero).  If the libsys5 library is used (through compilation with the -
  lsys5 switch), then the specified signal is not blocked from delivery when
  the handler is entered, and the disposition of the signal reverts to
  SIG_DFL when the signal is delivered.  If the libbsd library or the
  bsd_signal() function is used, the behavior is the same as that of the
  sigaction() function with the SA_RESTART flag set.

If you cannot resolve these problems, then please send me short code
examples and the build commands, so that I can investigate further.

regards,

	Ian Chamberlin.

Hi Ian,

Sorry, I didn't give you much information. The code I'm compiling is C++ not 
C. 
The uswitch() example doesn't compile with the C++ compiler but it does with 
the C compiler. 

In calls to string functions like strlen, where I had something like

	number = strlen(mystring);

I've changed it to

	number = ( s ? strlen(mystring) : 0 )

which I think is ok as a workaround, zero is correct isn't it?



As regards the SIG_IGN, again it's C++ code and I'm not linking in libbsd or 
libsys5. I've used sigaction instead which works fine so this is not a serious 
problem. But, here's a small example program I have which shows what I'm on 
about, basically I end up with defunct processes (zombie processes). There are 
two files, nothing.cc and zombie.cc. zombie calls a function in nothing which 
is hard coded as /var/clearcase/nothing so you can change that path.

$ cat nothing.cc
// nothing.cc
// process to do nothing but sleep for argv 1

 #include <iostream.h>
 #include <unistd.h>
 #include <stdlib.h>

int main(int argc, char* argv[])
{
    
    long secs = 3;
    
    if ( argc > 1 )
        secs = atol(argv[1]);

    sleep(secs);
    cout << argv[0] << " process id " << getpid() << " about to exit" << endl;
    
    return 0;
    
}

$ cxx -o nothing nothing.cc
$ cat zombie.cc
// zombie.cc
// mainline to create zombies on osf1
//

 #include <iostream.h>
extern "C"
{
 #include <signal.h>
 #include <sys/types.h>
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/wait.h>
}

int exit_flag=0;

void int_handler(int a)
{
    cout << "int_handler called for pid "<< getpid() << endl;
    exit_flag= 1;
}

int main()
{
    int count = 0;
    int pid=0;
   
    signal (SIGCHLD, SIG_IGN);

    for (;count<5;count++)
    {        pid = fork();
        switch (pid) {
          case -1:
            cout << "fork failed" << endl;
            break;

          case 0:
            cout << "Child " << count <<" is alive!" << endl;
            sleep(3);
            execl("/var/clearcase/nothing","no-thing","10",0);
            break;

          default:
            cout << "Process with PID=" << pid << " created" << endl;
            break;
        }
    }

    // loop until interupted...
    while(! exit_flag)
    {
    sleep(1);
    }

    return 0;
}

$ ./zombie

If you do a ps -ef you'll see defunct processes created when the children 
exit. I thought signal(SIGCHLD, SIG_IGN) should prevent zombie processes from 
being created.


Anyway, neither of these problems are life threatening! If you could just let 
me know if it's correct to return zero for all string functions on NULL 
strings or not, that'd be great.

Thanks Ian,


John.

Hi John,
	Yes, the info I received from the ASAP  people didn't mention C++ at
all,so I defaulted to C.

	You are correct that the example doesn't work under C++ - it looks as if
there is no prototype declaratiohn for uswitch() - but the C compiler doesnt
seem to mind.

	There is no issue with the workround you suggest. strlen returns a
size_t, which is an unsigned long, so zero is an acceptable return value, and
you will be getting the system V type behaviour you would get wit uswitch().
Just bear in mind though that there is now no way of differentiating between a
genuine zero length string, and a string which does not exist!  Thats why we
take the purist view on dereferencing null pointers.

	I found a way to make uswitch() work - you need to add an external
declaration like:

extern "C"
long uswitch(long, long);


Using sigaction() is the recommended way to handle signals.

Thanks for bringing this to our attention - I'll look into the problems a bit
further


Ian Chamberlin,

Digital Equipment Co, Software Partner Engineering.

John,
	Just to close the loop on this, I have reported the missing prototype for
uswitch() as a bug. I would expect it to be fixed in a future version of
Digital Unix.

	The C compiler copes by assuming an implicit function declaration. The
work round for C++ is for te user to declare it externally:

extern "C"
long uswitch(long,long);

Thanks for bringing this to our attention.

I guess its now time to close the call.

regards,
		Ian.
Ian Chamberlin,

Digital Equipment Co, Software Partner Engineering.