ANSI C89 and POSIX portability?

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?"

Comments

The story should have read:

[Anonymous Coward]

"Ask Slashdot: Can I revise my code?" Dear Slashdot community, I've got some old code; can I revise old code? Thanks.

I'd just go with well documented Visual Basic

[Clockwurk]

Re:I'd just go with well documented Visual Basic

[Anonymous Coward]

Or Phyton. Pyhton is sooo cool (says Guido).

Use autoconf.

[kyz]

Firstly, if you read the entire autoconf manual, you know the intricacies of 90% of these niggling little compatibility differences on every UNIX variant out there.

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.

[Cecil]

Yes, and while you're at it, shoot yourself in the face. It's a lot more fun than trying to figure out autoconf. Trust me, I've done it.

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.

[Anonymous Coward]

That autoconf/make/tools shit is the scourge of the earth.

Twisted ivory tower nerd assholes created that crap as yet another over-designed complex pile of shit.

It uses too many tools, too many scripts, too much code for what it does. It's complex and breaks all the damn time.

Idiots. Just idiots.

Re:Use autoconf.

[kyz]

autoconf is great. It's also fairly obvious if you read the manual. If M4 confuses you, learn it. Not everything has to be C, Perl or Bash syntax.

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't want my code to work on older or obscure architectures, I wouldn't use a configuration utility at all.

autoconf is still backwards compatible with all its documented macros. Keep using them. There is a conversion script for moving to the "new style" autoconf macros, which make it much easier to integrate with automake. If you used private, undocumented autoconf internals, they're now broken. Tough.

Re:Use autoconf.

[aminorex]

"Autoconf works"

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.

[Curtman]

I agree. autoconf, and automake are very intimidating in the beginning, but after a short learning curve they seem quite simple, and elegant. Luckily there are some great resources to get going with it, thousands of examples, and autoscan(1) is your friend.

• Autobook A tutorial for Autoconf, Automake and Libtool
• The autoconf manual
• The automake manual
• The libtool manual

Re:Use autoconf.

[Asmodai]

I have to agree.

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.

[statusbar]

Autoconf does not work. It it supposed to dynamically test the platform and figure out the appropriate way to build your app on the system. It tries to do this, but, it all comes down to the fact that it only works on the style of systems that autoconf was written for.

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 if linux is on i386 and I have wine installed! But alas, I usually cannot cross compile to mingwin32 from mac osx because the autoconf tests are unable to run the .exe's.

Another one is how it interacts with slightly different environments like cygwin/mingw/mac osx : .exe files versus .App directories, resource files, etc.

After originally being a total autoconf convert myself (I have the books!) I decided to roll my own. #ifdefs for the platforms that matter to me, and only those - for only those will be tested anyways. And Makefiles that use the filesystem to decide what files to compile into a library or executable, so nothing needs to change until a new platform is needed.

--jeff++

Re:Use autoconf.

[4of12]

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...

put the project code online

[Anonymous Coward]

and let the downstream distro maintainers give you patches. You should probably be focusing on over quality and maintainability of the code, not on why Irix version 5.blah.blah has no shitfuck() system call.

Re:put the project code online

[Anonymous Coward]

shitfuck() system call. Sounds messy.

It's still better than vfork().

Some thoughts...

[rjh]

• If it's working, be real careful in how you decide to 'fix' it. The old "if it ain't broke, don't fix it" adage is really true when it comes to old software.
• Check the original assumptions. Which platforms did it have to run on originally? How many of those vendors are still around? What platforms does it have to run on now? You may discover that the only platforms you need to support all have good POSIX facilities.
• If you've really got a wild hair to improve things, consider creating a port to $foo (Perl, Python, Java, .NET, etc.). One way to get around the lots of different incompatabilities problem is to use a language which already abstracts these things away, after all.
• If you absolutely must have platform-specific behavior in C, then GNU Autoconf is probably your best bet. Be warned that GNU Autoconf is arguably a cure that's worse than the disease. I've yet to meet one single programmer who's thought Autoconf was a good idea--only that Autoconf was a marginally less bad idea than all the other alternatives.

Good luck!

Re:Some thoughts...

[XO]

I think that Autoconf is about a bazillion times more complex than it probably needs to be. Perhaps one day I'll get to looking at it, and seeing what it really does, because it appears to do a whole bunch of mostly trivial junk, but everyone says it's insanely complex.

Re:Some thoughts...

[smittyoneeach]

What irritates me is the plethora of tools involved. The whole automake/autoconf thing is made huge and complex because of its requirement to be a lowest common denominator.
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...

[runderwo]

