Discussion:
SCO OpenServer 5.0.7 compiler
(too old to reply)
donr
2005-01-10 16:10:44 UTC
Permalink
Hi all,
I am migrating an application for SCO Xenix to SCO OpenServer 5.0.7.
There are some modules that have funcions in the form:

extern f(short, char[], char[]);
.
.
.
extern f(a, b, c)
short a;
char b[];
char c[];
{
}

Without the prototype, the compiler is happy. With the prototype, I
would get the warning:

type does not match prototype: a

I would get this warning for any object that is not or would not be
(i.e. pointers) the size of an int. What is the compiler trying to tell
me? If I compile this on a Sun compiler with its default -t option, I
get a similar warning and also that the old style declaration short is
being promoted to int. The Sun compiler displays the warning but I
don't think it actually does the promotion with this option. Is the SCO
compiler doing the promotion and that's why the warning?

If it's doing the promotion, what happens when this function is called
in another module with these types, especially in the case where there
is no prototype in this module? Does it push the data types specified
and pop ints? This would create some interesting behavior. Did pre-ansi
C push and pop ints? It seems protoypes were used in the defining
module if the function is called within this module and defined after
the calls. If it was defined first or not called in the defining
module, there is no prototype in the module.

I can fix it by doing the ansi format. However, an older version of
Informix is used in some places and esql doesn't like the ansi format.
So I have a bit of a catch 22. I am investagating a newer version of
Informix through informix.com but haven't yet gotten a response. Does
anyone know if there is a version for this O/S? I would think there
would be.

Thanks for input and help.
Don
Bela Lubkin
2005-01-10 23:55:23 UTC
Permalink
Post by donr
I am migrating an application for SCO Xenix to SCO OpenServer 5.0.7.
extern f(short, char[], char[]);
.
.
.
extern f(a, b, c)
short a;
char b[];
char c[];
{
}
Without the prototype, the compiler is happy. With the prototype, I
type does not match prototype: a
I would get this warning for any object that is not or would not be
(i.e. pointers) the size of an int. What is the compiler trying to tell
me? If I compile this on a Sun compiler with its default -t option, I
get a similar warning and also that the old style declaration short is
being promoted to int. The Sun compiler displays the warning but I
don't think it actually does the promotion with this option. Is the SCO
compiler doing the promotion and that's why the warning?
Yes, that's why the warning.

The ANSI-style prototype defines a function whose first parameter is a
`short'. On some systems, the calling convention would cause an actual
16-bit short to be pushed on the stack for that parameter. The
K&R-style prototype, on the other hand, defines a function whose first
parameter is _stored_ as a type `int', but _operated on_ as a type
`short'. That is, K&R rules explicitly require the promotion of
less-than-`int' int types to `int' in the calling convention.

