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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#103161

W dniu sobota, 4 lutego 2017 19:49:08 UTC+1 użytkownik Tim Rentsch napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu czwartek, 2 lutego 2017 11:40:03 UTC+1 u?ytkownik Tim Rentsch napisa?:
> >> Keith Thompson <kst-u@mib.org> writes:
> >>
> >>> Yes, it's IMHO infortunate that the language still allows
> >>> non-prototype function declarations and definitions.  [...]
> >>
> >> Some other people have reactions like this, and I'm a loss to
> >> understand why.  I can understand someone wanting to find places
> >> that don't have prototypes, but there are tools available for
> >> things like that (eg, various gcc options).  Why do you want to
> >> force your idea of what constitutes a good programming choice
> >> down everyone else's throat on every single compile whether they
> >> like it or not?  That is in effect what you're saying.  (Using a
> >> non-conforming mode or an out-of-date version of the standard
> >> is simply not a viable option.)
> >>
> >> I read somewhere that C++ is going to (or has already?) make
> >> using ++ on a boolean operand a constraint violation (C++ uses a
> >> different term IIANM, but the same idea).  If this is true (which
> >> I'm not sure it is), it's somewhere between completely lunatic
> >> and the programming equivalent of obsessive compulsive disorder.
> >> I have a similar reaction -- not as strong, but similar -- to
> >> wanting to get rid of non-prototypes.
> >>
> >> Incidentally, I do find non-prototype declarations handy on
> >> occasion, and in fact I used some just the other day.  But my
> >> reaction to the suggestion that they should be removed is not
> >> based just on that.
> >
> > i didnt understood this answer (weak english probably)
> >
> > but if its on defaults to which functions vealuates
> > it is interesting topic say
> >
> > main()
> > {
> >
> > }
> >
> > to what defaults it should evaluate?  [...]
> 
> That is an interesting question.  My comments though
> were about something else;  related, but not the same.

ok, not a problem

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

#102970

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Yes, it's IMHO infortunate that the language still allows
>> non-prototype function declarations and definitions. [...]
>
> Some other people have reactions like this, and I'm a loss to
> understand why.
[...]

Our previous discussions on this topic didn't resolve anything,
and I don't think I'll repeat them.

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

#103159

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Yes, it's IMHO infortunate that the language still allows
>>> non-prototype function declarations and definitions.  [...]
>>
>> Some other people have reactions like this, and I'm a loss to
>> understand why.
>
> [...]
>
> Our previous discussions on this topic didn't resolve anything,
> and I don't think I'll repeat them.

I have re-read what you have said before that I could find.  If I
may summarize, you don't like non-prototype declarations because
you think they are error-prone and because you think they don't
provide any significant value.

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?

Please don't feel obliged to respond if you don't want to.
I just wanted to be clear about what question I'm asking
about.

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

#103171

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.

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.

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

#103177

On Saturday, February 4, 2017 at 10:13:49 PM UTC, Keith Thompson wrote:
> 
> 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.
> 
The language with simple types needs to be B64. C has gone too
far down the typed variable route to allow default types any more.

I'm in two minds about whether a B64 function will need a prototype,
or whether they should all operate on bit buffers. The bit buffer
idea is more elegant - all functions simply map a set of input
bits to a set of output bits - but people are so used to the
conventional function of a set of parameters which returns a scalar
that it's hard to break.

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

#103244

On Saturday, February 4, 2017 at 4:13:49 PM UTC-6, Keith Thompson wrote:
> 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.

Would such a change be expected to pose any major problems with any existing
production code?  Some code might need to be changed to make it conforming,
but the necessary changes would be minimal, could be done essentially
mechanically, and would not make the code any less efficient or harder to
read.

By contrast, some implementations define useful behaviors for non-prototyped
functions beyond anything the C Standard requires, and regarding declarations
without argument lists as a constraint violation would break such code *in
a way that could be difficult to fix*.  To be sure, the C Standard has done
worse things in the past (e.g. forbidding structures from containing zero-
sized arrays broke code which used structures like:

    struct small_byte_array {
      unsigned short size;
      char dat[0];
    }

made it necessary to use other hackier approaches instead) but unless
forbidding something would offer a clear benefit, there's no reason to
accept the risk of it imposing a severe cost.

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

#103245

On Sunday, February 5, 2017 at 9:39:30 PM UTC, supe...@casperkitty.com wrote:
>
> By contrast, some implementations define useful behaviors for non-prototyped
> functions beyond anything the C Standard requires, and regarding declarations
> without argument lists as a constraint violation would break such code *in
> a way that could be difficult to fix*.  To be sure, the C Standard has done
> worse things in the past (e.g. forbidding structures from containing zero-
> sized arrays broke code which used structures like:
> 
>     struct small_byte_array {
>       unsigned short size;
>       char dat[0];
>     }
> 
> made it necessary to use other hackier approaches instead) but unless
> forbidding something would offer a clear benefit, there's no reason to
> accept the risk of it imposing a severe cost.
>
There's no law against wearing underpants on your head.
If large numbers of people were doing it and causing a public
distraction, it might be necessary to pass such a law. But since
so few people are to be seen with underpants on their head,
you can argue that the law is redundant.

Similarly no-one uses implicit int or non-prototyped functions
any more.

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

#103249

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Similarly no-one uses implicit int or non-prototyped functions
> any more.

Nonsense.  I see plenty of C code with implicit int and
non-prototyped functions, often in questions from inexperienced
programmers.  "int main()" rather than "int main(void)" is perhaps
the most common example.

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

#103262

On 02/ 6/17 10:56 AM, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Similarly no-one uses implicit int or non-prototyped functions
>> any more.
>
> Nonsense.  I see plenty of C code with implicit int and
> non-prototyped functions, often in questions from inexperienced
> programmers.  "int main()" rather than "int main(void)" is perhaps
> the most common example.

But these, just like wearing underpants on your head, are mistakes. not 
good practice.
-- 
Ian

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

#103265

Ian Collins <ian-news@hotmail.com> writes:
> On 02/ 6/17 10:56 AM, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Similarly no-one uses implicit int or non-prototyped functions
>>> any more.
>>
>> Nonsense.  I see plenty of C code with implicit int and
>> non-prototyped functions, often in questions from inexperienced
>> programmers.  "int main()" rather than "int main(void)" is perhaps
>> the most common example.
>
> But these, just like wearing underpants on your head, are mistakes. not 
> good practice.

Of course.  I'm disputing Malcolm's claim that noone makes those
mistakes.

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

#103267

On 02/ 6/17 01:14 PM, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 02/ 6/17 10:56 AM, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> [...]
>>>> Similarly no-one uses implicit int or non-prototyped functions
>>>> any more.
>>>
>>> Nonsense.  I see plenty of C code with implicit int and
>>> non-prototyped functions, often in questions from inexperienced
>>> programmers.  "int main()" rather than "int main(void)" is perhaps
>>> the most common example.
>>
>> But these, just like wearing underpants on your head, are mistakes. not
>> good practice.
>
> Of course.  I'm disputing Malcolm's claim that noone makes those
> mistakes.

I guess an intelligent bu uninformed member of a remote Amazon tribe 
would also be confused by underpants :)

