Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #8840

Re: 13 year old C source code

From "Scott Fluhrer" <sfluhrer@ix.netcom.com>
Newsgroups comp.lang.c
References <j0sbru0am8@news4.newsguy.com> <lnk4b2fa62.fsf@nuthaus.mib.org>
Subject Re: 13 year old C source code
Message-ID <1311891015.459259@rcdn-nntpcache-2> (permalink)
Organization cisco.com
Date 2011-07-28 18:10 -0400

Show all headers | View raw


"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnk4b2fa62.fsf@nuthaus.mib.org...
> buck <buck@private.mil> writes:
>> I haven't programmed in a VERY long time and I never was much good at
>> it anyway.  From this you can accurately imply that I'm the wrong
>> person to be doing this.  However:
>>
>> I have been tasked to determine the feasibility of updating 13 year
>> old (pre ANSI) ASM and C source code for the purpose of compiling a
>> 64-bit executable.
>
> If it's only 13 years old (1998), I'm a bit surprised that it's
> pre-ANSI; the ANSI standard was published 9 years before that
> (and re-published as ISO C90 a year later).
>
>> The source code was last modified in November of 1998 and was compiled
>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987
>> and 1986 respectively.
>
> Ok, those would be pre-ANSI compilers -- but at least some compilers
> back then probably supported prototypes, which are probably the
> most significant change ANSI introduced.


The DeSmet compiler most certainly did support prototypes; on the other 
hand, if the code he's porting doesn't use them, whether they were supported 
is irrelevent.

>
> On the other hand, K&R-style (non-prototype) function declarations are
> still legal, even in C99; I don't think even the C201X draft gets rid of
> them.  (A pity, IMHO, but that's beside the point.)
>
>> Are there any utilities that examine old C code and suggest how to
>> make it compliant with current compilers?  I tried splint v3.1.2, but
>> it crashes on line 110 of 824 lines and does not tell me how to
>> correct the errors and warnings it does find.
>
> Personally, I'd just compile the code with whatever modern compiler
> I want to use, and go through and fix any errors it reports.
> That requires a fairly good knowledge of C, but I can't think of
> any approach that doesn't.
>
> Be sure to use a good source control system so you can keep track
> of just what changes you've made.

One thing that the OP may need to be careful is if there are any explicit 
'near' and 'far' pointers; if the code tried to do anything fancy with them, 
well, you may end up having to figure out what they're doing, and rewriting 
that section.

>
>> Are there any utilities that examine 8086 ASM code and explain what to
>> change to make it compile for a 64-bit CPU?  I type 'debug' in a CMD
>> prompt in Vista in order to see the register names, but (of course)
>> Vista has no DEBUG...
>
> Can't help you with that.  It has nothing to do with C, so you'll get
> better help elsewhere.

One thing that comes into play here is the ABI (that is, the interface 
between a caller and the called routine, things like how parameters are 
passed, how return values are returned, what registers need to be preserved, 
etc).  The DeSmet compiler used one specific ABI (which was actually pretty 
popular at the time; they didn't invent it); I'm sure a C compiler running 
in 64 bit mode uses a significantly different ABI.  One of the things the 
rewrite will need to account for is retargetting the code to the new ABI.

This is looking less and less like a project that a newbie could handle...

>
> Most valid pre-ANSI C code should still compile with a modern
> compiler, though warnings are likely.  You'll probably have more
> problems with (a) use of extensions supported by the old compiler
> but not by the newer one, and (b) bad code that the old compiler
> didn't diagnose properly.

One thing I remember DeSmet not catching:

    char c;
    c = "T";    /* Yup; c got set to the lower 8 bits of the address, 
without even a warning from the compiler! */

-- 
poncho

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

13 year old C source code buck <buck@private.mil> - 2011-07-28 19:04 +0000
  Re: 13 year old C source code jacob navia <jacob@spamsink.net> - 2011-07-28 21:30 +0200
    Re: 13 year old C source code Francois Grieu <fgrieu@gmail.com> - 2011-07-28 21:35 +0200
      Re: 13 year old C source code jacob navia <jacob@spamsink.net> - 2011-07-28 21:48 +0200
        Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 13:37 -0700
    Re: 13 year old C source code buck <buck@private.mil> - 2011-07-28 20:28 +0000
  Re: 13 year old C source code Francois Grieu <fgrieu@gmail.com> - 2011-07-28 21:31 +0200
  Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 13:00 -0700
    Re: 13 year old C source code "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-07-28 18:10 -0400
      Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 15:27 -0700
  Re: 13 year old C source code Rich Webb <bbew.ar@mapson.nozirev.ten> - 2011-07-28 15:53 -0400
  Re: 13 year old C source code Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 16:18 -0400
    Re: 13 year old C source code Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 16:34 -0400
  Re: 13 year old C source code Ben Pfaff <blp@cs.stanford.edu> - 2011-07-28 13:36 -0700
  Re: 13 year old C source code gordonb.mgm25@burditt.org (Gordon Burditt) - 2011-07-28 15:37 -0500
    Re: 13 year old C source code Robert Wessel <robertwessel2@yahoo.com> - 2011-07-28 17:33 -0500
      Re: 13 year old C source code gordonb.2omx0@burditt.org (Gordon Burditt) - 2011-07-28 18:48 -0500
        Re: 13 year old C source code Robert Wessel <robertwessel2@yahoo.com> - 2011-07-28 19:26 -0500
    Re: 13 year old C source code BGB <cr88192@hotmail.com> - 2011-07-28 16:09 -0700
  Re: 13 year old C source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-03 08:17 +0000

csiph-web