[9fans] 8c's feature or bug? - Plan9

This is a discussion on [9fans] 8c's feature or bug? - Plan9 ; Hi all, Is this a feature or bug of 8c? Look at this: term% cat t.c #include #include #define ARGS(list) list void foo ARGS((char)); void foo1 ARGS((int)); void main(void) { foo('s'); foo1(1); exits(nil); } void foo (b) char b; { ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [9fans] 8c's feature or bug?

  1. [9fans] 8c's feature or bug?

    Hi all,

    Is this a feature or bug of 8c? Look at this:

    term% cat t.c
    #include
    #include

    #define ARGS(list) list

    void foo ARGS((char));
    void foo1 ARGS((int));

    void main(void)
    {
    foo('s');
    foo1(1);
    exits(nil);
    }

    void foo (b)
    char b;
    {
    }

    void foo1 (b)
    int b;
    {
    }

    term% 8c -FVw t.c
    t.c:17 function inconsistently declared: foo
    warning: t.c:17 param declared and not used: b
    warning: t.c:22 param declared and not used: b

    My question is: Why I get the "function inconsistently declared" error?
    or Why I'm not get the same error about foo1?

    Lee

  2. Re: [9fans] 8c's feature or bug?

    you're mixing ANSI prototypes and the original style, and
    in
    void f(b)
    char b;

    i suspect b is promoted to int, because before prototypes C compilers
    didn't know an argument was a char at point of call, and chars were promoted to int (similarly float to double),
    and the function with the argument so promoted clashes with the earlier void f(char).

    in any case, if you're going to use 8c at all, just commit to ANSI prototypes.
    in fact, even if you're not going to use 8c, just use ANSI prototypes and either way,
    avoid or eliminate the ARGS crud.

    surely it must be at least 20 years old.

    if the code is imported i suppose it doesn't matter, but if it's new code,
    using ARGS or __PROTO or whatever is usually just silly.


  3. Re: [9fans] 8c's feature or bug?

    On Thu, Feb 08, 2007 at 05:33:32PM +0000, Charles Forsyth wrote:
    > you're mixing ANSI prototypes and the original style, and
    > in
    > void f(b)
    > char b;
    >
    > i suspect b is promoted to int, because before prototypes C compilers
    > didn't know an argument was a char at point of call, and chars were promoted to int (similarly float to double),
    > and the function with the argument so promoted clashes with the earlier void f(char).
    >


    I give prototypes of foo and foo1 before use and define them, maybe 8c
    just ignore these prototypes when it see the definitions.

    > in any case, if you're going to use 8c at all, just commit to ANSI prototypes.
    > in fact, even if you're not going to use 8c, just use ANSI prototypes and either way,
    > avoid or eliminate the ARGS crud.
    >
    > surely it must be at least 20 years old.
    >
    > if the code is imported i suppose it doesn't matter, but if it's new code,
    > using ARGS or __PROTO or whatever is usually just silly.


    It's old code, anyway.

    Lee

  4. Re: [9fans] 8c's feature or bug?

    > I give prototypes of foo and foo1 before use and define them, maybe 8c
    > just ignore these prototypes when it see the definitions.


    What Charles said is right:

    void foo(b) char b; { }
    void foo(int b);

    produces no warnings, but

    void foo(b) char b; { }
    void foo(char b);

    does.

    Russ

  5. Re: [9fans] 8c's feature or bug?

    > I give prototypes of foo and foo1 before use and define them, maybe 8c
    > just ignore these prototypes when it see the definitions.


    the prototypes are fine, but that one doesn't agree with the actual definition
    because the rules require the old style declaration
    void f(b)
    char b;
    {}
    to be treated as if it were
    void f(b)
    int b;
    {}
    whereas
    void f(char b)
    {}
    would be compatible with a prototype
    void f(char);

    the diagnostic appears because it doesn't ignore the prototype
    (if it ignored it, all would be fine) but is obliged to check it against the
    actual definition which, according to the historical rules for that style of declaration,
    does not match.

    if you find that all a little confusing, that's all the more reason to avoid the old style completely!

    for old code that i control, i invariably take the opportunity to update it.
    8c -w ... sometimes finds other problems in old code.


  6. Re: [9fans] 8c's feature or bug?

    On Thu, Feb 08, 2007 at 06:48:48PM +0000, Charles Forsyth wrote:
    > > I give prototypes of foo and foo1 before use and define them, maybe 8c
    > > just ignore these prototypes when it see the definitions.

    >
    > the prototypes are fine, but that one doesn't agree with the actual definition
    > because the rules require the old style declaration
    > void f(b)
    > char b;
    > {}
    > to be treated as if it were
    > void f(b)
    > int b;
    > {}
    > whereas
    > void f(char b)
    > {}
    > would be compatible with a prototype
    > void f(char);
    >
    > the diagnostic appears because it doesn't ignore the prototype
    > (if it ignored it, all would be fine) but is obliged to check it against the
    > actual definition which, according to the historical rules for that style of declaration,
    > does not match.
    >

    I see now, thank you.

    > if you find that all a little confusing, that's all the more reason to avoid the old style completely!
    >
    > for old code that i control, i invariably take the opportunity to update it.


    I can't control these codes.

    > 8c -w ... sometimes finds other problems in old code.
    >


    Yes, -w is very helpful.

    Lee

+ Reply to Thread