-- 
Ian

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

#103270

On 06/02/17 01:24, Ian Collins wrote:
> On 02/ 6/17 01:14 PM, Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> On 02/ 6/17 10:56 AM, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> [...]
>>>>> Similarly no-one uses implicit int or non-prototyped functions
>>>>> any more.
>>>>
>>>> Nonsense.  I see plenty of C code with implicit int and
>>>> non-prototyped functions, often in questions from inexperienced
>>>> programmers.  "int main()" rather than "int main(void)" is perhaps
>>>> the most common example.
>>>
>>> But these, just like wearing underpants on your head, are mistakes. not
>>> good practice.
>>
>> Of course.  I'm disputing Malcolm's claim that noone makes those
>> mistakes.
>
> I guess an intelligent bu uninformed member of a remote Amazon tribe
> would also be confused by underpants :)
>

I think Tim Rentsch mentioned recently that he had use for non-prototype 
function declarations.  I don't believe he explained /why/ he used them 
- perhaps he just wants to avoid going over the top?

<https://en.wikipedia.org/wiki/Goodbyeee>

(More seriously, I assume Tim had a good reason, I just don't know what 
it might be.)

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

#103510

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

> Ian Collins <ian-news@hotmail.com> writes:
>> On 02/ 6/17 10:56 AM, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> [...]
>>>> Similarly no-one uses implicit int or non-prototyped functions
>>>> any more.
>>>
>>> Nonsense.  I see plenty of C code with implicit int and
>>> non-prototyped functions, often in questions from inexperienced
>>> programmers.  "int main()" rather than "int main(void)" is perhaps
>>> the most common example.
>>
>> But these, just like wearing underpants on your head, are mistakes.  not
>> good practice.
>
> Of course.  I'm disputing Malcolm's claim that noone makes those
> mistakes.

