Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #148786 > unrolled thread

K&R function definition with typedef parameter names

Back to article view | Back to comp.lang.c

Contents

  K&R function definition with typedef parameter names Steve Keller <keller@no.invalid> - 2020-01-04 19:31 -0800
    Re: K&R function definition with typedef parameter names Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 04:00 +0000
      Re: K&R function definition with typedef parameter names Steve Keller <keller@no.invalid> - 2020-01-09 06:26 -0800
    Re: K&R function definition with typedef parameter names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-04 23:15 -0500
      Re: K&R function definition with typedef parameter names Steve Keller <keller@no.invalid> - 2020-01-09 06:27 -0800
    Re: K&R function definition with typedef parameter names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 06:47 +0100
      Re: K&R function definition with typedef parameter names Steve Keller <keller@no.invalid> - 2020-01-09 06:25 -0800
        Re: K&R function definition with typedef parameter names Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-09 16:22 +0100
          Re: K&R function definition with typedef parameter names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-09 08:20 -0800
            Re: K&R function definition with typedef parameter names Thiago Adams <thiago.adams@gmail.com> - 2020-01-09 10:49 -0800
              Re: K&R function definition with typedef parameter names David Brown <david.brown@hesbynett.no> - 2020-01-10 10:22 +0100
                Re: K&R function definition with typedef parameter names Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 13:05 +0000
                  Re: K&R function definition with typedef parameter names David Brown <david.brown@hesbynett.no> - 2020-01-10 16:14 +0100
                    Re: K&R function definition with typedef parameter names Richard Damon <Richard@Damon-Family.org> - 2020-01-10 11:15 -0500
                      Re: K&R function definition with typedef parameter names James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-10 20:51 -0500
                Re: K&R function definition with typedef parameter names Thiago Adams <thiago.adams@gmail.com> - 2020-01-10 06:24 -0800
                  Re: K&R function definition with typedef parameter names David Brown <david.brown@hesbynett.no> - 2020-01-10 16:26 +0100
            Re: K&R function definition with typedef parameter names Nick Bowler <nbowler@draconx.ca> - 2020-01-13 22:12 +0000
    Re: K&R function definition with typedef parameter names Autist <autist69@gmail.com> - 2020-01-10 16:42 +0100
    Re: K&R function definition with typedef parameter names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 09:56 -0800

#148786 — K&R function definition with typedef parameter names

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?

Steve

[toc] | [next] | [standalone]

#148787

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.

At least one pre-ANSI C compiler (pcc) accepts this code.

> Was it intentionally and is it stated
> explicitely anywhere?

ANSI C includes the wording:

  "An identifier declared as a typedef name shall not be redeclared as a
  parameter."

in 3.7.1.  The corresponding text in the reference manual at the end of
K&R1 is missing, so I think this was a deliberate change designed to
facilitate parsing of new-style function declarations and definitions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148882

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Steve Keller <keller@no.invalid> writes:
> 
> >     typedef int t;
> >     int fun(t)
> >         int t;
> >     {
> >         return 0;
> >     }
> 
> At least one pre-ANSI C compiler (pcc) accepts this code.

OK, that's interesting and it is what I have assumed.

> ANSI C includes the wording:
> 
>   "An identifier declared as a typedef name shall not be redeclared as a
>   parameter."
> 
> in 3.7.1.  The corresponding text in the reference manual at the end of
> K&R1 is missing, so I think this was a deliberate change designed to
> facilitate parsing of new-style function declarations and definitions.

Ok, I've found this also in ISO C 9899 in 6.9.1 and it covers only
old-style function definitions.  Therefore, to convert such code to
the current standard you may write

    typedef int t;
    int fun(int t)
    {
        return 0;
    }

and all compilers I have do accept this.

Steve

[toc] | [prev] | [next] | [standalone]

#148788

On 1/4/20 10:31 PM, Steve Keller wrote:
> 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)

In K&R C, t could not be a type, it could only be the identifier for a
function parameter, so the issue never came up.

In standard C, when function prototypes were added, the ambiguity you've
run into became an issue. The committee produced a rule to deal with
such cases: "If, in a parameter declaration, an identifier can be
treated either as a typedef name or as a parameter name, it shall be
taken as a typedef name."  (6.7. 5.3p10).

They had to deal with the ambiguity some way, and if they had made the
opposite choice, to always resolve the ambiguity in favor of it being a
parameter name, it would not have been possible to use a typedef name to
declare a parameter of that type in a function prototype.

[toc] | [prev] | [next] | [standalone]

