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

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.

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

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

[runderwo]

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

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?

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!