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

 
 
buck
Guest
Posts: n/a
 
      07-28-2011
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.

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.

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

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. If char is changed to long, the values seem to be
accepted, but the function is called with a char variable.

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.
--
buck
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      07-28-2011
Le 28/07/11 21:04, buck a écrit :
> 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.
>


All this doesn't look very fresh...


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


No, you need a human to do that. And you have to pay gim/her a
significant amount of money since it is a significant effort.

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


Well, you need someone that knows C and assembly.


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



From this question I understand that you have really no clue...



Compiling/Assembling is not really that difficult. But I suppose that
you want that it RUNS correctly afterwards isn't it?


> I type 'debug' in a CMD
> prompt in Vista in order to see the register names, but (of course)
> Vista has no DEBUG...
>


Vista has very good debugger though... But you will need a 16 bit
debugger and those beasts disappeared something like 15 years or more
ago.

> 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 be wrong? You are probably compiling
with char defaulting to unsigned char. Change that.


If char is changed to long, the values seem to be
> accepted, but the function is called with a char variable.
>


Normally, a char variable is changed to int when passed to a function
that receives a char anyway since in modern CPUs you never push a
single char into the stack.


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



Look buck, the only real solution is to get somebody that knows the
stuff and pay him $$$ to do the job. You can't do it, I fear, you would
need months of work just to get started into it.
 
Reply With Quote
 
 
 
 
Francois Grieu
Guest
Posts: n/a
 
      07-28-2011
On 2011/07/28 21:04, buck wrote:

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


Try

#include <limits.h>
#define CHARIZE(x) (CHAR_MIN+255&((x)-CHAR_MIN))
static char v[]={CHARIZE(-20),CHARIZE(-124),CHARIZE(-180) ...

However, if that's obfuscated x86 code, you might be out of luck.

Francois Grieu
 
Reply With Quote
 
Francois Grieu
Guest
Posts: n/a
 
      07-28-2011
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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      07-28-2011
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.
 
Reply With Quote
 
Rich Webb
Guest
Posts: n/a
 
      07-28-2011
On 28 Jul 2011 19:04:29 GMT, buck <(E-Mail Removed)> 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.
>
>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.


splint was an academic exercise and never really a very good tool in
production (although there are certainly folks who use it that way). If
you need linting, then Gimpel lint is the way to go. Be aware that code
that wasn't linted during development can throw so many warnings and
errors that fixing everything can be like cleaning King Augeas' stables.
"So much ****! Where to start?" The answer is probably the same one that
Herc used: wash it all away and start over rather than try to go at it a
line at a time.

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


Machines are much faster nowadays and have lots more resources, so
whatever prompted the original requirement for embedded assembly may no
longer be important. You'll need to understand what the original
assembly was doing, whether you leave it as assembly or use C, so first
thing would be to replace it with functionally equivalent C code and
that may be good enough.

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


Change to "static signed char ..." Check other places where the
signedness of char may matter.

>
>works, but the values obviously violate current char (and unsigned
>char) rules. If char is changed to long, the values seem to be
>accepted, but the function is called with a char variable.
>
>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.


--
Rich Webb Norfolk, VA
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      07-28-2011
buck <(E-Mail Removed)> 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 (199, 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.

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.

> 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 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. If char is changed to long, the values seem to be
> accepted, but the function is called with a char variable.


That's not a K&R-vs-ANSI issue. Unless C88 targets some exotic
system with char bigger than 8 bits (unlikely), that code was wrong
to begin with. As Francois Grieu points out, the values -180,
-146, and -179 are almost certainly outside the range of char.
In practice, they'll most likely be implicitly converted to 76, 110,
and 77, respectively (though that's not guaranteed by the language).
Possibly the only difference is that the older compiler might not
have warned about it.

char probably isn't the right type for the array; given the values,
and assuming you change the out-of-range values as described, it
should prboably be signed char. Or perhaps unsigned char would
make more sense; then you should change all the negative values as
well (add 256 to each of them). It depends very much on what it's
being used for. (Arrays of unsigned char are usually the best way
to represent arbitrary byte sequences.)

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


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.

--
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
 
Roberto Waltman
Guest
Posts: n/a
 
      07-28-2011
buck 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.
>
>Are there any utilities that examine old C code and suggest how to
>make it compliant with current compilers? I tried splint ...


I would recommend Gimpel's PC-Lint (
http://www.gimpel.com/html/index.htm ), but to really take advantage
of it you need a level of knowledge that, from your post, you do not
have.

You could create a Visual Studio or Eclipse project based on the
sources you have, and start modifying the code until it compiles
cleanly with whatever options you choose.
Even if it does not run, the navigation, search, code completion, etc.
features of these environments can save you some time and effort.

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


Don't know, probably not. But, why do you want to preserve the ASM
code? Why was there any ASM code to begin with?
Probable reasons:
a) To interface with libraries with different calling conventions
(FORTRAN, Pascal)
b) To access system calls that were not available via the language's
run time library.
c) To directly access hardware.
d) For speed.
f) The ASM code already existed, and was being reused.

Those reasons probably are not relevant today. You may be better off
rewriting the ASM code in C instead of porting it to a 64 bit
environment.

> I type 'debug' in a CMD
>prompt in Vista in order to see the register names, but (of course)
>Vista has no DEBUG...


There isn't a DEBUG program as in the good old MS-DOS days, but Visual
Studio comes with a symbolic debugger so much powerful than DEBUG that
any comparison is meaningless. Also check Hewart and Pravat "Advanced
Windows Debugging"

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


I agree with Jacob Navia's suggestion to farm out the job to somebody
with current experience.
--
Roberto Waltman

[ Please reply to the group.
Return address is invalid ]
 
Reply With Quote
 
buck
Guest
Posts: n/a
 
      07-28-2011
jacob navia <(E-Mail Removed)> wrote in news:j0sdco$6lr$1
@speranza.aioe.org:

> Le 28/07/11 21:04, buck a écrit :
>> Are there any utilities that examine 8086 ASM code and explain what

to
>> change to make it compile for a 64-bit CPU?

>
>
> From this question I understand that you have really no clue...
>
>


Correct. I thought I said that
--
buck
 
Reply With Quote
 
Roberto Waltman
Guest
Posts: n/a
 
      07-28-2011
Roberto Waltman wrote:
>...
>There isn't a DEBUG program as in the good old MS-DOS days, but Visual
>Studio comes with a symbolic debugger ...


Check "Download and Install Debugging Tools for Windows"
http://msdn.microsoft.com/en-us/wind...dware/gg463009

--
Roberto Waltman

[ Please reply to the group.
Return address is invalid ]
 
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