#148883

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> >     typedef int t;
> >     int fun(t)
> 
> In K&R C, t could not be a type, it could only be the identifier for a
> function parameter, so the issue never came up.

Yes, that's what I have assumed and what causes the difference between
K&R and standard C.

> In standard C, when function prototypes were added, the ambiguity you've
> run into became an issue. The committee produced a rule to deal with
> such cases: "If, in a parameter declaration, an identifier can be
> treated either as a typedef name or as a parameter name, it shall be
> taken as a typedef name."  (6.7. 5.3p10).
> 
> They had to deal with the ambiguity some way, and if they had made the
> opposite choice, to always resolve the ambiguity in favor of it being a
> parameter name, it would not have been possible to use a typedef name to
> declare a parameter of that type in a function prototype.

Yes, and the only alternative would be completely unacceptable,
i.e. to lookahead or shift tokens until the end of the function
declarator just to see if the following token is a ';' (making it a
function declaration and the 't' a typedef-name) or if the following
token is a type-name (making it an old-style function definition and
the 't' an identifier).

Steve

[toc] | [prev] | [next] | [standalone]

#148789

> 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;
>      }

There's no necessity to use this.

[toc] | [prev] | [next] | [standalone]

#148881

Bonita Montero <Bonita.Montero@gmail.com> writes:

> There's no necessity to use this.

But there is necessity to parse this correctly.

Steve

[toc] | [prev] | [next] | [standalone]

#148884

>> There's no necessity to use this.

> But there is necessity to parse this correctly.

... to compile ancient code?

[toc] | [prev] | [next] | [standalone]

#148885

As of the latest version of the C standard,  K&R style function definitions are still permitted. A fully conforming implementation of C is therefore required to accept such code and to translate it correctly. It's free to also issue a warning, which I would strongly recommend, but it is not permitted to reject code for that reason. 
Given that this syntax is still permitted, I think it's likely that there's at least a few idiots somewhere still writing new code using that syntax. The committee would have at least deprecated the syntax a long time ago if they didn't think there were a fair number of people who still need it to be supported.

[toc] | [prev] | [next] | [standalone]

#148886

On Thursday, January 9, 2020 at 1:20:15 PM UTC-3, James Kuyper wrote:
> As of the latest version of the C standard,  K&R style function definitions are still permitted. A fully conforming implementation of C is therefore required to accept such code and to translate it correctly. It's free to also issue a warning, which I would strongly recommend, but it is not permitted to reject code for that reason. 
> Given that this syntax is still permitted, I think it's likely that there's at least a few idiots somewhere still writing new code using that syntax. The committee would have at least deprecated the syntax a long time ago if they didn't think there were a fair number of people who still need it to be supported.

I never used this syntax.
However, I can see where it can be useful.

If you are writing code from other language, for instance, 
you have your own language that the output is C,then
this feature and others like ignore function declarations,
is useful. In this case C is more like an "portable assembly"
and warnings are not necessary considering that the other
language is already making checks.

[toc] | [prev] | [next] | [standalone]

#148894

On 09/01/2020 19:49, Thiago Adams wrote:
> On Thursday, January 9, 2020 at 1:20:15 PM UTC-3, James Kuyper wrote:
>> As of the latest version of the C standard,  K&R style function definitions are still permitted. A fully conforming implementation of C is therefore required to accept such code and to translate it correctly. It's free to also issue a warning, which I would strongly recommend, but it is not permitted to reject code for that reason. 
>> Given that this syntax is still permitted, I think it's likely that there's at least a few idiots somewhere still writing new code using that syntax. The committee would have at least deprecated the syntax a long time ago if they didn't think there were a fair number of people who still need it to be supported.
> 
> I never used this syntax.
> However, I can see where it can be useful.
> 
> If you are writing code from other language, for instance, 
> you have your own language that the output is C,then
> this feature and others like ignore function declarations,
> is useful. In this case C is more like an "portable assembly"
> and warnings are not necessary considering that the other
> language is already making checks.
> 

If you are compiling from another language, using C as an intermediary
language, then there are basically two paths to take.  One is that /you/
choose the C compiler and options - in which case you can disable any
warnings, use compiler extensions and implementation-dependent features,
etc.  The other is that the user chooses the C compiler, and then you
want to generate as clean and portable code as you can, that aims to be
warning-free for any reasonable (for some definition of "reasonable")
choice of compiler, flags and warnings that the user picks.

Either way, but perhaps especially for the "language writer chooses the
compiler" way, you want to end up with the most efficient results
practical.  You generate code that gives the compiler the most knowledge
and the best opportunities for optimisation.  Skipping function
declarations, and relying on non-prototype function calls, is a sure way
to generate pointlessly poorer code.