You couldn't even compile the Python interpreter on half of the platforms that Autoconf targets.

Re:Some thoughts...

[Anonymous Coward]

Yes, the lack of an AN/UYK-7 version is particularly irritating... ;)

Re:Some thoughts...

[Waffle Iron]

You couldn't even compile the Python interpreter on half of the platforms that Autoconf targets.

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...

[XO]

really, you'd figure that it would be able to make semi intelligent guesstimations of what resources are available just by inspecting the files within the system. god only knows what it's really doing.

ANSI is fine...

[Anonymous Coward]

Anything modern will at least have an ANSI compiler, though for some commercial platforms, the ANSI tools will cost you extra. In such a case, GCC will run just about anywhere, though.

As for the libraries... Well, there are a few calls which are not portable and should be avoided, or at least used with caution, because POSIX/SVID/BSD/etc. all have slight differences which conflict with each other.

I think it helps to look at manpages. Particularly, the "Conforming to" bits. If something says BSD or SVID, it might not work everywhere.

Also, the GNU manpages are fairly good at tracking potential portability problems.

Purpose?

[fm6]

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.

It seems like everybody who posts an Ask Slashdot story these days wants to know how, but hasn't thought about why. In this case, you want to "modernize" the code -- but is there any really good reason for doing so? Is the code hard to maintain in its current form? Are there efficiency issues? You don't say yes or no, but from the way you describe the project, it sounds like the answer is "no". Why risk introducing a bunch of bugs just to make the software "more modern"? Job security, perhaps?

Re:Purpose?

[rjh]

I've known the submitter for about ten years now, a little less, so maybe I can answer your question for you.

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?

[fm6]

The answer is elegance.

If you can't appreciate that answer, that's a strong sign you're not qualified to have an opinion.

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 years needs a bigger justification than truisims about elegant code. A programmer's job is to create and maintain reliable software that meets the needs of its users. A sense of software esthetic is justifiable as a means to that ends -- not an end in itself.

Re:Purpose?

[bangular]

I used to be on that boat, until I've had to work with systems that were implemented when I was in elementry school. When you have generation gaps of systems, it becomes EXTREMELY difficult to find people farmilar with it as the years go by. In this case, what if they don't update it and let it lapse another 10 years? How likely are they going to be to find someone that will be able to update it and add functionality then? They will probably pay a hell of a lot more to do it then than to do it now. It may seem silly and pointless to rewrite software every few years, but ultimatly you are doing yourself a HUGE favor. You think you are saving yourself time and energy now not rewriting and updating, but wait until you have to find and pay a consultant 100,000 dollars to add very simple functionality to your software.

Re:Purpose?

[doshell]

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?

[Anonymous Coward]

Not only that, if this is for a company, then if he changes code that does not need to be changed and he gets paid for doing it, then he should be fired.

Re:Purpose?

[TheLink]

Rewriting old C software into POSIX C seems even more pointless. Coz if he rewrites it, wouldn't they still have the same problem 10 years later?

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 and there's no urgent need to shift, you can take time to build the "blueprint" program, then the "plastic model" program, and then the actual program. That way you should really get something with quality[1].

[1]The trouble with most software is you are usually sold/given the "blueprint" just because the blueprint actually compiles (probably with thousands of warnings) and "works". If you're lucky you're sold the "Plastic model".

The other problem is unlike civil engineering etc, the blueprint and plastic models each cost about the same to make as the real thing. So it is rare you get to go through all the steps and just sell the real thing as your first product.

Re:Purpose?

[Com2Kid]

• Sure elegant code is better than messy code. But rewriting software that has performed reliably for years needs a bigger justification than truisims about elegant code.

followed by.

• A programmer's job is to create and maintain reliable software that meets the needs of its users.

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 as a means to that ends -- not an end in itself.
  

Treat it as more of a waypoint on a journey. :)

Re:Purpose?

[redhog]

There's a difference between a programmer and a hacker.

Re:Purpose?

[Omega1045]

That's pretty patronizing. Or maybe the word is fascist.

Me thinks we have a spy, fellow Slashdotters! This person (parent comment author) sounds more like a drama student than a programmer!

Re:Purpose?

[Anonymous Coward]

If a piece of software has ugly portability hacks from 1991 which aren't relevant anymore, and the software no longer needs to run on decades-old machines, why not remove them?

If more programmers understand ANSI than K&R (and they do), and the pre-POSIX stuff is no longer in active use (i.e. future generations of programmers might not understand them), why not streamline the code so that it will be more maintainable?