Not everyone agrees that all of them are mistakes.

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

#103247

supercat@casperkitty.com writes:
> On Saturday, February 4, 2017 at 4:13:49 PM UTC-6, Keith Thompson wrote:
>> 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.
[...]
> By contrast, some implementations define useful behaviors for non-prototyped
> functions beyond anything the C Standard requires, and regarding declarations
> without argument lists as a constraint violation would break such code *in
> a way that could be difficult to fix*.

Examples?

[...]

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

#103252

On 02/ 6/17 10:39 AM, supercat@casperkitty.com wrote:
> On Saturday, February 4, 2017 at 4:13:49 PM UTC-6, Keith Thompson wrote:
>> 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.
>
> Would such a change be expected to pose any major problems with any existing
> production code?  Some code might need to be changed to make it conforming,
> but the necessary changes would be minimal, could be done essentially
> mechanically, and would not make the code any less efficient or harder to
> read.
>
> By contrast, some implementations define useful behaviors for non-prototyped
> functions beyond anything the C Standard requires, and regarding declarations
> without argument lists as a constraint violation would break such code *in
> a way that could be difficult to fix*.

Such code would undoubtedly have to be compiled in a non-standard 
configuration, so any changes to the standard would probably be irrelevant.

-- 
Ian

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

#103509

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.

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

#103515

On 09/02/17 06:32, Tim Rentsch wrote:
> 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.
> 

It can be difficult to decide where to draw lines here.  Sure, there are
some people who still find non-prototype function declarations to be
useful.  But how do those few compare to the numbers of people that make
mistakes, or write poorer quality code, by using non-prototype function
declarations?  I have no statistics here, and I suspect neither do you,
Keith, or the C standards committee.

But I am at a loss to imagine a use of non-prototype functions that
cannot be replaced by prototyped functions and/or macros.  You cannot
call a function without knowing the parameters and types - if they don't
match up with the function's definition, then the program will be
incorrect (it will have undefined behaviour).

At best, non-prototype function declarations might let you do some basic
syntax checking of your code before it can run - but a macro of the form
"#define foo(...)" should work just as well.  I believe that it most, or
all, cases where non-prototype function declarations are used, there are
alternative solutions that are usually better or at least not too
onerous.  (Feel free to provide counter-examples - maybe my imagination
is limited here.)

So to my mind, the cases /are/ analogous - it would be a change that can
cause problems for older or "looser" code, but which removes a source of
errors and improves code rigour.

That is not discounting other people's opinions - it is about talking a
balanced view of them and concluding that the language would be better
overall without this feature, even though it might disappoint some
people.  (They could stick to C90, C99, or C11 - changes do not affect
existing standards.)

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

