ANSI C89 and POSIX portability? 85
LordNite asks: "Here is the situation. I am maintaining a piece of source code which is written in K&R C. One of the original goals of this code was to be as portable as possible to as many platforms as possible. The code runs on UNIX and its clones as well as OS/2. The code avoids POSIX functions such as mmap(2) since at the time it was initially written (early 1990s) POSIX was not very wide spread. The code is well written, but in need of some serious fixing. As I go around fixing parts of the code I would also like to modernize it a bit. Since it is now 2004, can I rely on ANSI C89 and POSIX routines without sacrificing the portability of this code? (Yes, I do realize that the purpose of POSIX is code portability...) I am not really interested in the OS/2 port at this time. I am just interested in keeping portability with UNIX clones. To put my question another way: Are there any UNIX-like OSes in common use, which are currently developed and supported by some entity either OSS or proprietary, that do not support POSIX and ANSI C89?"
I'd just go with well documented Visual Basic (Score:3, Funny)
Use autoconf. (Score:5, Insightful)
Secondly (with automake) it can make a build environment that automatically converts ANSI C to K&R C, if the target install environment only supports K&R C. So don't sweat it. Use mmap() if HAVE_MMAP is defined. Personally, I would abstract file I/O and do all work as abstract file operations. You can then choose after-the-fact whether to fopen()/fread()/fclose() or mmap()/memcpy().
Re:Use autoconf. (Score:2)
autoconf works. That's about the only good thing anyone could ever say about it.
P.S. is there any fucking reason they feel the need to make new versions incompatible with older config files and vice versa? Have they ever heard of backward compatability?
Re:Use autoconf. (Score:3, Insightful)
autoconf works, autoconf works and autoconf works. Why do you use a configuration-detection script? Because you want your software to work! None of autoconf's "replacements" actually work in all scenarios. What's the point?
Sure, this one has simpler syntax, or that one makes smaller shell scripts, but they don't work on older or obscure architectures! If I didn'
Re:Use autoconf. (Score:1)
Re:Use autoconf. (Score:3, Interesting)
What do I mean? A big one I hate autoconf for is how cross compiling is broken on almost every one as many compiler tests require the ability to run the code locally. A neat trick I found is that I can cross compile to mingwin32 from linux
Re:Use autoconf. (Score:3, Interesting)
For some value of "works". Autoconf and automake are sorry hacks that should never have been undertaken.
Instead, there should be one master "config.h" file that infers from the platform headers exactly what HAVE_xxx macros should be defined, and one master "config.c" that abstracts over differences where it is trivial to do so. Everybody shares that, and nobody needs this jiggery-pokery with autoconf, automake, dlltool running recursive m4s. For the love of God, Montressor -- m4!\
Re:Use autoconf. (Score:3, Interesting)
I've done autoconf maintenance for some open source projects, I contributed to the auto* projects and my final conclusion is that they are not helping.
Instead I am just building my own detection code in a similar line as postfix' makedefs does. A lot clearer and keeps your sanity.
Re:Use autoconf. (Score:2)
Instead I am just building my own detection code
But then, I love that autoconf users have already built up a library of m4 macros for the typical kludges and different behaviors so that I don't have to do it again myself.
Yes, autoconf sucks, but I haven't seen a better system that doesn't sacrifice portability.
Now an autoconf that might check /etc/config.cache.xml or ~/.config.cache.xml might be an interesting improvement...
Don't use autoconf.... (Score:3, Informative)
...unless you really want/need to support ancient and obscure platforms. But since the question specifically *said* modern and maintained platforms, then autoconf will just uglify and complicate your code.
And in answer to the original question: yes, if you're talking modern unix or unix-like systems (i.e. AIX 4.3 or 5, Solaris 7 or later, Linux/glibc or BSD from the last several years, HPUX 11), then yes, you can assume POSIX and C89 (although for AIX, Solaris, and HPUX you'll need to buy a compiler or ins
Re:put the project code online (Score:1, Funny)
It's still better than vfork().
Some thoughts... (Score:4, Insightful)
Re:Some thoughts... (Score:2)
Re:Some thoughts... (Score:2)
IMHO, a robust, easy to learn, well documented, got-everything-you-need system needs to gulp all of that automake/autoconf (and why not make, itself, while we're after reductionism?) noise down. I nominate Python.
Re:Some thoughts... (Score:3, Insightful)
Re:Some thoughts... (Score:1)
And yet Python somehow manages to run natively on that one platform that is installed on most of the world's computers, whereas AFAIKT, Autoconf just blows it off.
Re:Some thoughts... (Score:2)
Purpose? (Score:3, Insightful)
Re:Purpose? (Score:5, Informative)
The reason is simple. He's a hacker. He sees something that works but is inelegant; and he'd like to be able to make it a little more elegant. It's that simple.
So the answer to "why risk introducing a bunch of bugs just to make the software 'more modern'" is not a facetious "job security".
The answer is elegance.
If you can't appreciate that answer, that's a strong sign you're not qualified to have an opinion.
Please note, by the by, that I almost agreed with you. I recommended that he be very careful in what he fixes and how. That's worlds apart from saying "leave it alone, you don't know what you're doing". Any answer of "leave it alone" is fundamentally anti-hacker.
Re:Purpose? (Score:1, Troll)
That's pretty patronizing. Or maybe the word is fascist. If I can't understand you, than I must be out of my depth? That's a formula for ignoring anybody that disagrees with you. Since we're discussing elegance of expression, maybe you should just say "Up yours!" and let it go at that!
Sure elegant code is better than messy code. But rewriting software that has performed reliably for
Re:Purpose? (Score:1)
Mmm troll...
A sense of software esthetic is justifiable as a means to that ends -- not an end in itself.
It depends on whether you think programming is conceivable as an art or not.
There is also a big difference between using the English language to write a memo for your boss and using it to write a novel.
Re:Purpose? (Score:2)
Yep, novels and memos are different kinds of prose. But both benefit from elegance -- and elegance is something with esthetic value.
Re:Purpose? (Score:1)
followed by.
If the code's a pain to read, and hard to understand, making it look good might very well be the first step towards making sure it is maintainable in a far more efficent fashion.
A sense of software esthetic is justifiable a
Re:Purpose? (Score:2)
Re:Purpose? (Score:2)
Re:Purpose? (Score:3, Funny)
Me thinks we have a spy, fellow Slashdotters! This person (parent comment author) sounds more like a drama student than a programmer!
Re:Purpose? (Score:2)
Or not to fuck off
Who gives a fuck?
yeah and when i rotated your tires (Score:1, Funny)
Re:Purpose? (Score:2)
I'm a professional software engineer. I'm not at all averse to refactoring or rewriting code.
However, because I'm paid for my time, I only do things that are worthwhile to my employer. If the code is unlikely to get new requirements or features, then it's best to leave it alone just because it seems to still work. What I produce for work is a balance of business sense and elegance, n
Re: (Score:2)
Re:Purpose? (Score:2)
If they really want to rewrite the software why do it in C of all languages? Why not python or java or even perl? At least you won't have to worry about stupid buffer overflow errors and crap like that.
Python, Java and Perl run on quite a number of platforms the last I checked. java would run fairly fast (given enough memory...).
Since the existing stuff works an
Re:Purpose? (Score:2)
"knowing" and "doing" are very different things.
So far it seems like that there are fewer than 5 people in the world who can do it successfully in contrast to the millions who merely _think_ they can.
Just take a look at the bugtraq mailing list. apache, ssh, openssl, linux kernel, etc. So do those developers know how to avoid buffer overflows?
Nowadays using C when it isn't absolutely necessary is being stupid or ignorant.
The easiest way to
Re:Purpose? (Score:1)
So you would propose "A competent C programmer does how to avoid buffer overflows." ?
Seems like you're comparing grammatical apples and oranges.
Using C is never *absolutely necessary*. So you would propose that writing an OS in it is stupid and ignorant because BeOS showed that it could be done in C++? That, of course, would mean that most OSes, including -- probably -- the one you're using, is made by stupid and ignorant people. Which
Re:Purpose? (Score:2)
Any programming language where it is _common_ for a small mistake (e.g. off by one) to "allow an attacker to remotely execute arbitrary code of his/her own choice" should be avoided where possible.
So if it's common for that to happen to C++ then avoid it as well. Or start changing things (e.g. default behaviours, libraries, methods etc) so that it's uncommon.
Stick to a solid foundation and people wil
POSIX and C89 (Score:5, Informative)
About POSIX and Unix compatibility. There are a handful of Unixes that remain important and widely deployed. They are:
Solaris
HP-UX
AIX
Linux
*BSD
MacOSX
They pretty much all have modern APIs in recent versions. The older unixes have recently added a bunch of Linux-like modern APIs to make portability easier. This was the reason behind HPUX 11i (the 'i' denotes "internet ready", but what they really mean is glibc/*BSD apis). This is also the reason behind the AIX 5L name (AKA 5.1, 5.2) (L = linux affinity, same deal, new GNU/*BSD apis). You know that MacOSX uses a BSD-based userland, so you're fine there. Then there's Solaris, of which recent versions (>=2.6) are in good shape. Recent versions of the proprietary unixes even have
Ok, once you figure out what platforms you are targeting, you need to figure out what compilers you will support. All of the proprietary Unixes have their own C compiler (sometimes only available for a fee). Many are not fully ANSI compliant. They are definitely not all C99 compliant. That is the bad news.
The good news is that gcc is available for all of the major platforms. This is what gcc excels at, it is highly portable. You can use this to your advantage to get things working on these platforms. If your users then want to get them working with other compilers, that is worth a shot too (non-gcc compilers often produce better optimizations, etc.).. but it will be hit or miss.
Testing. I highly recommend the HP Testdrive program. They make available a bunch of machines with various HP hardware running various operating systems from Linux on Alpha to HPUX on IA64, including Tru64 (aka OSF/1). http://www.testdrive.compaq.com/ [compaq.com]
Sourceforge also has a build farm which includes Solaris on sparc and x86 and MacOS X. http://sourceforge.net/docman/display_doc.php?doc
Good luck. Hope this helps.
-molo
HPUX Note: Many people think that 11i is for the Itanium platform. That is not the case. 11i is version 11.11 and higher. 11.11 is for HPPA. 11.20 and higher are for IA64. Both are called 11i.
Re:POSIX and C89 (Score:1, Informative)
Re:POSIX and C89 (Score:2)
Re:POSIX and C89 (Score:3, Funny)
Wait...
I think you missed a major version of unix there. In fact the only *real* unix, SCOWare. They even own the copyright on "UNIX".
</SARCASM>
Re:POSIX and C89 (Score:1, Interesting)
That is to say, POSIX is an important enough standard that even the world's least compatible operating system has a choice of POSIX compatibility modes...
testdrive systems (Score:2)
AIX
IRIX
FreeBSD 5.x
Solaris 10
any 4.2 or 4.3 BSD
any SVR4-MP
any "Trusted" system
OS/390
I need these for an Open Source project I maintain.
Re:testdrive systems (Score:2)
-molo
access to IRIX and BSD (Score:2)
If yuo need a Silicon Graphics box to develop software on, check out http://forums.nekochan.net [nekochan.net]. Someone there can probably give you an account on a SGI IRIX 6.5.x system with gcc and/or MIPSpro. You could also buy an O2 from eBay for about $50. You'll still need to find a more recent version of IRIX, but SGI will
Re: (Score:2)
QNX? (Score:3, Informative)
Re:POSIX and C89 (Score:3, Interesting)
Re:POSIX and C89 (Score:2)
have yet to figure out how to get the client's address from accept() without causing a compile warning on at least one platform.
My guess is that it is on HP-UX with aCC? In that case you have to cast over void*:
Re:POSIX and C89 (Score:1)
As I recall, the problem with accept() actually had to do with socklen_t, which isn't defined the same on all platforms. It's not a big deal, but I like to keep my code warning free.
Re:POSIX and C89 (Score:2)
Re:POSIX and C89 (Score:2)
C89 refers to the version of C standardized in 1989, which devotes hundreds of pages to the Standard Library (C99 devotes over 280 of about 600 total pages to the library). While "freestanding" implementations are not required to contain any or all of the Standard Library, it's really just provided as a way out for very limited processors. Practically all C implementation
Obligatory book reference (Score:3, Informative)
AFAIK really all UNIX and UNIX-like systems support at least POSIX-1988, and most even support SUS1 and higher. Heck, even Windows NT/2000 are (partly) POSIX compatible, and to my knowledge Windows XP can be made POSIX compatible with some extra package from MicroSoft, but I don't know which).
I really recommend Advanced UNIX Programming [basepath.com], it's an excellent book which not only discusses and explains POSIX and SUS APIs but also where you can expect those APIs to be avaible and how to test for them to be sure. It was also reviewed here at Slashdot [slashdot.org].
Re:Obligatory book reference (Score:2)
Also, (which you also mentioned, but didn't know the name) microsoft provides Microsoft Services for UNIX (more recently known as Interix), which provides..something for UNIX compatibility (userland? maybe non-undersc
Re:Obligatory book reference (Score:2)
Granted, Cygwin would've been easier, but it ain't called easemacs...
What part of POSIX? (Score:3, Informative)
- Hubert
embedded (Score:1)
vxWorks, QNX, pSOS, OSE, etc..
Comment removed (Score:3, Interesting)
HPUX is the CP/M of Unix systems (Score:2, Interesting)
Re:HPUX is the CP/M of Unix systems (Score:1)
Been there, done that. Also installed other GNU stuff like bash, coreutils, findutils, grep, make... "./configure --prefix=$HOME" definitely helps...
Re:HPUX is the CP/M of Unix systems (Score:2)
This may not be an option for the latest version of GCC. I seem to recall a mention in the release notes that you can no longer bootstrap with a K&R compiler.
Re:Not necessarily (Score:3, Interesting)
In case anyone's interested, this is a HP-UX 11 (the machine is a 9000/800) system
That C compiler is (AFAIK) only shipped for building new versions of the kernel. You can also buy a reasonably decent C99/C++98 compiler from HP for about a zillion dollars. The reason they cripple the shipped compiler is to force
Re:Not necessarily (Score:2)
One of the more prominent entries on the HP-UX FAQ (more relevant to the days when HP-UX was a contender for desktop UNIX) - was why the built-in compiler was brain-dead. The answer is what you said - it is there for building the kernel (as has been that way since HP-UX 8.x, and probably before). It was a pretty nice compiler as long as the source was strict K&R (it had code to detect ANSI C and would issue an error) - the
Re: (Score:3, Informative)
Plan 9 (Score:3, Interesting)
It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this [bell-labs.com] for more information.
The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.
I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.
As you can probably tell. I was impressed.
If you don't want to mess with installing over you existing OS you can try Inferno [vitanuova.com] which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer [corpus-callosum.com] to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.
Use Samba as a reference (Score:5, Informative)
What I'd do if I were you is to just grep the Samba source code before you use a function. You'll likely find a list of platforms that it doesn't work on, or that simply doesn't have that particular function. You may also find workarounds for bugs in particular implementations.
Re:Use Samba as a reference (Score:2)
Also interested to compare notes with, also postfix' makedefs framework lists broken implementations on different platforms.
Re:Use Samba as a reference (Score:2)
Re:Use Samba as a reference (Score:2)
I merely said that the config.h is a prime example of platform specific notes.
Go with ANSI C94 and POSIX (Score:3, Interesting)
For both TenDRA and DragonFly we're using ANSI C94 (C90 plus amendments) along with POSIX/SUS and the code in general tends to get cleaner and cleaner (and easier to understand in my opinion).
It is amazing, since I am doing a lot of these conversions on a plethora of different old time tools, how much programming errors/mistakes the old code managed to get away with...
Fix yes, Modernize no! (Score:3, Insightful)
You're one of the few still having a job! You've got a project at hand, and you NEED to do it well.
DO NOT modernize if you don't have to! What you have in your hands is, as you tell, a nice *working* code. IF after your "modernization" crusade, it breaks on some platforms, even due to platform bugs, it will be YOUR neck under the guillotine. Understand THAT!
And, no, I'm not talking this from my behind... been there, done that, got burned!!! Unnecessary modernization/elegance/optimizations/refactoring is root of all evil and prime cause of job loss! Do your job, and fix whatever is *NEEDED*... and make sure you ain't breaking anything. If you can do THAT much flawlessly, you should be thankful. In software engineering there are just too many variables and you carry the onus of working around them. All compiler/platform/libc bugs will form part of YOUR work... so be careful!
Re:Fix yes, Modernize no! (Score:2)
My experiences have been the total opposite of yours. The ANSIfied code in general is clearer, solved mysterious bugs present in the K&R code, and was on the whole easier to maintain than the old code.
FreeBSD 4.x IIRC is still K&R compilable (Score:2)
One might check out FreeBSD 4.x, it defined some workaround systems for prototypes to be both Ansi and K&R usable.