If a programmer needs to change the code in 2012 and sees archiac hacks for portability issues that were addressed in 1989 and fixed in the 1990s, don't you think he may get confused? By today's standards, it's completely reasonable to write a C program without ugly portability #ifdefs and have it run on all major forms of modern Unix. That kind of code is more maintainable than having one code path that uses mmap() and one that avoids it, for example.

Re:Purpose?

[Anonymous Coward]

At least you won't have to worry about stupid buffer overflow errors and crap like that.

Buffer overflows are not a relevant part of this equation. Your mention of them only reveals your bias against C. A competent C programmer knows how to avoid buffer overflows. It only becomes an issue when people get careless, and when a compotent C guy creates a buffer overflow by some fluke, he'll be able to fix it no problem.

Many of the myths about "impossible to debug C programs" are perpetrated by people who simply haven't sufficiently mastered C.

Python, Java and Perl

Who's to say that Python in 10 years will be compatible with the Python of today? At least ANSI/POSIX C has an established standards body. It's mature, it's stable, and it's simple enough such that it probably won't need much change. By comparison, where C is simple and basic, Python is pretty complex. It's also relatively new, with no standard to govern it, and new languages change fast.

And perl... Well, we all know perl releases are not necessarily compatible with one another.

Java IMHO is a much more reasonable suggestion, though it too changes often.

It's important to note that for this guy, changing languages may not be feasible or wise. There are plenty of applications C is great for. Believe it or not, C often works much better than Python, Perl, or Java. I don't think we should be playing language elitists here when the guy simply wants to know about C topics.

Re:Purpose?

[GlassHeart]

The answer is elegance. If you can't appreciate that answer, that's a strong sign you're not qualified to have an opinion.

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, never one completely overcoming the other.

Anti-hacker? You stopped being a hacker when you took the paycheck. Be a hacker who cares only about "elegance" on your own time. That paycheck requires you to also consider other priorities.

Re:Purpose?

[TheLink]

"A competent C programmer knows how to avoid buffer overflows."

"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 avoid buffer overflows is to use a sane programming language. 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.

Re:Purpose?

[Anonymous Coward]

Because, you know, everyone loves having to install $random_obscure_language, and a new one for every project.

Re:Purpose?

[torstenvl]

So you would propose "A competent C programmer does how to avoid buffer overflows." ?

Seems like you're comparing grammatical apples and oranges.

Nowadays using C when it isn't absolutely necessary is being...

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 is why BeOS is better than UNIX and all variations and clones thereof, right?

...stupid...

Re:Purpose?

[fm6]

I always resent being called a troll -- except maybe in this case. A troll is somebody who makes an argument he doesn't believe in just to piss off the other person. Such a person has no interest in having an actual discussion/argument. But if you think I'm such a person, why are you trying to refute me?

Yep, novels and memos are different kinds of prose. But both benefit from elegance -- and elegance is something with esthetic value.

Re:Purpose?

[TheLink]

I'm not sure what you mean with your first two sentences. The first line of my post was a quote of the AC.

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 will be able to spend more time building a lot more without having to waste time patching/updating each layer every two weeks.

With regards to OSes, it's kind of a step backwards that an O/S should ever have to "panic" for silly little stuff like having trouble with peripheral hardware.

The amount of competence required to write safe programs in C is beyond most people - smart people can be stupid and ignorant too sometimes.

Not all programs need to be safe - e.g. stuff which only takes input from trusted sources. But the requirement for safety and reliability is spreading.

Re:Purpose?

[fm6]

That pretty snobbish. And also ignorant. Hacking is just an unstructured style of programming. It is not a synonym for "sloppy work."

Re:Purpose?

[fm6]

To fuck off,
Or not to fuck off
Who gives a fuck?

POSIX and C89

[molo]

Ok, POSIX is all about the system calls and C library functions. C89 is about compiler support. They are seperate and don't go hand-in-hand.

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 /dev/[u]random and /proc filesystems. There's a lot of common interfaces, as long as you target relatively recent releases.

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/

Sourceforge also has a build farm which includes Solaris on sparc and x86 and MacOS X. http://sourceforge.net/docman/display_doc.php?doci d=762&group_id=1#platforms You have to be a developer of a sourceforge project to get access, but its a good deal.

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

[Anonymous Coward]

It is also worth mentioning that all currently maintained unix-like operating systems support the Single Unix Specification. The specification can be downloaded for free from www.opengroup.org. The latest version of the specification is SUSv3, but as a coder you're better off using SUSv2 (released 1998) since SUSv2 wasn't widely implemented until about 2001 and it is quite likely that some of your customers will want to run your software on older OS versions.

Re:POSIX and C89

[noselasd]

And if you look ad SUS, you'll see that it requires a whole lot of posix features.

