Slashdot Mirror
LSB & Posix Conflicts
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. "
← Back to Stories (view on slashdot.org)
- The LSB spec is a sub-set of the required POSIX implementation (E.g. PThreads)
- 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.
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!
Dude, gets() is so bad, there is _no way_ to guarantee that the incoming string isn't going to totally cause a buffer overflow! _No way_! You can ioctl() with FIONREAD all you want, you still aren't guaranteed that the string you pass to gets() is actually big enough to hold the incoming text. At best you get a program crash -- at worst you get a hacker with root!
gets() is just bad, horrible, terrible design. You say something about checking the input to prevent overflows, but by the time you get the string back from gets() it's too late! The stack is already fsked. Or if it's on the heap you probably already crashed or your program is somehow otherwise corrupt...
Funny thing you mention them in the same breath, since RMS was behing the original /usr/group that gave birth to POSIX.
Given that his world view isn't Linux-centric, I guess he'd be behind POSIX even today, as compliance would make eventual port to the Hurd easier in some measure; OTOH, many of the LSB extensions are actually the officialisation of GNU extensions in glibc and other GNU tools, so they don't hurt so much these days that software get ported from GNU to proprietary Unix instead of the other way round.
All things considered, standards should go together; extensions aren't bad if they bring benefits and are easily flaggable, but simple violations are evil if they can just creep in without bringing benefits nor being easily spotted.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Even if not, GNU has helpfully published a version of "Hello, World!" that uses autoconf, so it's quite easy to work around incompatibilities if the GPL isn't a problem for your project. It doesn't seem to be actively maintained at the moment, however, the current version 2.1.1 is over a year old.
Programming can be fun again. Film at 11.
I'm no thread programmer, but I think that NPTL (The Native POSIX Thread Library for Linux) may solve your problem.
/Styx
was the source of some of the headaches VMware has been giving people... (as the BSD implementation of nice(3) follows POSIX).
Code writers: pay close attention to this page if you want to avoid being laughed at by the rest of the world...
POSIX is a dead standard that hasn't moved ahead in 20 years. The LSB simply makes official the extensions and common way of doing things that has grown up in the years since POSIX stopped evolving.
A standards document like this is not a holy book that everyone must use as a daily guide. Every aspect of a standard like this should be constantly under ruthless attack to do things better.
When I was in the Army every unit I was in had a Standard Operating Procedures (SOP) book. This document formalized the way things were being done at the time. This made it easier to train new people, but if someone came up with a better, easier, faster way of doing things and could get it accepted, guess what? That's right, they updated the book. So various units would evolve slowly overtime to the best way of getting the job done.
A document like POSIX or the LSB is actually merely a "best practices" book and should reflect the best practices of the times, not be some arbitrary thing that documents how things were done 20 years ago.
Not to mention the fact that POSIX is silent on way too many very important things that govern an actual Unix or Linux distribution.
If two Unix or Linux distributions meet POSIX this is no guarantee that they are compatible in any way shape or form. But if two distributions meet the LSB, then you are guaranteed a very high level of interoperablity between the two.
And there are easy to use tools that actually test compliance to the LSB.
RMS is "Richard Stallman", the man behind the GNU project. Undoubtably a very talented and gifted individual, he has unfortunately been perceived as something of a "crank" amongst many people involved in the open source world. He is notorious for his insistence that the Linux OS should be referred to as "GNU/Linux", giving proper credit to the GNU software required to do anything useful. However, many people see this as whining - after all, following that precedent would mean that the OS should be called
GNU/X/Apache/GNOME/KDE/BSD/Linux
etc. in order to "properly credit" all those parties involved.
He also has a very big beard. See his webpage for more info on the man.
C:\Program Files\
Ok, is explorer.exe in C:\Program Files\Microsoft\Windows\Explorer\ ? Or in C:\Windows\ ? Or in C:\Windows\System32\? Or in C:\Program Files\Explorer\? And where's iexplore.exe ? Where's the uninstaller for FooSoft Bar? C:\windows\unwise.exe ?
Now go and find those settings. Are they in C:\Documents and Settings\Windows User\Application Data\ ? Are they in C:\Program Files\Foo\Bar.ini ? In win.ini? Are they in the registry in HKLM? Or in HKCU? Or even in HKU\.DEFAULT? Or in a group policy? Or in a custom policy? Somewhere in Active Directory?
Where does iexplore put it's cache? How about MSIE 4? How about 5? How about if you run ME? in C:\Windows\Cache ? In c:\Documents and Settings\Windows User\Local Settings\Temp? Win98x doesnt even have C:\Documents and Settings!
When is %windir% C:\windows and when is it c:\winnt? Why is %windir% even an environment variables, people fuck with those!
Windows paths are a great big piling heap of.. Well, something unpleasant. And the registry doubly so. Granted, the *nix way of doing things isn't perfect, but at least it had homedirectories(!) with
SCO employee? Check out the bounty
>something Windows got right from the start
Hahahahahhahaha, guess you didn't have to support anything prior to Win95.
Right from the start. ROTFL!
Mind you, that was the least of the problems with Win3.x, but your statement is just silly.
Everything is going toward POSIX compliance?
XP and Win Server 2003 aren't compliant.The POSIX subsytem was removed in XP and everything after.
POSIX does some dumb things. Ever hear of the gets() function?
Now correct me if I'm wrong, but I'm pretty sure gets() was defined
in the ANSI C standard libraries, and these were subsequently adopted by POSIX?
Not to mention scanf()/sscanf()..
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"
You seem to forget that posix is just a description of what functions a system must implement(If it want to support posix) and how theese functions must behave. It is not a system description.
Posix is(shuld be) a subset of LSB meaning that a LSB system should support posix, not the other way around.
Posix have been implemented on hurd,*Nix,linux qnx 6,amiga os(Almost, but contain some problems with the filesystem functions, and fork) and I also think that beos got a posix layer. (Oh and windows got posix support too, you just can't use it together with other windows functions, so that support is rather pointless)
Martin
POSIX is a dead standard that hasn't moved ahead in 20 years.
Except that, well, it's not. There's a new POSIX (ISO/IEC 9945:2002) which is now the same as the Single Unix Specification, V3. The article is about the differences between LSB and this version of the standard.
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
When most Linux systems conform to POSIX behavior on these aspects (for example by using NPTL for threads), the difference can be removed. Before then, programmers should try to make the program work in both POSIX systems and LSB systems.
It accomplishes NOTHING. First of all, the overflow can still occur if more I/O arrives on stdin between your ungetc and your gets call.
Secondly, if there was no data on stdin (e.g. closed pipe at other end) and you got unlucky during function initialization, you can overrun the dummy buffer with your strlen call. If there is no data, fgets will not alter dummy in any way, there is no guarantee that it is an ASCIZ string, and you call strlen on it. Boom! At least initialize dummy if you want consistent code behaviour.
Third, you're doing way too goddamn much work, and it's EXPENSIVE work!
How about this:
char buf[10];
if (fgets(buf, sizeof(buf), stdin) != NULL)
process_some_data(buf);
Simpler, cheaper, safer, quicker, easier to read, and not retarded!
Do daemons dream of electric sleep()?
Why not?
/usr readonly? If you've got files that could change during operation on that partition, you're stuffed.
Well, how about if you want to mount
BTW, installation/uninstallation of an app is the job of the package manager, not the user. If the PM knows what files belong to what package, what real advantage is there to having everything for that app under on directory?
As far as I can see the policy seems to be to comply with the POSIX standard as much as possible, except in cases where it is idiotic, in which case it seems reasonable to implement something better, as in the case of threading:
This guy has it backward. Linux is the standard for Unix. The OpenGroup should learn about the state of the world as it exists, and not fret over what is no longer. The OpenGroup has lost their prerogative. They are no longer in the game. Linux is the big dog; the rest of the also-rans are fleas along for the ride.
Here is last quarter's server market share:
$4.3 billion - all (real) Unix
$3.2 billion - all Windows
$583 million - all Linux
Linux is the flea, and will be for years, if not forever. It might not even be able to hold onto its current market share depending on the outcome of the SCO-IBM lawsuite.
Any thoughts that you have about Linux setting the standard for Unix today are either wishful thinking or stem from being uninformed.
POSIX doesn't define everything (other posters have pointed out that many of the differences are really extensions because of the GNU tools, which typically have more functionality than their POSIX/Unix equivalents), and having a single set of guidelines will really help to alleviate the "This works on Red Hat but not Mandrake or anything else" problem.
We'll take your example of RPM. The standard doesn't mean that everyone has to use RPM as their primary package format; they just have to be able to use RPM packages, which Debian can thanks to alien. So if you have an RPM of Commercial-Closed-Source-XYZ, it can be installed on your LSB-compliant system, and it will have a reasonable idea of where to find what it needs.
KDE and GNOME are cooperating to create common APIs so that software can be written for both at once. This is the same thing. Distributions can still do many things to set them apart from each other, like the strict package management of Debian. But having common ground for developers to target is a huge plus.
WMBC freeform/independent online radio.
The LSB simply makes official the extensions and common way of doing things that has grown up in the years since POSIX stopped evolving.
Except that many of these extensions and ways of doing things are only common on Linux systems. A program that adheres to POSIX isn't guaranteed portable to Linux, and a LSB compliant program isn't guaranteed to be portable to Solaris, BSD, AIX, HPUX, etc.
A Government Is a Body of People, Usually Notably Ungoverned