You won't necessarily structure you code in the way a human programmer
might.  In normal C programming, it is common to put the prototype
declarations of external linkage functions in a header, which is
included by C units that use the functions and also by the one that
defines it.  In generated C code, you might skip that and directly add
function declarations of called functions at their point of use in the C
files.  That would be a maintenance nightmare for manually written code,
but absolutely fine for generated code.  There would be advantages in
avoiding (or minimising) the generation of header files - there would be
no advantage in skipping function prototypes.

And I am completely at a loss to see how K&R style function definitions
ever offer any kind of advantage over modern C function definitions with
full prototypes.  Maybe I have missed something that you are thinking
about, and you can elaborate.

[toc] | [prev] | [next] | [standalone]

#148900

David Brown <david.brown@hesbynett.no> writes:
<cut>
> And I am completely at a loss to see how K&R style function definitions
> ever offer any kind of advantage over modern C function definitions with
> full prototypes.  Maybe I have missed something that you are thinking
> about, and you can elaborate.

One possible example is with code the uses a table of heterogeneous
functions.  In C-with-prototypes the code is undefined unless the
function pointer is cast to right type at the point of call.  In K&R C,
the call is well-defined provided the (promoted) types match.

This is a rather narrow window of advantage because in a translator the
type information may well be known and the correct cast could be
generated.  None the less, it might be simpler not to.  And in
interpreted code it's impossible to cast to the right type (since C has
no run-time type values) so this looks like a big win.  However,
interpreted code often uses it's own "value type" so all the functions
could simply be declared variadic or they could take a pointer to an
array or values.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148909

On 10/01/2020 14:05, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>> And I am completely at a loss to see how K&R style function definitions
>> ever offer any kind of advantage over modern C function definitions with
>> full prototypes.  Maybe I have missed something that you are thinking
>> about, and you can elaborate.
> 
> One possible example is with code the uses a table of heterogeneous
> functions.  In C-with-prototypes the code is undefined unless the
> function pointer is cast to right type at the point of call.  In K&R C,
> the call is well-defined provided the (promoted) types match.

That would be a reason (not a good one, IMHO, but that is beside the
point - and has been discussed before) to use K&R style non-prototype
function /declarations/, but not a reason to use K&R style function
definitions.

> 
> This is a rather narrow window of advantage because in a translator the
> type information may well be known and the correct cast could be
> generated.  None the less, it might be simpler not to.  And in
> interpreted code it's impossible to cast to the right type (since C has
> no run-time type values) so this looks like a big win.  However,
> interpreted code often uses it's own "value type" so all the functions
> could simply be declared variadic or they could take a pointer to an
> array or values.
> 

[toc] | [prev] | [next] | [standalone]

#148913

On 1/10/20 10:14 AM, David Brown wrote:
> On 10/01/2020 14:05, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>> And I am completely at a loss to see how K&R style function definitions
>>> ever offer any kind of advantage over modern C function definitions with
>>> full prototypes.  Maybe I have missed something that you are thinking
>>> about, and you can elaborate.
>>
>> One possible example is with code the uses a table of heterogeneous
>> functions.  In C-with-prototypes the code is undefined unless the
>> function pointer is cast to right type at the point of call.  In K&R C,
>> the call is well-defined provided the (promoted) types match.
> 
> That would be a reason (not a good one, IMHO, but that is beside the
> point - and has been discussed before) to use K&R style non-prototype
> function /declarations/, but not a reason to use K&R style function
> definitions.
> 

But if you still need to use the non-prototype function declaration 
after you have actually defined the function, then the function 
definition needs to not provide a prototype, and thus be in the K&R style.

Admittedly, this is getting into the weeds.

[toc] | [prev] | [next] | [standalone]

#148920

On 1/10/20 11:15 AM, Richard Damon wrote:
...
> But if you still need to use the non-prototype function declaration 
> after you have actually defined the function, then the function 
> definition needs to not provide a prototype, and thus be in the K&R style.

There's no such requirement.

"If the expression that denotes the called function has a type that does
not include a prototype, the integer promotions are performed on each
argument, and arguments that have type float are promoted to double.
These are called the default argument promotions. If the number of
arguments does not equal the number of parameters, the behavior is
undefined. If the function is defined with a type that includes a
prototype, and either the prototype ends with an ellipsis (, ...) or the
types of the arguments after promotion are not compatible with the types
of the parameters, the behavior is undefined." (6.5.2.2p6).