Re:POSIX and C89

[Elm Tree]

<SARCASM>

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

[Anonymous Coward]

It's also worth mentioning that - as long as you stick to POSIX standards - you can then even compile your program for Windows by using some kind of compatibility layer (Cygwin or Microsoft SFU).

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...

Re:POSIX and C89

[_|()|\|]

Good advice to actually seek out test platforms. I've found subtle bugs in shell scripts and POSIX-ish C code on certain platforms. Some examples:

• The ls command returns success on OS X, even if no files were found.
• The test command has some options, like -e, which are not portable.
• HP-UX requires an ioctl() to detect that a slave PTY has closed.
• AIX has fewer than 64 PTYs configured, by default, which exposed a bug in one of my programs.
• There seems to be disagreement on the types of some socket functions. I have yet to figure out how to get the client's address from accept() without causing a compile warning on at least one platform.
• Reaping child processes seems to be another mess. The most portable solution I've found is to double fork, letting init clean up the zombies.

I've started porting a Unix program to Windows and VMS, which has been interesting. For example, Windows and VMS both have a select() function, but it only works on sockets. The popen()/_popen() function on Unix and Windows doesn't redirect stderr, whereas it does on VMS. VMS only lets you get the actual exit status from waitpid() or pclose() in recent versions.

Re:POSIX and C89

[GlassHeart]

POSIX is all about the system calls and C library functions. C89 is about compiler support. They are seperate and don't go hand-in-hand.

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 implementations better than the desktop class of computers are "hosted", and must provide the entire Standard Library.

POSIX makes additional guarantees on the language (C is written for the lowest common denominator in many ways), and requires additional library functions.

Re:POSIX and C89

[isj]

test -e is portable, just not with Solaris' braindead /bin/sh :-/

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*:

sockaddr_in sa;
socklen_t sal = sizeof(sa);
int cfd = accept(fd, (sockaddr*)(void*)&sa,&sal);

Re:POSIX and C89

[_|()|\|]

Actually, the -e switch doesn't work under ash and some versions of ksh (including that shipped with HP-UX), where it's a built in. I don't remember whether I found any copies of /bin/test that don't support -e.

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

[Anonymous Coward]

I agree with poster's advice, but technically C89 is not all about the compiler. It also involves bits
of the language that are implemented in libc...
for instance, C99 atoi() is different than C89 atoi()

Which can cause very subtle bugs :)
C99 atoi(0x1) = 1
C89 atoi(0x1) = 0

Garick

Re:POSIX and C89

[bedessen]

Why not use Cygwin? It "fixes" the Win32 behavior you speak of and gives you back the unix/posix environment on windows. Of course it also means your code is touched by the GPL fairy, so if it's not free software then it could be a problem.

Obligatory book reference

[DarkDust]

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, 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.

Re:Obligatory book reference

[endx7]

Yes, windows includes partial compatibility with one catch: most of the stuff they -do- support is prefixed with an underscore. You can work around that by definingmacros as wrappers in your ifdef'ed windows specific header (kinda like glib does). Most of this is in the base windows system.

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-underscored naming? I know that the netbsd people have ported pkgsrc to it at least)

Re:Obligatory book reference

[smittyoneeach]

'Doze services for Unix. But why? Just get MinGW. Heck I even compiled emacs from source, which was something of a tooth extraction.
Granted, Cygwin would've been easier, but it ain't called easemacs...

What part of POSIX?

[hubertf]

POSIX is not a single specification, but consists of quite a number of parts. While some of the basic interfaces can be considered of widespread use, I wouldn't recommend using others like realtime handling or maybe even threads.

- Hubert

embedded

[Quill_28]

Are you also including embedded systems like:
vxWorks, QNX, pSOS, OSE, etc..

Not necessarily

[squiggleslash]

Believe it or not, there are still K&R systems around. I was somewhat surprised and a little disheartened about six years ago when one of our clients gave us use of a machine where pretty much the only development tools were an old version of Perl and a K&R C compiler - and not a "modernized" just-pre-ANSI one either, I mean something that choked on function prototypes in a way my Sinclair QL's Metacomco C compiler didn't back in 1995...

In case anyone's interested, this is a HP-UX 11 (the machine is a 9000/800) system, and we can only use it, not administer it, and they pretty much refuse to upgrade anything other than Oracle on it, so we're still stuck with the damned compiler.

That said, there is a solution: GNU GCC comes with an ANSI to K&R tool. I've not tried it, but it's probably worth playing with. If your ANSI 89 C code can also stay compatable with the translator, then your plans for total compatability should hold up.

