Compile Errors

[Technoid]

I'm working on a legacy test platform with a compiler that expects K&R
style C (as opposed to ANSI). How does this affect the required syntax
for my code? Would it affect syntax for function prototypes?

When I attempt to make or compile my C code, the compiler complains
about the syntax of the function prototypes, even though the syntax is
correct.

Example syntax:

void function_name(void);

If the issue is not with the compiler, what else could be causing the
compile error?

Thanks!

 

[Walter Roberson]

I'm working on a legacy test platform with a compiler that expects K&R
style C (as opposed to ANSI). How does this affect the required syntax
for my code? Would it affect syntax for function prototypes?

Yes, definitely. K&R's prototypes are quite different.

When I attempt to make or compile my C code, the compiler complains
about the syntax of the function prototypes, even though the syntax is
correct.

Example syntax:

void function_name(void);

void is not part of K&R C.

If the issue is not with the compiler, what else could be causing the
compile error?

That you are trying to use features that did not exist when that
compiler was created.

 

[Chris Torek]

Yes, definitely. K&R's prototypes are quite different.

More specifically, K&R C lacks prototypes entirely.

void is not part of K&R C.

It was, however, a very common extension.

Prototypes (and other things that are liable to crop up here) have
been standard for over 15 years now. The OP did say "legacy test
platform", but sometimes legacy is too painful even to contemplate.
Still, here are some tricks.

The "void problem" can be worked-around easily:

#define void int

The next step might be to revert to a technique commonly used many
years ago, back when prototypes were new:

#ifdef __STDC__
#define P(x) x
#else
#define P(x) ()
#endif

double somefunc P((char *, double *));

Now the prototype portion of a declaration vanishes when needed
(not __STDC__) but remains when possible (__STDC__). (One might
tweak the #ifdef, since some non-standard compilers still had
prototype support, back then.)

You can also handle "const" by #defining it away:

#define const /*nothing*/

and likewise for "volatile". A few tricks like this, plus a modest
amount of source-code discipline, can produce code that compiles
correctly with a K&R compiler, yet still uses prototypes on modern
systems.

 

[Keith Thompson]

I'm working on a legacy test platform with a compiler that expects K&R
style C (as opposed to ANSI). How does this affect the required syntax
for my code? Would it affect syntax for function prototypes?

When I attempt to make or compile my C code, the compiler complains
about the syntax of the function prototypes, even though the syntax is
correct.

Example syntax:

void function_name(void);

If the issue is not with the compiler, what else could be causing the
compile error?

K&R C didn't have prototypes. It also didn't have the "void" keyword.

K&R defines the K&R version of the language. More specifically,
Kernighan & Ritchie, _The C Programming Language_, First Edition (the
second edition covers the ANSI/ISO standard, C89/C90). Copies should
still be available, at least used.

There's a tool called "ansi2knr" that attempts to translate ANSI C
code to K&R-compatible code (removing prototypes, etc.). It probably
doesn't do a perfect job.

 

[Keith Thompson]

K&R C didn't have prototypes. It also didn't have the "void" keyword.

K&R defines the K&R version of the language. More specifically,
Kernighan & Ritchie, _The C Programming Language_, First Edition (the
second edition covers the ANSI/ISO standard, C89/C90). Copies should

One more thing: K&R1 was published shortly before the "enum" keyword
was added to the language, but most pre-ANSI compilers support "enum".
Chris says "void" was a common extension; I didn't know that, but I'll
take his word for it. But the only really relevant question is what's
supported by the particular antediluvian compiler you're being forced
to support.

(You should seriously consider the possibility that this whole
exercise is a waste of time. I don't know of any significant systems
that don't have at least a C89/C90 compiler. If you have an old
system with a K&R compiler, you can probably use it to bootstrap gcc,
though probably not the latest version.)

There's a tool called "ansi2knr" that attempts to translate ANSI C
code to K&R-compatible code (removing prototypes, etc.). It probably
doesn't do a perfect job.

And because of this, you might need to tweak your ANSI-compatible code
in some minor ways so that (a) ansi2knr doesn't choke on it, and (b)
your legacy compiler doesn't choke on the output of ansi2nkr. Such
tweaks are likely, but not certain, to be less intrusive than using
#ifdefs to make all your prototypes and "void"s conditional on
__STDC__.

Argument promotion, I think, is something that ansi2nkr doesn't handle
very well. The K&R code:

int foo(c)
char c;
{ /* ... */ }

isn't actually equivalent to this:

int foo(char c)
{ /* ... */ }

it's closer to this:

int foo(int c)
{ /* ... */ }

This kind of thing can cause subtle errors if you're not *very*
careful.

 

[Rod Pemberton]

I'm working on a legacy test platform with a compiler that expects K&R
style C (as opposed to ANSI). How does this affect the required syntax
for my code? Would it affect syntax for function prototypes?

I think others convered the function prototype question. So the question is
how early a version of K&R?

A) Early K&R twenty-five keywords:
#define #include auto break case char continue
default do double else entry extern float for
goto if int register return sizeof static
struct switch while

B) Early K&R, ten operators written in reverse when compared to modern C:
=>> =>> =+ =- =* =/ =% =& =^ =|

C) Other operators and structural elements:[ ] . & ! ~ - + * / % < > ^ | ?



Rod Pemberton

 

[Keith Thompson]

I think others convered the function prototype question. So the question is
how early a version of K&R?

A) Early K&R twenty-five keywords:
#define #include auto break case char continue
default do double else entry extern float for
goto if int register return sizeof static
struct switch while

I don't think #define and #include were ever considered keywords.

B) Early K&R, ten operators written in reverse when compared to modern C:
=>> =>> =+ =- =* =/ =% =& =^ =|

Early versions of C used "=-" rather than "-=". Since K&R1 (the book)
uses the modern "-=" form, I'd refer to such versions of the language
as pre-K&R. (I think the book mentions the older forms in passing.)

 

[Mark McIntyre]

I'm working on a legacy test platform with a compiler that expects K&R
style C (as opposed to ANSI). How does this affect the required syntax
for my code? Would it affect syntax for function prototypes?

Very much so, since K&R C doesn't allow prototypes AFAIR. You can have
declarations tho.

When I attempt to make or compile my C code, the compiler complains
about the syntax of the function prototypes, even though the syntax is
correct.

Example syntax:

void function_name(void);

This isn't valid pre-ANSI C. You need to remove the void, and any
other parameters, from the prototype to turn it into a plain old
declaration.
Mark McIntyre

 

[Jordan Abel]

A few tricks like this, plus a modest amount of source-code
discipline, can produce code that compiles correctly with a K&R
compiler, yet still uses prototypes on modern systems.

Also, watch out for narrow types - you will of course have to code using
"old-style" function definitions [macros to conditionally use old or new
style aren't really worth it]


int foo(x,y) char x; float y; {
...
}

needs the prototype

int foo P((int x, double y))