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

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

How to find the problem in the object file

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

Contents

  How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 05:14 -0800
    Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:22 +0000
      Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:37 +0000
    Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 13:53 +0000
      Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:20 -0800
        Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 14:28 +0000
          Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:48 -0800
          Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:29 -0800
            Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 16:54 +0000
              Re: How to find the problem in the object file luser droog <luser.droog@gmail.com> - 2017-01-26 09:01 -0800
              Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:20 -0800
              Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:12 +0100
                Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-27 01:32 +0000
                  Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 09:50 +0100
            Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 09:19 -0800
              Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:21 -0800
                Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 02:39 -0800
                  Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:08 -0800
                    Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:31 -0800
                    Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:48 -0800
                      Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-04 11:07 -0800
                  Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-02 10:22 -0800
                    Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:00 -0800
                      Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-04 14:14 -0800
                        Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 20:02 -0800
                        Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-05 13:39 -0800
                          Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:44 -0800
                            Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:56 -0800
                              Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:07 +1300
                                Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 16:14 -0800
                                  Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:24 +1300
                                    Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-06 01:59 +0100
                                  Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
                          Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:54 -0800
                          Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:18 +1300
                        Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
                          Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-09 10:33 +0100
                            Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:10 -0800
                            Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:01 +1300
                          Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:01 -0800
                            Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:35 -0800
                              Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:57 -0800
                                Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:45 +0100
                                  Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 14:59 -0800
                                    Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 15:20 -0800
                                      Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 16:12 -0800
                                        Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 10:21 +0100
                                          Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-13 07:20 -0800
                                            Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-13 09:28 -0800
                                    Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 09:55 +0100
                                  Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 03:36 -0800
                            Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:56 +0100
                            Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 07:00 -0800
                              Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-16 20:03 +0100
                                Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-17 09:22 +1300
                                  Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-16 13:07 -0800
                                    Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:21 -0800
                                  Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:02 -0800
                                    Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:05 +1300
                                Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:26 -0800
                                  Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-25 19:38 +0100
                  Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-03 07:32 +1300
                    Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:24 -0800
                  Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:56 -0600
                    Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:12 -0800
                      Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 04:47 -0600
                        Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:59 -0800
                      Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:13 -0800
                        Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 19:28 -0800
                          Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:48 -0800
                            Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 17:36 -0800
        Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 15:51 +0100
          Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 08:29 -0800
            Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 16:34 +0000
              Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 09:48 -0800
            Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:52 -0800
            Re: How to find the problem in the object file James Kuyper <jameskuyper@verizon.net> - 2017-01-26 13:53 -0500
              Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 11:00 -0800
            Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:49 +0100
              Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-27 06:08 -0800
                Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 16:20 +0100
          Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:41 -0800
            Re: How to find the problem in the object file m.labanowicz@gmail.com - 2017-01-27 01:26 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#103541

On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
> Do you have a compelling example where old-style function
> declarations are actually useful?  Perhaps you've already posted
> it here, but if so I can't recall it.  I also invite anyone else
> to post examples.

On some systems, calls to prototyped functions use a different naming and
calling conventions from calls to non-prototyped functions.  A compiler
which processes a function with a prototype could include two entry points--
one for each calling convention--but compiled code from the days before
prototypes would only have one entry point.  If an existing compiler uses
the presence or absence of a prototype as its means for selecting which
calling convention to use, having each new implementation come up with a
different syntax to indicate the same meaning as the old () form, and
possibly requiring users to come up with macros to allow code to be
compatible with old and new compilers alike, would seem less helpful than
having a recommended form.

