Slashdot Mirror

← Back to Stories (view on slashdot.org)

LSB & Posix Conflicts

Posted by Hemos on from the understand-it-better dept.

An anonymous reader writes "The OpenGroup has published a detailed list of the conflicts between the Linux Standards Base and Posix ? that is accessible through their website. "

4 of 354 comments (clear)

  1. Nothing major by Anonymous Coward · · Score: 5, Informative
    Most of the differences fall into two catagories:
    1. The LSB spec is a sub-set of the required POSIX implementation (E.g. PThreads)
    2. The LSB spec has pulled in some extra GNU functionality (E.g. getopt(), extra flags to a few shell utilities)
    None of this seems to major however. Some of it even seems sensible (E.g. the LSB deprecates gets()) Some of it is dangerous though. This is especially true where the LSB and POSIX spec defers on things such as ioctl() and system() In these cases, LSB needs to come into line with POSIX, or at least support the LSB implementation as a superset of POSIX.

    Some of the LSB PThreads stuff could be anoying, but currently very few implementations of PThreads are feature complete anyway. LSB and Linux have just as much chance as anyone else to bring themselves into line with POSIX.

    Nothing too shocking, but it could be a handy reference. If in doubt though, stick with POSIX.
  2. WRONG! POSIX does some really dumb things!! by cculianu · · Score: 5, Informative

    POSIX does some dumb things. Ever hear of the gets() function?

    Also, in most cases the LSB is a superset of POSIX, but the contradictions are _minor_. Not show-stoppers.. not enough to require significant application rewrites when porting to Linux. So what if O_LARGEFILE is set most of the time? This is actually a good thing because most of the time it causes no problems. Even if you are checking the fd flags O_LARGEFILE being set isn't a problem as long as you check the flags in the _right_ way, that is logical AND'ing them with the flag you want to check for. The only time this contradiction causes a problem is if you are breing stupid and expecting the flags to be explicitly equal to some magic number you were expecting. Sure that is not exactly to spec, but for 99.9% of the apps out there it doesn't break compatibility, and if it does it's a one-line fix. However the benefint of fcntl() acting this way is clear -- most apps on linux have no problems with 64-bit file-sizes which are more and more common these days!

  3. Re:Everything Else by Diomidis+Spinellis · · Score: 5, Informative
    The POSIX compliance of Windows NT is a farce. It was only added as a marketing trick allowing Windows-based systems to compete in procurement contracts where POSIX compatibility is an obligatory specification. As implemented in Windows NT and Windows 2000 the POSIX subsystem is almost useless. According to Microsoft's documentation applications running in the POSIX subsystem applications have no direct access to any of the facilities and features of the Win32 subsystem, such as memory-mapped files, networking, graphics, or dynamic data exchange. Applications working in the POSIX subsystem essentially operate in an isolated text terminal island. The original POSIX subsystem was probably an embarrassment to Microsoft, so it was quietly dropped when moving to Windows XP and beyond in favour of the Interix technology.

    If you want POSIX compatibility under Windows you are better of using Cygwin or - at the shell level - the native ports of GNU utilities to Win32. Add to the mix my Outwit tools for Windows interoperability and you are set.

    Diomidis Spinellis - Code Reading: The Open Source Perspective
    #include "/dev/tty"

  4. Re:POSIX is required! by pmsyyz · · Score: 5, Informative

    2002, great, too bad it wasn't available in 1991.

    From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
    Newsgroups: comp.os.minix
    Subject: Gcc-1.40 and a posix-question
    Message-ID:
    Date: 3 Jul 91 10:00:50 GMT
    Hello netlanders,

    Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice.

    A month later, Linus posted:

    As to POSIX, I'd be delighted to have it, but POSIX wants money for their papers, so that's not currently an option.

    This June 1999 article is good: The Past and Future of Linux Standards

    Also, this Dec 2000 interview with Linus touches on Linux and POSIX/LSB standards.

    To sum it all up: POSIX is good, LSB is good, let's work together towards world peace.

    --
    Phillip