Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: K&R function definition with typedef parameter names
Date: Sat, 11 Jan 2020 09:56:40 -0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <86tv5127xj.fsf@linuxsc.com>
References: <qurl9m$b69$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="a658bb27d1b88b897660621da5fe7a9e"; logging-data="30932"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5LLaXSMGlxkK7DsleUh/ntBA6jGA++E0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:prri+3K17J+29oUjMObq1WaxKUE= sha1:NjYMcJNZlIRSBfD/l9yzAOA/jzQ=
Xref: csiph.com comp.lang.c:148938

Steve Keller <keller@no.invalid> writes:

> I wonder if the old K&R style function definition allowed to use
> function parameter names that were already typedef'd.  Current
> compilers like gcc, clang, and tcc don't allow this:
>
>     typedef int t;
>     int fun(t)
>         int t;
>     {
>         return 0;
>     }
>
> The compilers I tested on this seem to interpret "int fun(t)" as a
> function declaration of fun that takes one argument of type t.  I
> don't have any pre C90 compiler available but would like to know how
> this would be handled.  If the above was possible in old pre-ANSI C
> this seems to have changed.  Was it intentionally and is it stated
> explicitely anywhere?

I think you've already gotten an answer to the second part of
your question.

On the first part -- without having any data to offer, what I
suspect is true is that some pre-standard compilers did one
thing and other pre-standard compilers did something else.  In
other words the field was not homogeneous, and the decision was
not to make a "change" but to decide what should be done for
standardized C.

The Rationale document is pretty good about calling out changes
in standard C relative to what was done in pre-standard C.  The
Rationale says nothing about the standard C rule being a change
over earlier C compilers.  That isn't absolutely compelling
evidence, but it is some evidence that pre-standard compilers
didn't all behave the same way for this scenario.