Also, there are some cases where it's useful to have types of functions
accept pointers to function types which can't be declared yet.  While
having a form of incomplete function type analogous to an incomplete
structure types would be a better solution, the only way I know presently
to avoid requiring a cast at each function call would be to have a
function accept a pointer to a function of unspecified arguments.  That
would especially be an issue in cases where a function accepts pointers to
two other functions, one of which is passed to the other and used for no
other purpose (so given:

    int f1a(void);
    int f1b(int (*p)(void));
    int f2a(double q, long r);
    int f2b(int (*p)(double q, long r));

function foo might be invoked as either foo(f1a, f1b) or foo(f2a, f2b).
While it wouldn't generally be possible for a function to invoke a function
pointer without knowing what kind of arguments it requires, function foo
shouldn't need to know or care about how the second function should be
called provided that the first function knows how to call the second
properly.

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

#103543

supercat@casperkitty.com writes:
> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
>> Do you have a compelling example where old-style function
>> declarations are actually useful?  Perhaps you've already posted
>> it here, but if so I can't recall it.  I also invite anyone else
>> to post examples.
>
> On some systems, calls to prototyped functions use a different naming and
> calling conventions from calls to non-prototyped functions.

Name one.

[snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#103556

Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
>>> Do you have a compelling example where old-style function
>>> declarations are actually useful?  Perhaps you've already posted
>>> it here, but if so I can't recall it.  I also invite anyone else
>>> to post examples.
>>
>> On some systems, calls to prototyped functions use a different naming and
>> calling conventions from calls to non-prototyped functions.
>
> Name one.

Is this even conforming?  I though it was allowed to declare a function
with a prototype and define it without, without having the prototype
visible at the point of definition.

Yours,

-- 
Jean-Marc

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

#103576

On Thursday, February 9, 2017 at 1:45:45 PM UTC-6, Jean-Marc Bourguet wrote:
> Keith Thompson writes:
> 
> > supercat writes:
> >> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
> >>> Do you have a compelling example where old-style function
> >>> declarations are actually useful?  Perhaps you've already posted
> >>> it here, but if so I can't recall it.  I also invite anyone else
> >>> to post examples.
> >>
> >> On some systems, calls to prototyped functions use a different naming and
> >> calling conventions from calls to non-prototyped functions.
> >
> > Name one.
> 
> Is this even conforming?  I though it was allowed to declare a function
> with a prototype and define it without, without having the prototype
> visible at the point of definition.

I've observed such behavior with the Keil C51 compiler (which is non-
compliant in a few ways, but strives to comply with the Standard as much
as practical).  It uses a naming convention similar to what I suggested
(adding an underscore to the names of functions which expected arguments
in registers).  I don't recall noticing if it had an option to generate
a stub to allow non-prototype calls to prototyped functions, but the
naming convention was such that if such stubs were generated the functions
could support being called through either convention, which would satisfy
the requirements of the Standard.

Further, on both the PC and the classic Macintosh, many compilers have
supported a number of calling conventions; code which calls a function would
use the convention described in its prototype, if any, or else the default
configured for the caller.  An attempt to call the a function with the wrong
convention would either jump the rails or cause a link error (I think the PC
compilers preceded link names with an underscore when using C convention,
but not when using Pascal convention; I don't remember the Macintosh making
that distinction).

The authors of the Standard have historically shown deference to plausible
implementations (e.g. ones that might behave unpredictably when left-
shifting a negative value), on the basis that such deference shouldn't
prevent implementations that don't need them from behaving sensibly.
While I don't know of any fully-compliant implementations that behave as
I described, I have seen some that use the same general principles.

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

#103578

supercat@casperkitty.com writes:
> On Thursday, February 9, 2017 at 1:45:45 PM UTC-6, Jean-Marc Bourguet wrote:
>> Keith Thompson writes:
>> 
>> > supercat writes:
>> >> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
>> >>> Do you have a compelling example where old-style function
>> >>> declarations are actually useful?  Perhaps you've already posted
>> >>> it here, but if so I can't recall it.  I also invite anyone else
>> >>> to post examples.
>> >>
>> >> On some systems, calls to prototyped functions use a different naming and
>> >> calling conventions from calls to non-prototyped functions.
>> >
>> > Name one.
>> 
>> Is this even conforming?  I though it was allowed to declare a function
>> with a prototype and define it without, without having the prototype
>> visible at the point of definition.
>
> I've observed such behavior with the Keil C51 compiler (which is non-
> compliant in a few ways, but strives to comply with the Standard as much
> as practical).

Then it's hardly relevant.

I believe this program is valid:

#include <stdio.h>

void func();

int main(void) {
    func("Hello, world");
}

void func(const char *message) {
    puts(message);
}

(The definition could be moved to a different translation unit if that
matters.)

At the point of the call, the only visible declaration of the function
is not a prototype.  The function is later defined with a prototype.  If
different calling conventions were used for prototyped and
non-prototyped functions, the call would likely fail somehow.