And, of course, some people would argue that K&R was never standard anyway. They're kind of correct, there was a general consensus to how it should work (some of which contradicted the book itself) and most of the incompatabilities were actually extensions, but there will be areas of incompatability whatever you do.

Re:Not necessarily

[randombit]

and a K&R C compiler - and not a "modernized" just-pre-ANSI one either, I mean something that choked on function prototypes in a way my Sinclair QL's Metacomco C compiler didn't back in 1995...

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 you to buy the real compiler (or install GCC, of course). So HP isn't really a K&R only system (I mean c'mon, how could you sell a system like that anytime in the last 10 years?), it just ships with a crippled compiler, which is a shame because some people continue to insist that it's usable for anything -- it's not.

Re:Not necessarily

[calidoscope]

That C compiler is (AFAIK) only shipped for building new versions of the kernel.

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) - then again, you wouldn't want to trust your kernel to a flaky compiler, would you?

Re:Not necessarily

[squiggleslash]

It's actually not a bad compiler, it's just about 15 years out of date - older if you consider the fact that function prototypes and other nicities were pretty much becoming standard in the late eighties without the help of ANSI.

It's usable for just about anything except compiling code intended for other systems. I didn't really think, for some reason, about the option of compiling GCC locally (eg into our user account), I may try that and see how far we can get. That would at least also allow us to get around the Perl et al issues too.

HPUX is the CP/M of Unix systems

[Anonymous Coward]

You can always try to install gcc in some temp dir. That's what I do on such castrated platforms. It goes a long way to restore sanity.

Re:HPUX is the CP/M of Unix systems

[J�r�me Zago]

You can always try to install gcc in some temp dir. That's what I do on such castrated platforms. It goes a long way to restore sanity.

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

[_|()|\|]

You can always try to install gcc in some temp dir.

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.

Plan 9

[Leimy]

Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.

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 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 which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer 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.

testdrive systems

[r00t]

Where can I find these?

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

[molo]

Sorry, I don't know of any. If you find them, let me know, I'd be interested too. Thanks.

-molo

QNX?

[calidoscope]

QNX is still being used - the latest version now hs gcc support - versus that Watcom compiler for earlier versions (4.25 and earlier).

Use Samba as a reference

[lkaos]

We go through great lengths in Samba to be as portable as possible. Our build farm runs the most popular unices on all sorts of architectures (you'd be amazed how different Linux on x86 can be than Linux on say a s390). We support a ton of platforms including some as obscure as the Amiga.

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

[Asmodai]

Sendmail has a master header file, IIRC config.h, which lists all kind of platform wrappings as well.

Also interested to compare notes with, also postfix' makedefs framework lists broken implementations on different platforms.

Re:Use Samba as a reference

[hey]

Sendmail is NOT a good guide for elegance!

Re:Use Samba as a reference

[Anonymous Coward]

Sure, but it does run on a lot of systems...

Re:Use Samba as a reference

[Asmodai]

Either you are misreplying or misunderstanding my post.

I merely said that the config.h is a prime example of platform specific notes.

yeah and when i rotated your tires

[Anonymous Coward]

at the tire shop, i saw that your engine was running on gasoline. how barbaric, i thought, so i upgraded it to hydrogen.

Don't use autoconf....

[V. Mole]

...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 install GCC).

access to IRIX and BSD

[green pizza]

Get an old black NeXTstation or NeXT cube from eBay if you want a 4.2 BSD based machine. IIRC, the original OS, NeXTstep, was based on 4.2 BSD, while the later OS, OpenStep, was based on 4.3 BSD.

If yuo need a Silicon Graphics box to develop software on, check out http://forums.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 give you all of the development tools for free if you join their "plus" developer program as a "hobbyist". SGI also gives away free accounts on their big iron Origin (IRIX) and Altix (Linux) systems, but you probably have to be a full-time serious developer for that.

Re:access to IRIX and BSD

[CRCulver]

IIRC, the original OS, NeXTstep, was based on 4.2 BSD, while the later OS, OpenStep, was based on 4.3 BSD.

The latter OS, NeXT's implementation of the OpenStep standard, was called OPENSTEP. There's a concise explanation of the capitalization confusion.

Go with ANSI C94 and POSIX

[Asmodai]

Just do it.

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!

[mritunjai]

Hi there,

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!

[Anonymous Coward]

I'm on same track as mritunjai. Fix only problems and don't make any changes to working code. Think that you are saving money and time if you don't rewrite working code.

Re:Fix yes, Modernize no!

[Asmodai]

Funny.

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

[marcovje]

One might check out FreeBSD 4.x, it defined some workaround systems for prototypes to be both Ansi and K&R usable.