westerm@pur-ee.UUCP (Westerman) (10/04/84)
Anyone out there have guidelines for porting C progams between
operating systems, specifically 4.2, sys5, RSX-11M, RT-11, &
MS-DOS.
Thanks,
Rick Westerman @ Purdue University
{decvax}!pur-ee!westermminow@decvax.UUCP (Martin Minow) (10/08/84)
Rick Westerman asks for guidelines for porting code between various C implementations -- especially those on non-Unix machines. There are some suggestions in the Decus C documentation. They all boil down to D O N ' T B E C L E V E R . I.e, don't assume that free()/realloc() sequences do what they did on Unix V6. Don't assume that variable-names are significant past the 6th byte, etc. etc. etc.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/08/84)
There are (at least) two things to do to write C code that ports across operating systems. First, stick to portable language usage (use "lint" to check this). Second, use only those C library routines that exist across all systems (this is a pretty small subset), or else choose an environment and port the environment to each target system (this is the approach I generally use; it involves more work up front but then all applications port "free" from then on). Unavoidable system dependencies, such as routines to get a single character from a keyboard, should be isolated in separate modules with the SAME interface to the application but of course a different internal implementation on each system. Some of the C tutorial texts give good advice about portability, but others are awful. Plum-Hall publishes a good set of portability guidelines (two versions: one for UNIXes and one for general systems).
mac@tesla.UUCP (Michael Mc Namara) (10/10/84)
After doing a lot of porting of a set of C programs I wrote (between
UNIX 4.2BSD on a Vax 11/780, a Data General MV 8000 running AOS/VS 4.03,
a Vax 11/750 running VMS and a HARRIS 800 running VOS) I can offer the
following wisdom:
[1] don't rely on their library of routines; write your own.
(Use /usr/src/lib/libc as a guide, if you don't have license problems)
[2] The biggest problem I have found is that they don't call
stdio.h stdio.h!!!! On VMS, it is invoked with #include <std.h>
on the Harris, it is "STDIO.H" (caps necessary), et cetera
[3] Vms requires everything be initialized if it is to be external.
.
.
.
[oo] again, I could go on, but D O N ' T B E C L E V E R sort
of sums it up, so i qoute Martin Minow @ DEC.
------------------------------------
MAC @ Cornell Electrical Engineering
..!cornell!tesla!mac
!crnlccsb!mtm ------------------------------------taso@munnari.OZ (Taso Hatzi) (10/10/84)
It's probably true to say that the more useful C programs (no offence intended to authors of reproducers), call on functions in one or other library. Indeed, the 'language' derives much of its utility from the various function libraries that come with it. Those who have had occasion to use C under various systems will be aware that there are differences in the 'standard' libraries. Any two 'standard' libraries may have the same functions but chances are the name or calling sequence are different. It seems to me that some effort put into defining standard libraries for application domains would be just as useful as that put into defining the language itself. I guess first on the list would be a standard IO library. th
jon@boulder.UUCP (Jon Corbet) (10/12/84)
In article <tesla.434> mac@tesla.UUCP (Michael Mc Namara) writes: > > [2] The biggest problem I have found is that they don't call >stdio.h stdio.h!!!! On VMS, it is invoked with #include <std.h> >on the Harris, it is "STDIO.H" (caps necessary), et cetera > > [3] Vms requires everything be initialized if it is to be external. Really? Which compiler do you use? The VAX11 C (trademark of DEC, I'm sure) compiler (1) understands <stdio.h> as well as other nifty things like <signal.h> and <setjmp.h> that one would expect to be UNIX (TM) dependant. Furthermore, externals do NOT need to be initialized. My experience has been that UNIX code ports to VMS with little trouble, unless (1) you wire file names, or (2) use lots of process/job control stuff that VMS does not support. -- Jon Corbet National Center for Atmospheric Research, Field Observing facility
minow@decvax.UUCP (Martin Minow) (10/13/84)
MAC @ Cornell mentioned that, on vms, "they don't even call it stdio.h" -- I should note that Vax-C (Dec's C compiler for VMS) does support stdio.h. The language and library are extremely compatible with Unix usage. Martin Minow decvax!minow
daemon@decwrl.UUCP (The devil himself) (10/17/84)
Re: C Portability Between Non-UNIX Operating Systems___________________________ > I can offer the following wisdom: > [2] The biggest problem I have found is that they don't call stdio.h > stdio.h!!!! On VMS, it is invoked with #include <std.h>... > [3] VMS requires everything be initialized if it is to be external. Please be more specific; what C compiler are you using with VMS? VAX C, the official VMS C compiler of the 1984 Olympics*, uses stdio.h and doesn't require everything to be initialized if it is to be external. <_Jym_> ------------------------------------------------------------- *I am, of course, joking; please don't send lawyers after me!
mac@tesla.UUCP (Michael Mc Namara) (10/19/84)
> In article <tesla.434> mac@tesla.UUCP (Michael Mc Namara) writes: Organization: Cornell Electrical Eng. Lines: 29 > > > > [2] The biggest problem I have found is that they don't call > >stdio.h stdio.h!!!! On VMS, it is invoked with #include <std.h> > >on the Harris, it is "STDIO.H" (caps necessary), et cetera > > > > > [3] Vms requires everything be initialized if it is to be external. > > Really? Which compiler do you use? The VAX11 C (trademark of DEC, I'm > sure) compiler (1) understands <stdio.h> as well as other nifty things > like <signal.h> and <setjmp.h> that one would expect to be UNIX (TM) > dependant. Furthermore, externals do NOT need to be initialized. > > My experience has been that UNIX code ports to VMS with little trouble, > unless (1) you wire file names, or (2) use lots of process/job control > stuff that VMS does not support. > > x|p| |p~ |p|g|pp|g|`|g|x|p|pp|g|g|`~||p|pp| ~ p||| > Jon Corbet > National Center for Atmospheric Research, Field Observing facility > Ok, after I read your article I walked over to the Vax11 computer system we have here at Cornell, and indeed, they are not running Dec's C but are running Whitesmith's C for the Vax11, hence the problems are not due to VMS but to the particular compiler written by Whitesmith.... Michael Mc Namara @ Cornell University.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/19/84)
Sounds like the old Whitesmiths C system (<std.h>, globals must be initialized precisely once among all load modules).