Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 13 year old C source code

Reply
Thread Tools

13 year old C source code

 
 
Ben Pfaff
Guest
Posts: n/a
 
      07-28-2011
buck <(E-Mail Removed)> writes:

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


How big is it? What does it do? Based on the answers, you might
decide that rewriting it or using a modern equivalent is less
work and more satisfying than trying to port it to a modern OS
and toolchain.

By the way, if it's only 13 years old then it was written in an
old style: in 1998, the ANSI C standard had already been out for
9 years.
--
Ben Pfaff
http://benpfaff.org
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      07-28-2011
jacob navia <(E-Mail Removed)> writes:
> Le 28/07/11 21:35, Francois Grieu a écrit :
>> On 2011/07/28 21:30, jacob navia wrote:
>>> Le 28/07/11 21:04, buck a écrit :
>>>> One of the things I'm completely stuck on is the difference in char.
>>>> In the existing source code and with C88,
>>>>
>>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>>>
>>>> works, but the values obviously violate current char (and unsigned
>>>> char) rules.
>>>
>>> No, this is valid code. Why should it be wrong?

>>
>> -180 -146 and -179 are less than CHAR_MIN is on anything that
>> I ever used.
>>
>> Francois Grieu

>
> So what? The compiler should take the lower 8 bits...
>
> For instance -180 should be 0x4c.


Chances are it will do so (though the standard doesn't require it,
unless plain char is unsigned). But the unanswered question is,
why did the original code use -180 in the first place?

It could well indicate a bug in the original code, having nothing
to do with K&R vs. ANSI C (perhaps it was missed because the older
compiler didn't bother to warn about it).

We really don't have enough information to do more that guess,
but if I were working on this I'd certainly try to find out.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      07-28-2011
"Scott Fluhrer" <(E-Mail Removed)> writes:
[...]
> 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! */


Ok, that could explain why the code initializing a char to -180 never
got fixed (the compiler wouldn't have warned about it). It wouldn't
explain why it was written that way in the first place, but assuming the
code actually worked, either leaving it alone and ignoring the warnings,
or changing the value from -180 to 76, might be ok.

But we still have no clue what the char array is actually used for,
and the OP hasn't given us much feedback.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      07-28-2011
On 7/28/2011 1:37 PM, Gordon Burditt wrote:
>> 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.
>>
>> 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.

>
> What CPU is this? 8088? 8080? 8008?
>


I think elsewhere 8086 was mentioned.
most likely it was an MS-DOS app.

> One way to run a program like this is, especially when there's
> assembly involved, is to write a full emulator, with the binary
> of the program as the data. This is a large job, and it won't
> easily let you modify the code involved even after you're finished.
>
> If you do a good job writing the emulator, the code can be portable
> to many different CPUs, even though it still has ASM in it.
>


or maybe use DOSBox...

DOSBox can run DOS apps on modern Windows, and one can also get Win3.11
to work in it (albeit XPMode or VMware+WinXP are better for running
Win3.x apps, as then the OS is less prone to breaking...).


> Do you have a working version of the compiler that will compile it?
> (on any system you have access to?) It may well come down to figuring
> out what that compiler did (by examining the generated code) and
> figuring out how to do that in a portable way.
>
>> 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.

>
> Running slint on the program *crashes* slint? This is distinct
> from just giving an error message and giving up on further analysis.
> I hope you report the bug to the vendor.
>
> A lint-like program is a good tool, but it may overwhelm you with
> warnings. For syntax problems, generally the first error message
> is the one to look at, as the rest may be caused by faulty assumptions
> trying to recover from the first error.
>
> Don't expect a program to be able to guess how to fix it. If there
> are several things that are inconsitent, you need to make them
> consistent by changing all but one of them, but knowing which one
> requires a lot of knowledge of what the program is supposed to be
> doing. It's like going to a junk yard and trying to put stuff
> together, not realizing that the parts you have are half a car,
> half an airplane, half a vacuum cleaner, and half a TV set.
>
> One of the worst examples of this was a program entered into the
> obfuscated C contest that consisted of one array initialization
> (that's the entire program!):
>
> short main [] = { ...bunch of numbers in here ... };
>
> It's portable between the VAX and PDP-11.
>


yep...


>
>> Are there any utilities that examine 8086 ASM code and explain what to
>> change to make it compile for a 64-bit CPU?

>
> In one context I think they are called 'grad students'.
>
>> I type 'debug' in a CMD
>> prompt in Vista in order to see the register names, but (of course)
>> Vista has no DEBUG...
>>
>> One of the things I'm completely stuck on is the difference in char.
>> In the existing source code and with C88,
>>
>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>
>> works, but the values obviously violate current char (and unsigned
>> char) rules.

>
> I'm going to make an assumption that it took the bottom 8 bits of
> each value and stuffed them into a char/unsigned char.
>
>> If char is changed to long, the values seem to be
>> accepted, but the function is called with a char variable.

>
> If you change the definition so v[] is an array of long, you have to
> deal with changing everything that uses that array. Things may not
> go so well if a pointer into v gets fed to string-handling functions.
>
>> Any suggested resources other than utilities would be appreciated,
>> too. Google hasn't been much help, so the above includes a request
>> for suggested search phrases.

>
> You may find a lot of problems by carefully analyzing the type of
> every parameter passed to a function (particularly library and
> system functions) and make sure that it is correct. long is not
> necessarily the same size as int. int is not necessarily the same
> size as short. Also, keep an eye out for mis-use of pointers that
> depends on the byte-order of the CPU.
>


long ago (back when I was much younger), I had some code like this (the
Wolfenstein 3D source), which at the time I had no idea how to build
into a form I could run on more modern systems at the time (Windows and
Linux). at the time I did use it some as a read-only learning aide.

later on (after I learned programming a bit better), I could probably
have done it, but by this point there was no longer much point (as I was
off messing with the Quake source and OpenGL).

kind of funny how things are sometimes...

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      08-03-2011
On Thu, 2011-07-28, buck wrote:
> 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.
>
> 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.


The code may be 13 years old on the surface, but I get the feeling
it's soul is more like 30 years old ...

> Are there any utilities that examine old C code and suggest how to
> make it compliant with current compilers?


Like Jacob said, what you need is a C programmer. The compiler, the
build system and other normal tools should be enough as far as tools
are concerned.

Depending on the coding style of the original code, you may have lots
of work, or not so much. Much depends on how well the code used the
type checking (which IIRC was optional before ANSI C, and of course is
often disabled using casts etc even today).

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
13 year old C source - Thanks to all buck C Programming 14 08-04-2011 04:08 AM
old repository for old C++ source code *Prot3anThr3ad* C++ 6 10-02-2006 04:44 AM
old repository for old C++ source code *Prot3anThr3ad* Computer Support 7 10-02-2006 04:44 AM
Week of year to full Year Otuatail HTML 4 12-08-2003 07:50 PM



Advertisments