Question about compiler behavior

Question about compiler behavior

Post by Jon Richar » Wed, 10 Aug 1994 09:22:29



Solaris 2.3, cc: SC3.0 15 Dec 1993

What's the rationale behind the following compiler behavior?

Given the following C file..
-----------------------------------------------------------------
extern int foo(short n);

int
foo(n)
    short n;
{
    return 0;

Quote:}

main() {}
-----------------------------------------------------------------

You get the follow warnings when compiling with -Xa:

"foo.c", line 5: warning: identifier redeclared: foo
        current : function() returning int
        previous: function(short) returning int : "foo.c", line 1
"foo.c", line 6: warning: Prototype mismatch in arg 1 for function foo:
        function : old style declaration short promoted to int
        prototype: short

Here's the explanation from the Answerbook:

    For compatability reasons, foo's arguments must be promoted
    according to the default argument promotions, which is how they
    were promoted before the existence of function prototypes.
    Therefore, the value that must be passed to foo is an int although
    the function will only use the char [short in my example] part
    of the value.

This explanation still leaves me confused as to why the compiler
behaves this way.  Can someone explain in more detail what
compatability reasons justify this compiler behavior?

-Jon

 
 
 

Question about compiler behavior

Post by Neil Ricke » Wed, 10 Aug 1994 13:38:05



>Solaris 2.3, cc: SC3.0 15 Dec 1993
>What's the rationale behind the following compiler behavior?
>Given the following C file..
>-----------------------------------------------------------------
>extern int foo(short n);

This is the new style declaration.  Since n is declared short, it is
assumed to occupy two bytes of stack space.

Quote:>int
>foo(n)
>    short n;
>{
>    return 0;
>}

This is the old style initialization.  In the old style (K&R) of C,
any integer type parameter (char, short, int) was passed as int,
and any float was passed as double.  The argument to a function call
was silently coerced to the default size.  That means that 4 bytes
of stack space are assumed for the argument.

 What it amounts to, is that you can use:

        extern int foo(short n);

  together with

        int foo(short n) { return 0;}

or you can use

        extern int foo()

  together with

        int foo(n) short n; { return 0; }

but you cannot mix and match.  Since one form assumes a 2-byte
parameter, and the other assumes a 4-byte parameter, you cannot
ignore the compiler warning for this.

 
 
 

Question about compiler behavior

Post by Doug Gwyn (ACISD/MC » Thu, 18 Aug 1994 01:29:45



>What's the rationale behind the following compiler behavior?
>extern int foo(short n);
>int
>foo(n)
>    short n;
>{
>    return 0;
>}
>main() {}
>"foo.c", line 5: warning: identifier redeclared: foo
>        current : function() returning int
>        previous: function(short) returning int : "foo.c", line 1
>"foo.c", line 6: warning: Prototype mismatch in arg 1 for function foo:
>        function : old style declaration short promoted to int
>        prototype: short

It's what the C standard requires, or at least permits of an implementation.
The prototype declaration says that the argument is passed as a short
but the old-style definition says it is passed as an int (*then* converted
to a short internal to foo).  In general, different linkage might be used
for the two cases.

Quote:>Here's the explanation from the Answerbook:
>    For compatability reasons, foo's arguments must be promoted
>    according to the default argument promotions, which is how they
>    were promoted before the existence of function prototypes.
>    Therefore, the value that must be passed to foo is an int although
>    the function will only use the char [short in my example] part
>    of the value.

That applies just to the definition of foo().  In the prototype
declaration, the argument need not be passed as int.  Probably it
*will* be in most implementations, to reduce the likelihood of
breaking code written by people who never used to worry about these
things.
 
 
 

1. Strange behaviour with gcc as C++ compiler

Hi linuxers!

  I reinstalled linux from scratch last week, using the SLS distribution, and
I'm experiencing strange results when compiling a C++ program, which uses the
iostream library. The program compiles fine (yes, I link it with libg++), but
exits without running. The really strange part is that when I run it under gdb,
it works fine.
  I tried linking with the -nojump and -static options, and even directly with
the /usr/lib/libg++ library, to no avail. I do no think the problem is specific
to SLS or gcc because it runs fine on a Sun SparcStation wiith gcc, and it
showed the same problem before I reinstalled with SLS.
  My current configuration is a 486/33, 16M RAM, 0.98.1 kernel with math
emulation turned off, and I am using gcc 2.2.2d.
  Is the problem due to the 2.2.2d libraries, and should I then install 2.3.1
instead, or is there just a configuration problem ?

  Please reply by E-mail, so as to reduce clutter on this overworked newsgroup,
and thanks in advance.

-- Fazal Majid

--
Fazal MAJID                     |      /\    /\    /\    0-  Sarff, the serpent


2. setld shows packages but also says they are not installed etc...

3. Strange Behavior With Solaris (Sparc) C Compiler

4. gcc errors

5. Strange compiler behaviour with g77 and SMP

6. mpg321 as init.d deamon?

7. : Weird ">" redirect behavior vs. ">>" redirect behavior

8. makefile question

9. hp-ux C compiler flags vs hp-aix C compiler flags

10. Are sun studio C/C++ compilers and Forte C/C++ compilers same ??

11. Compiler compilers

12. Installing a compiler on a Lixux system with an existing compiler?

13. Linux compilers vs. Windows compilers