The change I propose making to the standard, removing non-prototype
function declarations and definitions, needn't affect any non-conforming
implementations if, for example, their non-conforming features are
sufficiently useful.  (I don't know why Keil would use different calling
conventions for prototyped and non-prototype functions, but I'll accept
that it does so and that there's some reason for it.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#103581

On Thursday, February 9, 2017 at 5:19:59 PM UTC-6, Keith Thompson wrote:
> I believe this program is valid:
> 
> #include <stdio.h>
> 
> void func();
> 
> int main(void) {
>     func("Hello, world");
> }
> 
> void func(const char *message) {
>     puts(message);
> }
> 
> (The definition could be moved to a different translation unit if that
> matters.)
> 
> At the point of the call, the only visible declaration of the function
> is not a prototype.  The function is later defined with a prototype.  If
> different calling conventions were used for prototyped and
> non-prototyped functions, the call would likely fail somehow.

If the compiler defined entry points for both _func and func, then calls
to either (using the appropriate convention for the linker name used) would
work.  Having the compiler do so by default, however, would waste a few
bytes per function unless code actually needed to invoke functions both ways.
Given that the compiler is designed to support parts with as few as 1024
bytes, such waste is best avoided.  When using default settings, code like
the above fail with a link error if the function was defined in a different
compilation unit from where it was called (I think the compiler would also
issue a warning if a function was declared with a prototype after it had
already generated code for a call without one).  I never had a need to
request that the compiler generate stubs for both calling conventions, so
I don't know if it had an option to do so, but it would have been a fairly
simple way to make the compiler's behavior coincide with the Standard's
requirements in that regard.

> The change I propose making to the standard, removing non-prototype
> function declarations and definitions, needn't affect any non-conforming
> implementations if, for example, their non-conforming features are
> sufficiently useful.  (I don't know why Keil would use different calling
> conventions for prototyped and non-prototype functions, but I'll accept
> that it does so and that there's some reason for it.)

Prior to the advent of prototypes and stdarg.h, no distinction was made
between "required" and "optional" arguments.  Some code relied upon the
ability to have a function like:

    int printf(format)
       char *format;
    {
      ...
    }

harmlessly ignore any extra arguments that might get passed to it.  Further,
some code exploited the fact that on many implementations, given a function:

    int foo(x,y)
       int x,y;
    {
      ...
    }

a call "foo(3);" would behave identically to "foo(3,0);", but generate
smaller code, if the function "foo" never attempted to do anything with
its second argument.

In the interest of supporting extant code which did such things, many
implementations used a calling convention which didn't rely upon the caller
knowing how many arguments the called function was expecting, provided only
that the caller supplied *at least* as many arguments as the called function
actually tried to use.

Note that the Standard allows "foo(1,2);" to yield different code depending
upon whether the function expects two ints, or an int and a variable-length
argument list; the Standard suggests that the default presumption should
be that the function expects two arguments of type "int", but the commonplace
behavior was to use a convention that was less efficient than passing two
arguments of type "int" but which would work with with variadic arguments
(since there would otherwise have been no way to specify that a function
needs variadic-argument support).  For a compiler to presume the use of the
faster convention without supporting the universal one would have broken any
code that needed variadic-argument support and hadn't been updated to use
prototypes.

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

#103776

On 10/02/17 01:12, supercat@casperkitty.com wrote:
> On Thursday, February 9, 2017 at 5:19:59 PM UTC-6, Keith Thompson wrote:
>> I believe this program is valid:
>>
>> #include <stdio.h>
>>
>> void func();
>>
>> int main(void) {
>>     func("Hello, world");
>> }
>>
>> void func(const char *message) {
>>     puts(message);
>> }
>>
>> (The definition could be moved to a different translation unit if that
>> matters.)
>>
>> At the point of the call, the only visible declaration of the function
>> is not a prototype.  The function is later defined with a prototype.  If
>> different calling conventions were used for prototyped and
>> non-prototyped functions, the call would likely fail somehow.
> 
> If the compiler defined entry points for both _func and func, then calls
> to either (using the appropriate convention for the linker name used) would
> work.  Having the compiler do so by default, however, would waste a few
> bytes per function unless code actually needed to invoke functions both ways.
> Given that the compiler is designed to support parts with as few as 1024
> bytes, such waste is best avoided.  When using default settings, code like
> the above fail with a link error if the function was defined in a different
> compilation unit from where it was called (I think the compiler would also
> issue a warning if a function was declared with a prototype after it had
> already generated code for a call without one).  I never had a need to
> request that the compiler generate stubs for both calling conventions, so
> I don't know if it had an option to do so, but it would have been a fairly
> simple way to make the compiler's behavior coincide with the Standard's
> requirements in that regard.

Let me see if I understand your point here, Supercat:

On a compiler for a target like the 8051, it can make sense to have more
optimised calling conventions tuned to the actual parameters used in a
function.  For those that don't know the 8051, it is an 8-bit processor
with only a couple of registers, and with extremely poor data stack
support (no "stack pointer + index" addressing modes).  So a compiler
for such a target might have a calling convention with "first parameter
in the A register, other parameters on the stack" to be general, and to
work with re-entrant or recursive functions.  But given a specific
function "uint8_t foo(uint8_t x, uint8_t y)", that is known to be
non-recursive (through program analysis, command-line options, pragmas,
etc.), it is likely that the compiler will assign static fixed addresses
in memory for "x" and "y".

A general implementation of "foo" would then be:

// Data section
parameter_x: .byte 1
parameter_y: .byte 1

// Code section
foo_unprototyped:
	store A at address parameter_x
	pop stack into A
	store A at address parameter_y
foo_prototyped:
	// Use parameter_x and parameter_y
	return

Putting data onto the stack, or taking it off the stack, is big and
slow, and avoided where possible.


With an arrangement like this, the compiler will call "foo_prototyped"
when possible and fall back on "foo_unprototyped" when unavoidable.

However, the compiler must always generate both of these entry points
when it generates code for "foo", unless it can be sure that
foo_unprototyped is never used in the code.  That could be due to
"static", to whole-program analysis, pragmas, command-line options, etc.
 Or it could generate the code and let a smart compiler figure out that
it is not used and remove it.

Either way, as far as C is concerned, the programmer can call the same
function with a prototype declaration or non-prototype declaration, and
get the same effect.  Details of the entry point used are hidden by the
implementation.

(Keil is normally used in whole-program mode, I believe, which means
that such things are not only hidden from the programmer, but end up
with the most efficient implementation automatically.)	

> 
>> The change I propose making to the standard, removing non-prototype
>> function declarations and definitions, needn't affect any non-conforming
>> implementations if, for example, their non-conforming features are
>> sufficiently useful.  (I don't know why Keil would use different calling
>> conventions for prototyped and non-prototype functions, but I'll accept
>> that it does so and that there's some reason for it.)
> 

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

#103809

On Monday, February 13, 2017 at 3:21:32 AM UTC-6, David Brown wrote:
> (Keil is normally used in whole-program mode, I believe, which means
> that such things are not only hidden from the programmer, but end up
> with the most efficient implementation automatically.)	

The documentation talked about options for whole-program optimization, but I'd
not used them beyond some experiments.  The amount of improvement didn't seem
sufficient to justify the additional compilation time and make-file complexity.

In any case, the concept of having functions' link-time name vary based
upon the use or non-use of a prototype is something which exists in
something which is probably about as close to being a conforming C89
compiler as would be practical given the target system, and while I don't
know of compilers for other systems where the *default* convention used
for prototyped functions differs from the default used with non-prototyped
functions, there are certainly systems where using a different convention
with prototyped functions could allow more efficient code generation, and
where coupling that with a different naming convention and default stub
generation would make it possible to get that improved efficiency without
loss of compatibility *except* that compiled code for old-style functions
would require that the caller not have a prototype.

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

#103818

supercat@casperkitty.com writes:
> On Monday, February 13, 2017 at 3:21:32 AM UTC-6, David Brown wrote:
>> (Keil is normally used in whole-program mode, I believe, which means
>> that such things are not only hidden from the programmer, but end up
>> with the most efficient implementation automatically.)	
>
> The documentation talked about options for whole-program optimization,
> but I'd not used them beyond some experiments.  The amount of
> improvement didn't seem sufficient to justify the additional
> compilation time and make-file complexity.
>
> In any case, the concept of having functions' link-time name vary based
> upon the use or non-use of a prototype is something which exists in
> something which is probably about as close to being a conforming C89
> compiler as would be practical given the target system, and while I don't
> know of compilers for other systems where the *default* convention used
> for prototyped functions differs from the default used with non-prototyped
> functions, there are certainly systems where using a different convention
> with prototyped functions could allow more efficient code generation, and
> where coupling that with a different naming convention and default stub
> generation would make it possible to get that improved efficiency without
> loss of compatibility *except* that compiled code for old-style functions
> would require that the caller not have a prototype.

That last paragraph was all one sentence.  *Please* try to write more
clearly.

You say Keil is "probably about as close to being a conforming C89
compiler as would be practical given the target system".  It can
continue to be exactly that, regradless of what the next edition of
the standard does.  If C2x removed old-style function declarations
and definitions, that change would not need to have any effect on
Keil at all.  Your example does not support your argument.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#103775

On 09/02/17 23:59, supercat@casperkitty.com wrote:
> On Thursday, February 9, 2017 at 1:45:45 PM UTC-6, Jean-Marc Bourguet wrote:
>> Keith Thompson writes:
>>
>>> supercat writes:
>>>> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
>>>>> Do you have a compelling example where old-style function
>>>>> declarations are actually useful?  Perhaps you've already posted
>>>>> it here, but if so I can't recall it.  I also invite anyone else
>>>>> to post examples.
>>>>
>>>> On some systems, calls to prototyped functions use a different naming and
>>>> calling conventions from calls to non-prototyped functions.
>>>
>>> Name one.
>>
>> Is this even conforming?  I though it was allowed to declare a function
>> with a prototype and define it without, without having the prototype
>> visible at the point of definition.
> 
> I've observed such behavior with the Keil C51 compiler (which is non-
> compliant in a few ways, but strives to comply with the Standard as much
> as practical).

No, it does not strive to comply to the standard (any of them).  And it
is so far away on many aspects that it does not count as a "C
implementation" - it is a "C-like compiler with a sort-of C-like library".

It strives to guess what users might find useful in order to get
efficient code on a target processor that is completely unsuitable for
C, and then it strives to follow these rules it has made up for that
particular version of the compiler.  A fine example of its
non-compliance is its disregard for integer promotion rules (because
Keil things its users want to keep their 8-bit arithmetic without
promoting it to grossly inefficient 16-bit arithmetic - good intentions,
but non-standard and surprising to people expecting to work in C).

>  It uses a naming convention similar to what I suggested
> (adding an underscore to the names of functions which expected arguments
> in registers).  I don't recall noticing if it had an option to generate
> a stub to allow non-prototype calls to prototyped functions, but the
> naming convention was such that if such stubs were generated the functions
> could support being called through either convention, which would satisfy
> the requirements of the Standard.
> 

Note that there is absolutely no good reason for Keil's tools to work
this way - in fact, I would be very surprised if they do so.  The tools
are also usually operated in a "whole program optimisation" mode, so the
compiler has full information about all functions and their uses in the
code.


> Further, on both the PC and the classic Macintosh, many compilers have
> supported a number of calling conventions; code which calls a function would
> use the convention described in its prototype, if any, or else the default
> configured for the caller.  An attempt to call the a function with the wrong
> convention would either jump the rails or cause a link error (I think the PC
> compilers preceded link names with an underscore when using C convention,
> but not when using Pascal convention; I don't remember the Macintosh making
> that distinction).

Things like "far" or "fastcall" calling convention markers are
extensions that need to be used when declaring a function - it does not
matter if the declaration is a function prototype or a non-prototype
function declaration.

> 
> The authors of the Standard have historically shown deference to plausible
> implementations (e.g. ones that might behave unpredictably when left-
> shifting a negative value), on the basis that such deference shouldn't
> prevent implementations that don't need them from behaving sensibly.
> While I don't know of any fully-compliant implementations that behave as
> I described, I have seen some that use the same general principles.
> 

No, neither of your examples support your point.

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

#103992

Jean-Marc Bourguet <jm@bourguet.org> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> supercat@casperkitty.com writes:
>>> On Thursday, February 9, 2017 at 11:01:55 AM UTC-6, Keith Thompson wrote:
>>>> Do you have a compelling example where old-style function
>>>> declarations are actually useful?  Perhaps you've already posted
>>>> it here, but if so I can't recall it.  I also invite anyone else
>>>> to post examples.
>>>
>>> On some systems, calls to prototyped functions use a different naming and
>>> calling conventions from calls to non-prototyped functions.
>>
>> Name one.
>
> Is this even conforming?  I though it was allowed to declare a function
> with a prototype and define it without, without having the prototype
> visible at the point of definition.

Such a scheme can be conforming, IIANM.  Having different names
is kind of beside the point:  there must be a way of converting
back and forth between the two call points, which in practical
terms means they must be relatable without knowing their names.
That relationship holds because it must be possible to convert a
pointer-to-function of one flavor to the other flavor, at which
point the names usually have long since been lost.  But there
very well could be different calling conventions used for the
different flavors (ie, prototyped and prototype-less).

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

#103558

Keith Thompson <kst-u@mib.org> writes:

> Do you have a compelling example where old-style function
> declarations are actually useful?  Perhaps you've already posted
> it here, but if so I can't recall it.  I also invite anyone else
> to post examples.

I've seen pointer to functions with unknown arguments used in interpreters,
the type and number of arguments where knows and checked by the
interpreter.  You couldn't use variadic functions (they need at least one
parameter before the ...).  You could have used pointers to fully
prototyped functions, at the cost of complexifying the implementation (for
instance, using an union of all the possible prototyped pointers) with no
benefit (you'd still need the other way to have the prototype for the
interpreter to choose which one to call).

But that is not a function declaration.

Yours,

-- 
Jean-Marc

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

#104009

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>
>>> (Context:  Removing non-prototype function declarations and definitions
>>> from the language.)
>>>
>>>> My question here is a little different.  Knowing that other
>>>> people consider them worth keeping, what explains the reaction
>>>> of wanting to exclude them anyway?  Is it just a "my opinions
>>>> count, and other people's don't" sort of attitude, or is it
>>>> something else?
>>>
>>> I didn't say that other people's opinions don't count.  I have
>>> my opinion, which I've already expressed, that old-style function
>>> declarations and definitions should be removed from the language.
>>
>> I understand these comments.  You are expressing a personal value
>> judgment.  Fine so far.
>>
>>> In C99, the committee removed implicit int from the language, and it
>>> hadn't even been marked as obsolescent.  I agree with that decision,
>>> and similar reasons apply to non-prototype function declarations
>>> and definitions.  Removing them would make C a better language.
>>
>> These comments are what I don't understand.  Essentially everyone
>> agreed that implicit int could be removed without any serious
>> loss, especially since there was something to replace it (eg,
>> either 'int' or 'void', depending).  Not everyone agrees that
>> non-prototype function declarations can be removed without any
>> serious loss, and IIUC what you're suggesting is that they be
>> removed without any sort of replacement for the capability.  The
>> two cases don't seem that analogous.  So I don't see how you get
>> to your conclusion, unless it is something like discounting of
>> other people's opinions.
>
> In my opinion, non-prototype function declarations are essentially
> useless, and they exist only for compatibility with code that
> was written before prototypes were available.  I have never seen
> a convincing use for them that would not be met at least as well
> by prototypes.

Yes, you have stated these views before, and I accept them
as your personal assessments.

> Note that C++ gets along just fine without them.

I accept that this statement reflects your beliefs in the
matter.  Do you mean it as anything more than a statement of
personal opinion or purely subjective value judgment?

> The ANSI C committee marked them as obsolescent in 1989.  I agree
> with that decision;  I take it you do not.

That depends on what meaning you think was intended.  I read this
statement as saying, roughly, "Be advised that something may
change or be removed in a future version of the standard."  Not
that it will be removed, or should be removed, or is likely to be
removed, but only that a change may be considered and if so that
may lead to removal.  Also there is the question of what the
"something" is here.  More specifically, is the item under
discussion a syntactic notation or a semantic capability?  When
implicit int was removed from C, it still was (and is) possible
to declare and define things of type 'int' - the change to the
language did remove a syntactic notation but did not remove the
underlying capability.  My interest here is not really about
syntax but more about capability - as long the syntax for a
generic function type is not too burdensome, I don't really care
whether it uses a () syntax or something else.

> You did recently offer an example.  As I recall (please correct me
> if I'm describing it incorrectly) it involved some code that was in
> an early stage of development;  you had written some function calls
> but not yet implemented the functions, so you added non-prototype
> declarations to allow the program to compile.  Surely it would have
> been only very slightly more difficult to add prototypes that match
> the actual calls

I talked about this in my other recent reply to another message
of yours.  Basically, the amount of effort needed would have
been much larger had I been forced to use prototypes.

> -- which could also have caught any errors where
> the function is called inconsistently.

I don't WANT to catch errors if or when a function is called
inconsistently.  For what I was doing, it's better to ignore such
issues at that stage of working than to be forced to pay
attention to them.

> Do you have a compelling example where old-style function
> declarations are actually useful?  Perhaps you've already posted
> it here, but if so I can't recall it.  I also invite anyone else
> to post examples.

Here is the problem with your question.  What you have done --
basically, all you have done -- is say you think non-prototype
declarations aren't very useful, and the language would be better
off without them.  It is purely a personal value judgment, with
no underlying reasoning given.  Any example that might be given
you could just say, "Nope, I don't think that's useful."  You've
heard some statments from me and at least one other person (in
this thread, Jean-Marc Bourguet) for cases we think are useful,
but you don't think they are.  Trying to offer a compelling
example under such circumstances is a fool's errand.

What bothers me is that I am perfectly willing to take your
comments at face value but you seem unwilling to return the
favor.  You think non-prototype function types aren't useful -
okay, I can accept that, and for you maybe they aren't.  So why
can't you accept that they /are/ useful for some of the work that
I do?  Personally I don't think this is that big a stretch.  C
has generic pointer types, in the form of 'void *', and they are
obviously useful.  It seems like generic function types should be
useful as well (not exactly the same as non-prototyped functions,
but still related);  indeed several use cases have been offered
where they actually /did/ prove useful in the judgment of those
doing the work.  But these cases don't convince you because,
well, it's just your reaction that they don't.  Can you see why
other people might find that rather frustrating?

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

#104028

On 16/02/17 16:00, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> [...]
>>>>
>>>> (Context:  Removing non-prototype function declarations and definitions
>>>> from the language.)
>>>>
>>>>> My question here is a little different.  Knowing that other
>>>>> people consider them worth keeping, what explains the reaction
>>>>> of wanting to exclude them anyway?  Is it just a "my opinions
>>>>> count, and other people's don't" sort of attitude, or is it
>>>>> something else?
>>>>
>>>> I didn't say that other people's opinions don't count.  I have
>>>> my opinion, which I've already expressed, that old-style function
>>>> declarations and definitions should be removed from the language.
>>>
>>> I understand these comments.  You are expressing a personal value
>>> judgment.  Fine so far.
>>>
>>>> In C99, the committee removed implicit int from the language, and it
>>>> hadn't even been marked as obsolescent.  I agree with that decision,
>>>> and similar reasons apply to non-prototype function declarations
>>>> and definitions.  Removing them would make C a better language.
>>>
>>> These comments are what I don't understand.  Essentially everyone
>>> agreed that implicit int could be removed without any serious
>>> loss, especially since there was something to replace it (eg,
>>> either 'int' or 'void', depending).  Not everyone agrees that
>>> non-prototype function declarations can be removed without any
>>> serious loss, and IIUC what you're suggesting is that they be
>>> removed without any sort of replacement for the capability.  The
>>> two cases don't seem that analogous.  So I don't see how you get
>>> to your conclusion, unless it is something like discounting of
>>> other people's opinions.
>>
>> In my opinion, non-prototype function declarations are essentially
>> useless, and they exist only for compatibility with code that
>> was written before prototypes were available.  I have never seen
>> a convincing use for them that would not be met at least as well
>> by prototypes.
>
> Yes, you have stated these views before, and I accept them
> as your personal assessments.
>
>> Note that C++ gets along just fine without them.
>
> I accept that this statement reflects your beliefs in the
> matter.  Do you mean it as anything more than a statement of
> personal opinion or purely subjective value judgment?

I am not speaking for Keith here, but I can tell you that I agree with 
his comment here, and I /don't/ mean it as merely personal opinion.  C++ 
does not support non-prototype function declarations.  The language has 
gone through many revisions, and has a much lower barrier to change than 
C.  If it were seriously felt that non-prototype function declarations 
were a missing feature, it is likely that they would have been added to 
the language, or that an alternative would have been added.  I cannot 
claim to have read /all/ the proposals for changes to the C++ language, 
but I have never seen anything to suggest that this is a feature people 
feel is missing from the language.  I think it is fair to conclude that 
C++ "gets along just fine without them".

>
>> The ANSI C committee marked them as obsolescent in 1989.  I agree
>> with that decision;  I take it you do not.
>
> That depends on what meaning you think was intended.  I read this
> statement as saying, roughly, "Be advised that something may
> change or be removed in a future version of the standard."  Not
> that it will be removed, or should be removed, or is likely to be
> removed, but only that a change may be considered and if so that
> may lead to removal.

According to the C99 Rationale:

 >> 6.11.6 Function declarators
 >> The characterization as obsolecent of the use of the "old style"
 >> function declarations and definitions, that is, the traditional
 >> style not using prototypes, signals the Committee's intent that
 >> the new prototype style should eventually replace the old style.
 >>
 >> The case for the prototype style is presented in §6.5.2.2 and
 >> §6.7.5.3.  The gist of this case is that the new syntax addresses
 >> some of the most glaring weaknesses of the language defined in
 >> K&R, that the new style is superior to the old style on every count.
 >>
 >> It was obviously out of the question to remove syntax used in the
 >> overwhelming majority of extant C code, so the Standard specifies two
 >> ways of writing function declarations and function definitions.
 >> Characterizing the old style as obsolescent is meant to discourage
 >> its use and to serve as a strong endorsement by the Committee of the
 >> new style.  It confidently expects that approval and adoption of the
 >> prototype style will make it feasible for some future C Standard to
 >> remove the old style syntax.

Seems pretty clear-cut to me.  The old style is still accepted for 
backwards compatibility, but the Committee considers prototypes to be 
"superior on every count" and hopes that they can eventually be removed 
entirely - it is only the existence of pre-C89 code that keeps the 
old-style declarations legal.

Of course that does not stop some people using them, or feeling that 
their code is better or their development process faster because 
non-prototype function declarations are allowed.  But it /does/ mean 
that saying "non-prototype functions are a relic of the past, and the 
language would be better without them" is the /standard/ position.  It 
is the position of the C Standards Committee, and has been for 30 years. 
  Wanting to have them available for use in new code (as distinct from 
as support for legacy code) is an unusual and rare position.

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

#104031

On 02/17/17 08:03 AM, David Brown wrote:
> On 16/02/17 16:00, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>> In my opinion, non-prototype function declarations are essentially
>>> useless, and they exist only for compatibility with code that
>>> was written before prototypes were available.  I have never seen
>>> a convincing use for them that would not be met at least as well
>>> by prototypes.
>>
>> Yes, you have stated these views before, and I accept them
>> as your personal assessments.
>>
>>> Note that C++ gets along just fine without them.
>>
>> I accept that this statement reflects your beliefs in the
>> matter.  Do you mean it as anything more than a statement of
>> personal opinion or purely subjective value judgment?
>
> I am not speaking for Keith here, but I can tell you that I agree with
> his comment here, and I /don't/ mean it as merely personal opinion.  C++
> does not support non-prototype function declarations.  The language has
> gone through many revisions, and has a much lower barrier to change than
> C.  If it were seriously felt that non-prototype function declarations
> were a missing feature, it is likely that they would have been added to
> the language, or that an alternative would have been added.  I cannot
> claim to have read /all/ the proposals for changes to the C++ language,
> but I have never seen anything to suggest that this is a feature people
> feel is missing from the language.  I think it is fair to conclude that
> C++ "gets along just fine without them".

Me to.  Keith stated a fact not an opinion: us C++ programmers do get 
along just fine without them.

Yes non-prototype function declarations can be of use, but like many 
aspects of the language, they also have a cost.  This cost outweighs the 
benefit.  The the C and C++ committees would appear to agree.

My view is they should go the route of gets.  There would be nothing to 
prevent compilers supporting them as an option (the notorious gcc/clang 
option "no-strict-aliasing" is a common example), just not in conforming 
mode.  That would probably cover Tim's use case for development builds 
while keeping the risk out of production code.

-- 
Ian

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

#104038

Ian Collins <ian-news@hotmail.com> writes:
[...]
> My view is they should go the route of gets.  There would be nothing to 
> prevent compilers supporting them as an option (the notorious gcc/clang 
> option "no-strict-aliasing" is a common example), just not in conforming 
> mode.  That would probably cover Tim's use case for development builds 
> while keeping the risk out of production code.

Indeed, if non-prototype function declarations and definitions were
removed from the language in a future standard, it is almost certain
that most or all C compilers would continue to support them in some
non-conforming mode, perhaps even by default.

gcc and clang already have "--std=cNN", for NN = 89/90, 99, and 11,
which will certainly[*] continue to support old-style function
declarations and definitions.

[*] Of course I can't be 100% certain of that, but I'd be astonished if
it weren't the case.  I can imagine gcc and clang eventually dropping
support for old C standards, but I expect C11 support to continue for
decades.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#104604

Keith Thompson <kst-u@mib.org> writes:

> Ian Collins <ian-news@hotmail.com> writes:
> [...]
>> My view is they should go the route of gets.  There would be nothing to
>> prevent compilers supporting them as an option (the notorious gcc/clang
>> option "no-strict-aliasing" is a common example), just not in conforming
>> mode.  That would probably cover Tim's use case for development builds
>> while keeping the risk out of production code.
>
> Indeed, if non-prototype function declarations and definitions were
> removed from the language in a future standard, it is almost certain
> that most or all C compilers would continue to support them in some
> non-conforming mode, perhaps even by default.

My experience with non-conforming modes that allow additional
(ie, non-conforming) constructs is that they allow other things
that aren't wanted.  No good.

By contrast, options that give warnings or errors on selected
conforming constructs tend to be precisely and accurately
targeted.  People who want to avoid non-prototype declarations
can simply use -Wstrict-prototypes in gcc (perhaps with a side
compile if another compiler is being used for the regular .o
files).

> gcc and clang already have "--std=cNN", for NN = 89/90, 99, and 11,
> which will certainly[*] continue to support old-style function
> declarations and definitions.

That makes things worse, not better.  If my only concern were for
what holds in past versions of the Standard I wouldn't have
brought it up in the first place.

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

#104603

Ian Collins <ian-news@hotmail.com> writes:

> On 02/17/17 08:03 AM, David Brown wrote:
>> On 16/02/17 16:00, Tim Rentsch wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> In my opinion, non-prototype function declarations are essentially
>>>> useless, and they exist only for compatibility with code that
>>>> was written before prototypes were available.  I have never seen
>>>> a convincing use for them that would not be met at least as well
>>>> by prototypes.
>>>
>>> Yes, you have stated these views before, and I accept them
>>> as your personal assessments.
>>>
>>>> Note that C++ gets along just fine without them.
>>>
>>> I accept that this statement reflects your beliefs in the
>>> matter.  Do you mean it as anything more than a statement of
>>> personal opinion or purely subjective value judgment?
>>
>> I am not speaking for Keith here, but I can tell you that I agree with
>> his comment here, and I /don't/ mean it as merely personal opinion.  C++
>> does not support non-prototype function declarations.  The language has
>> gone through many revisions, and has a much lower barrier to change than
>> C.  If it were seriously felt that non-prototype function declarations
>> were a missing feature, it is likely that they would have been added to
>> the language, or that an alternative would have been added.  I cannot
>> claim to have read /all/ the proposals for changes to the C++ language,
>> but I have never seen anything to suggest that this is a feature people
>> feel is missing from the language.  I think it is fair to conclude that
>> C++ "gets along just fine without them".
>
> Me to.  Keith stated a fact not an opinion:  us C++ programmers do get
> along just fine without them.

First off that is a different statement.  Second it is not a
statement of fact, because there is no objective observation that
will confirm or refute it.  Any statement of the form "X gets
along just fine without Y" is inherently subjective, because of
the "just fine" condition.  As such they cannot be statements of
fact.  Consider two examples:

    C gets along just fine without C99-style declarations.

    C++ gets along just fine without compound literals.

Each of these statements has people who agree with it and people
who do not agree with it.  What people mean by the "just fine"
part varies from person to person.  Whether one agrees or not,
neither is a statement of fact, and cannot be, because of the
subjective "just fine".  The same is true of the quoted "just
fine" statements about C++.

By the way, it's rather presumptuous to speak for "us C++
programmers".  I too program in C++.

> Yes non-prototype function declarations can be of use, but like many
> aspects of the language, they also have a cost.  This cost outweighs
> the benefit.  The the C and C++ committees would appear to agree.

Just more opinion.  It's disappointing that no one has responded
on the issue that started this whole subthread but instead have
treated it as an opinion shouting match.

> My view is they should go the route of gets.  There would be nothing
> to prevent compilers supporting them as an option (the notorious
> gcc/clang option "no-strict-aliasing" is a common example), just not
> in conforming mode.

There would be nothing to prevent compilers providing an option
that disallows non-prototype declarations either.  Oh wait!
There already is one.  So there already is an option for people
who want to avoid using such declarations.

> That would probably cover Tim's use case for
> development builds while keeping the risk out of production code.

It doesn't.  Also there are other cases where semi-generic
function types have useful application in final code.

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

#104631

On 02/25/17 06:02 AM, Tim Rentsch wrote:
>
> By the way, it's rather presumptuous to speak for "us C++
> programmers".  I too program in C++.

So do you struggle without non-prototype function declarations when you 
program in C++?

-- 
Ian

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

#104606

David Brown <david.brown@hesbynett.no> writes:

> On 16/02/17 16:00, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>> [...]
>>>>>
>>>>> (Context:  Removing non-prototype function declarations and definitions
>>>>> from the language.)
>>>>>
>>>>>> My question here is a little different.  Knowing that other
>>>>>> people consider them worth keeping, what explains the reaction
>>>>>> of wanting to exclude them anyway?  Is it just a "my opinions
>>>>>> count, and other people's don't" sort of attitude, or is it
>>>>>> something else?
>>>>>
>>>>> I didn't say that other people's opinions don't count.  I have
>>>>> my opinion, which I've already expressed, that old-style function
>>>>> declarations and definitions should be removed from the language.
>>>>
>>>> I understand these comments.  You are expressing a personal value
>>>> judgment.  Fine so far.
>>>>
>>>>> In C99, the committee removed implicit int from the language, and it
>>>>> hadn't even been marked as obsolescent.  I agree with that decision,
>>>>> and similar reasons apply to non-prototype function declarations
>>>>> and definitions.  Removing them would make C a better language.
>>>>
>>>> These comments are what I don't understand.  Essentially everyone
>>>> agreed that implicit int could be removed without any serious
>>>> loss, especially since there was something to replace it (eg,
>>>> either 'int' or 'void', depending).  Not everyone agrees that
>>>> non-prototype function declarations can be removed without any
>>>> serious loss, and IIUC what you're suggesting is that they be
>>>> removed without any sort of replacement for the capability.  The
>>>> two cases don't seem that analogous.  So I don't see how you get
>>>> to your conclusion, unless it is something like discounting of
>>>> other people's opinions.
>>>
>>> In my opinion, non-prototype function declarations are essentially
>>> useless, and they exist only for compatibility with code that
>>> was written before prototypes were available.  I have never seen
>>> a convincing use for them that would not be met at least as well
>>> by prototypes.
>>
>> Yes, you have stated these views before, and I accept them
>> as your personal assessments.
>>
>>> Note that C++ gets along just fine without them.
>>
>> I accept that this statement reflects your beliefs in the
>> matter.  Do you mean it as anything more than a statement of
>> personal opinion or purely subjective value judgment?
>
> I am not speaking for Keith here, but I can tell you that I agree
> with his comment here, and I /don't/ mean it as merely personal
> opinion.  C++ does not support non-prototype function declarations.
> [...]

You have as usual missed the point.  But then that isn't too
surprising since what motivates you is not a desire to help
further the conversation but just liking hearing the sound of
your own voice.

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web