Notice that if you avoid all three of the problems list (the number of
arguments doesn't match the number of parameters, the prototype ends in
..., or promoted argument types that are incompatible with corresponding
parameter type), there's no problem with such a function call.

[toc] | [prev] | [next] | [standalone]

#148908

On Friday, January 10, 2020 at 6:22:22 AM UTC-3, David Brown wrote:
[...]
> And I am completely at a loss to see how K&R style function definitions
> ever offer any kind of advantage over modern C function definitions with
> full prototypes.  Maybe I have missed something that you are thinking
> about, and you can elaborate.

I was not aware of this performance problem.

This is the situation I have in mind:

Let's say I decide to implement the C++ operator delete
in my transpirer cprime (that generates C code)


struct X * p = ...;

delete p;

In this case I have to transform 'delete p' in a function call
or make it inline.

If I use some kind of name mangling, let's say 'X_delete',
I could just output without any declaration:

X_delete(p);

One alternative, like you suggest, is to output in the 
line above the declaration

void X_delete(struct X* p);
X_delete(p);

the 'problem' Is when the same function is used many
times. In this case, for better readability, I could add
just one. (count the number of declarations generated)

void X_delete(struct X* p);
X_delete(p1);
X_delete(p2);

[toc] | [prev] | [next] | [standalone]

#148910

On 10/01/2020 15:24, Thiago Adams wrote:
> On Friday, January 10, 2020 at 6:22:22 AM UTC-3, David Brown wrote:
> [...]
>> And I am completely at a loss to see how K&R style function definitions
>> ever offer any kind of advantage over modern C function definitions with
>> full prototypes.  Maybe I have missed something that you are thinking
>> about, and you can elaborate.
> 
> I was not aware of this performance problem.
> 

To be fair, the performance issues will depend highly on the target
system - it could quickly be high on the systems I tend to use, but
perhaps insignificant on PC's.

When you don't have prototypes, the compiler must promote arguments to
default types.  That means if you are using floats, the values are
promoted to doubles.  This would be a killer on small devices (which
don't have hardware double support), and even on big systems you are
just wasting cycles and effort.

But the general point is that the less information the compiler has, the
more pessimistic it must be in code generation.

> This is the situation I have in mind:
> 
> Let's say I decide to implement the C++ operator delete
> in my transpirer cprime (that generates C code)
> 
> 
> struct X * p = ...;
> 
> delete p;
> 
> In this case I have to transform 'delete p' in a function call
> or make it inline.
> 
> If I use some kind of name mangling, let's say 'X_delete',
> I could just output without any declaration:
> 
> X_delete(p);
> 
> One alternative, like you suggest, is to output in the 
> line above the declaration
> 
> void X_delete(struct X* p);
> X_delete(p);
> 
> the 'problem' Is when the same function is used many
> times. In this case, for better readability, I could add
> just one. (count the number of declarations generated)
> 
> void X_delete(struct X* p);
> X_delete(p1);
> X_delete(p2);
> 
> 

Exactly.  Generate it once (either just the declaration, or an inline
definition).

There is a lot that is hard in making a language translator or a C code
generator.  This is not one of those points - it is simple.  There is
nothing to be gained (other than saving you a little effort) from /not/
having proper prototyped function declarations here - and there might be
benefits in having them declared.  There are certainly big benefits to
human readability when looking at the code.

However, the title of this thread is K&R function /definitions/, not
/declarations/.

[toc] | [prev] | [next] | [standalone]

#149057

On Thu, 09 Jan 2020 08:20:04 -0800, James Kuyper wrote:
> Given that this syntax is still permitted, I think it's likely that
> there's at least a few idiots somewhere still writing new code using
> that syntax. The committee would have at least deprecated the syntax a
> long time ago if they didn't think there were a fair number of people
> who still need it to be supported.

"Idiot" is a bit harsh...  There are actually functions one may
quite reasonably want to write in C that are only possible to
write with old-style definition syntax.

Consider the following:

  void hello(int(*)[*], int);
  void hello(a, n)
     int n;
     int (*a)[n];
  {
     /* ... */
  }

Even though we can write the prototype for hello in standard C, as shown
above, there is no way to use prototype syntax in the function definition.
Only an old-style definition will do.

It's worth pointing out that GCC has an extended prototype syntax which
can be used in definitions of functions like this one.

[toc] | [prev] | [next] | [standalone]

#148912

> 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?

It doesn't matter how this is handled because this is a exotic case
which is practically irrelevant: no one uses K&R function declarations
today and even less like than never with a preceded typedef like this.

[toc] | [prev] | [next] | [standalone]

#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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web