This distinction has no effect on Intel x86 architectures, where stack
operations are almost always done in 32-bit increments. In other words:
the x86 calling convention does not take advantage of the ANSI prototype
granting the compiler permission to push only 16 bits for `short'.

On some other architectures, where stack operations are doine in 16-bit
or smaller increments, the above declaration and definition would
actually be in conflict, and your program would fail.

Thus, in effect, the warning means: "this code is going to work right
now, but you have a potential _outward bound_ portability problem".

A lot of open source code provokes these warnings; this implies that
almost all modern architectures do not take advantage. If you were
porting to, say, a PDP-11, 6809 or 65C816, your code would actually
break.
Post by donr
If it's doing the promotion, what happens when this function is called
in another module with these types, especially in the case where there
is no prototype in this module? Does it push the data types specified
and pop ints? This would create some interesting behavior. Did pre-ansi
C push and pop ints? It seems protoypes were used in the defining
module if the function is called within this module and defined after
the calls. If it was defined first or not called in the defining
module, there is no prototype in the module.
Exactly. Pre-ANSI C requires the calling convention to promote all
smaller `int' types to `int'. x86 architecture encourages compilers to
do this _even_ in the ANSI C case where it isn't _required_. All x86
compilers that I've investigated in sufficient detail do in fact promote
shorter types to `int', whether or not an ANSI prototype gave them
permission not to do so.

So as far as that goes, the warning can be ignored.
Post by donr
I can fix it by doing the ansi format. However, an older version of
Informix is used in some places and esql doesn't like the ansi format.
So I have a bit of a catch 22. I am investagating a newer version of
Informix through informix.com but haven't yet gotten a response. Does
anyone know if there is a version for this O/S? I would think there
would be.
You could try bracketing with e.g.

#if defined(__STDC__)
extern f(short, char[], char[]);
#else
extern f(a, b, c);
#endif

Hopefully "esql" doesn't define __STDC__ while not supporting ANSI
prototypes...
Post by donr
Bela<
donr
2005-01-11 14:49:46 UTC
Permalink
Thanks for the input. I had tried it with the gnu compiler and don't
get the warning. Maybe it's doing the promotion and not warning? I'm
not planning on this going to another processor so I should be good.
Don
Post by Bela Lubkin
Post by donr
I am migrating an application for SCO Xenix to SCO OpenServer 5.0.7.
extern f(short, char[], char[]);
.
.
.
extern f(a, b, c)
short a;
char b[];
char c[];
{
}
Without the prototype, the compiler is happy. With the prototype, I
type does not match prototype: a
I would get this warning for any object that is not or would not be
(i.e. pointers) the size of an int. What is the compiler trying to tell
me? If I compile this on a Sun compiler with its default -t option, I
get a similar warning and also that the old style declaration short is
being promoted to int. The Sun compiler displays the warning but I
don't think it actually does the promotion with this option. Is the SCO
compiler doing the promotion and that's why the warning?
Yes, that's why the warning.
The ANSI-style prototype defines a function whose first parameter is a
`short'. On some systems, the calling convention would cause an actual
16-bit short to be pushed on the stack for that parameter. The
K&R-style prototype, on the other hand, defines a function whose first
parameter is _stored_ as a type `int', but _operated on_ as a type
`short'. That is, K&R rules explicitly require the promotion of
less-than-`int' int types to `int' in the calling convention.
This distinction has no effect on Intel x86 architectures, where stack
the x86 calling convention does not take advantage of the ANSI
prototype
Post by Bela Lubkin
granting the compiler permission to push only 16 bits for `short'.
On some other architectures, where stack operations are doine in 16-bit
or smaller increments, the above declaration and definition would
actually be in conflict, and your program would fail.
Thus, in effect, the warning means: "this code is going to work right
now, but you have a potential _outward bound_ portability problem".
A lot of open source code provokes these warnings; this implies that
almost all modern architectures do not take advantage. If you were
porting to, say, a PDP-11, 6809 or 65C816, your code would actually
break.
Post by donr
If it's doing the promotion, what happens when this function is called
in another module with these types, especially in the case where there
is no prototype in this module? Does it push the data types
specified
Post by Bela Lubkin
Post by donr
and pop ints? This would create some interesting behavior. Did pre-ansi
C push and pop ints? It seems protoypes were used in the defining
module if the function is called within this module and defined after
the calls. If it was defined first or not called in the defining
module, there is no prototype in the module.
Exactly. Pre-ANSI C requires the calling convention to promote all
smaller `int' types to `int'. x86 architecture encourages compilers to
do this _even_ in the ANSI C case where it isn't _required_. All x86
compilers that I've investigated in sufficient detail do in fact promote
shorter types to `int', whether or not an ANSI prototype gave them
permission not to do so.
So as far as that goes, the warning can be ignored.
Post by donr
I can fix it by doing the ansi format. However, an older version of
Informix is used in some places and esql doesn't like the ansi format.
So I have a bit of a catch 22. I am investagating a newer version of
Informix through informix.com but haven't yet gotten a response. Does
anyone know if there is a version for this O/S? I would think there
would be.
You could try bracketing with e.g.
#if defined(__STDC__)
extern f(short, char[], char[]);
#else
extern f(a, b, c);
#endif
Hopefully "esql" doesn't define __STDC__ while not supporting ANSI
prototypes...
Post by donr
Bela<
Loading...