#103535

On Thursday, February 9, 2017 at 3:33:57 AM UTC-6, David Brown wrote:
> It can be difficult to decide where to draw lines here.  Sure, there are
> some people who still find non-prototype function declarations to be
> useful.  But how do those few compare to the numbers of people that make
> mistakes, or write poorer quality code, by using non-prototype function
> declarations?  I have no statistics here, and I suspect neither do you,
> Keith, or the C standards committee.

People who write implementations should have some idea of what kind of
code their customers will need to run.  If a construct will be useful or
essential for customers of some implementations, but not for others, it
would make the most sense to say that implementations whose customers will
need the construct are free to support it at their leisure, but those whose
customers would only invoke the construct accidentally would be free to
reject it.

Nothing is gained by mandating that an implementation support features that
none of its customers would ever need, but nor is anything gained by
suggesting that implementations should remove support for constructs upon
which their customers rely.

> But I am at a loss to imagine a use of non-prototype functions that
> cannot be replaced by prototyped functions and/or macros.  You cannot
> call a function without knowing the parameters and types - if they don't
> match up with the function's definition, then the program will be
> incorrect (it will have undefined behaviour).
> 
> At best, non-prototype function declarations might let you do some basic
> syntax checking of your code before it can run - but a macro of the form
> "#define foo(...)" should work just as well.  I believe that it most, or
> all, cases where non-prototype function declarations are used, there are
> alternative solutions that are usually better or at least not too
> onerous.  (Feel free to provide counter-examples - maybe my imagination
> is limited here.)

If the language were to allow implementations to accept declarations of the
form "int foo(__unknown_args)" as an alternative to "int foo()", the latter
form could then be deprecated.  What's important, though, is to recognize
that a significant number of programs may exist that rely upon a feature
which becomes bothersome to support, the feature should be replaced with a
new form that old systems could easily be made to support (e.g. by specifying
that __unknown_args should be a compiler-defined macro that maps to a
compiler intrinsic, and that code may use:

    #ifndef __unknown_args
    #define __unknown_args
    #endif

so an old compiler that supports "int foo()" wouldn't have to do anything to
support "int foo(__unknown_args)" the same way).  Once that is done, code
could be migrated to use the new form, and after migration is essentially
complete, support for the old form could be dropped.


   

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

#103553

On 02/ 9/17 10:33 PM, David Brown wrote:
> On 09/02/17 06:32, Tim Rentsch wrote:
>> 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.
>>
>
> It can be difficult to decide where to draw lines here.  Sure, there are
> some people who still find non-prototype function declarations to be
> useful.  But how do those few compare to the numbers of people that make
> mistakes, or write poorer quality code, by using non-prototype function
> declarations?  I have no statistics here, and I suspect neither do you,
> Keith, or the C standards committee.
>
> But I am at a loss to imagine a use of non-prototype functions that
> cannot be replaced by prototyped functions and/or macros.  You cannot
> call a function without knowing the parameters and types - if they don't
> match up with the function's definition, then the program will be
> incorrect (it will have undefined behaviour).
>
> At best, non-prototype function declarations might let you do some basic
> syntax checking of your code before it can run - but a macro of the form
> "#define foo(...)" should work just as well.  I believe that it most, or
> all, cases where non-prototype function declarations are used, there are
> alternative solutions that are usually better or at least not too
> onerous.  (Feel free to provide counter-examples - maybe my imagination
> is limited here.)
>
> So to my mind, the cases /are/ analogous - it would be a change that can
> cause problems for older or "looser" code, but which removes a source of
> errors and improves code rigour.

That is the view taken by a couple of teams I worked with in the 90s who 
used C++ compilers to "lint" their code in order to remove that 
particular source of errors.  It is also my opinion!

-- 
Ian

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

#103532

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

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 -- which could also have caught any errors where
the function is called inconsistently.

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.

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

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

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

csiph-web