How robust are Solaris 2.4's BSD/SunOS compatibility libraries?

How robust are Solaris 2.4's BSD/SunOS compatibility libraries?

Post by Ashok P. Nadkar » Sun, 14 May 1995 04:00:00



I need to port some SunOS based network applications to Solaris 2.4+.
I have two choices - use the BSD compatibility libs and compiler
options or make the necessary changes to port the sources to
SVR4/Solaris 2.4.

The question I have is - how robust are the BSD compatiility libraries
in Solaris ? Particularly in the area of network API's, signal
handling, process control etc.. The application is single threaded,
but some system libraries it links with may not be (nsl?).

Please reply to this article since my email is currently unreliable.

Thanks in advance for any answers.

/Ashok

 
 
 

How robust are Solaris 2.4's BSD/SunOS compatibility libraries?

Post by Casper H.S. D » Mon, 15 May 1995 04:00:00



>While I too recommend to always use sigaction(2), I would not call signal(3)
>to be avoided - it is part of ANSI/ISO C definitions and thus has to be
>available in XPG4 compatible environments. It will likely be implemented
>as a function around sigaction(2). If you are sure to reestablish signal
>handlers if necessary, they should be portable with signal, too.

While signal(3) is supported by ANSI C and XPG4, it's semantics aren't
fixed.  That's the main reason for avoiding them .  And there's a big
difference between reestablising a signal handler and not
blocking the signal (unsafe) and blocking it automagicaly thru sigaction
(safe).

In portable code, signal(3) should be avoided.

Casper
--
Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University


 
 
 

How robust are Solaris 2.4's BSD/SunOS compatibility libraries?

Post by Casper H.S. D » Mon, 15 May 1995 04:00:00



Quote:>The question I have is - how robust are the BSD compatiility libraries
>in Solaris ? Particularly in the area of network API's, signal
>handling, process control etc.. The application is single threaded,
>but some system libraries it links with may not be (nsl?).

The BSD networking API (sockets)  is supported in the native environment
and works quite well: the main exception being that it's more picky about
properly initializing socket structures and certain function parameters.

The BSD signal handling stuff is only supported in UCB libs.
I'd recommend strongly to avoid those libraries and do a straight port
instead.  By switcing from BSD signals to POSIX signals you'll avoid
many of the pitfalls that go with libucb and you'll save yourself future
porting headaches.  Make sure you avoid the following system calls:
        signal, sigset, sigrelse, sighold, sigignore
and go with sigaction and sigprocmask instead.

sigrelse/sighold are not suitable for blockign a single signal, how
attractive, because simple, it may seem to use:

        sighold(ASIG);
        /* critical section */
        sigrelse(ASIG);

it breaks as soon as you do:

        sighold(ASIG);
        /* critical section calls directly or indirectly a function foo()
           that also uses sighold/sigrelse, for ASIG.
           signal no longer held after calling that function
         */
         foo();
         /* ASIG no longer held after call to foo */
        sigrelse(ASIG);

use:

        sigset_t set, oset;
        sigemptyset(&set);
        sigaddset(&set, ASIG);

        sigprocmask(SIG_BLOCK,&set, &oset);

        /* critical section */

        sigprocmask(SIG_SETMASK,&oset, 0);

Casper
--
Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University

 
 
 

How robust are Solaris 2.4's BSD/SunOS compatibility libraries?

Post by Andre Be » Mon, 15 May 1995 04:00:00



|> [...]
|> instead.  By switcing from BSD signals to POSIX signals you'll avoid
|> many of the pitfalls that go with libucb and you'll save yourself future
|> porting headaches.  Make sure you avoid the following system calls:
|>   signal, sigset, sigrelse, sighold, sigignore
|> and go with sigaction and sigprocmask instead.

While I too recommend to always use sigaction(2), I would not call signal(3)
to be avoided - it is part of ANSI/ISO C definitions and thus has to be
available in XPG4 compatible environments. It will likely be implemented
as a function around sigaction(2). If you are sure to reestablish signal
handlers if necessary, they should be portable with signal, too.

--
+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |

+-o-+--------------------------------------------------------+-o-+

 
 
 

1. ``Robust'' SUN Software (showrev, Solaris 2.4)


Here's what I got when I tried it. Looks pretty logical to me.

 showrev: list_patches: Library function get_env_var(foo, SUNW_PATCHID)(No such

This was under Solaris 2.3 with various patches (kernel 101318-31).

What was it supposed to do that was so nasty? Is it 2.4-specific?
--
Ruth Milner                            NRAO                  Socorro NM

2. Receiving output of Shell script into C program?

3. SunOS/BSD Compatibility Library Functions

4. xntp on 2.2 available

5. binary compatibility on solaris 2.4 - library version warning

6. NE2000 Card = Compatible?

7. SunOS box w/ Solaris FS 'df' compatibility?

8. Sendmail relay problem.

9. ``A Library Implementation of POSIX Threads under SunOS/Solaris'', Version 2.

10. Compatibility issue between solaris 2.4 and solaris 2.6

11. Compatibility between Solaris 2.5.1 vs. Solaris 2.4

12. Compatibility issue between Solaris 2.4 and Solaris 2.6

13. Help - install Solaris and SunOS on Sparcbook2/ Solaris 2.4/5 ?