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

#104711

On 24/02/17 18:26, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/02/17 16:00, Tim Rentsch wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
<snip>
>>>> 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.
>

Is that your opinion of my motivations, or is it fact?  If it is fact, 
I'd like to see your evidence - if it is opinion, then why do /you/ get 
to express your opinion as though it were clear and obvious fact, while 
you rail against others?

I notice that you snipped my reasoning for saying that "C++ gets along 
fine without non-prototype function declarations" - justification for 
claiming it is a lot more than my personal opinion.  At the very least 
it is the shared opinion of both the C and C++ standards committee that 
the prototype function declarations are "superior on every count". 
Closer to "fact" would be harder to get here.

 From anyone less knowledgable than you, I would take an ad hominem 
reply as a clear sign of losing an argument - I would rather try to 
learn why you have a different opinion of non-prototype function 
declarations, than to consider the sub-thread to be argument for wining 
or losing.  I have yet to see any good reasoning from you - certainly no 
examples that could not have been expressed at least as well, if not 
better, without resorting to "old style" declarations.

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

#102971

On 02/ 2/17 11:39 PM, Tim Rentsch wrote:
> 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.

Using ++ on a boolean operand is deprecated in C++, just as 
non-prototype function declarations are already gone.  Neither offer any 
value.  The former is usually a mistake and the latter are a source of 
error.

 > cat x.cc; CC x.cc
void barely_defined();

int main(int argc, char *argv[]) {
   barely_defined(42);
}
"x.cc", line 4: Error: Too many arguments in call to "barely_defined()".
1 Error(s) detected.

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

How did you use one and why wasn't a regular declaration appropriate?

-- 
Ian

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

#103164

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

> On 02/ 2/17 11:39 PM, Tim Rentsch wrote:
>> 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.
>
> Using ++ on a boolean operand is deprecated in C++, just as
> non-prototype function declarations are already gone.  Neither offer
> any value.  [...]

I won't speak to the question in C++, but in C both are
useful on occasion.  Some people may feel that this or
that use case provide no significant benefit, but there
is no denying they offer some utility.

>> cat x.cc;  CC x.cc
>
> void barely_defined();
>
> int main(int argc, char *argv[]) {
>   barely_defined(42);
> }
> "x.cc", line 4:  Error:  Too many arguments in call to "barely_defined()".
> 1 Error(s) detected.

Yes, I understand that in most cases function declarations (or
declarations that include function types) are better written with
prototypes.  As a rule I use compiler options that require
previously declared prototypes even for function definitions
that include a prototype.  In other cases though a non-prototype
declaration works better IME.

>> 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.
>
> How did you use one and why wasn't a regular declaration
> appropriate?

I explained this in my response to Robert Wessel.  Like I said, I
could have used prototypes rather than just (), but it would have
been more work without giving any significant value.  Not all
programming activity is working on complete code that is finished
and (just about) ready to ship.  For some of the intermediate
stages, declarations without prototypes allow reaching the goal
sooner than requiring them for all functions on every single
compile.

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

#102990

On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

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


It was depreciated in C++14, and will be removed from C++17. Trigraphs
are going away too.  Now if only traditional octal literals were done
away with too (I'd not object in the least if there were octal
literals of the form 0o1234, or something like that, but I've
essentially never seen any code with a non-zero octal literal where it
was not a mistake - although many of those were for values less than
eight, and so harmless).


>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'm curious what for?  I haven't written one in so many years that
when I found one in some old code, and had to read the manual to
figure out how part of it worked.

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

#103162

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> 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.
>
> It was depreciated in C++14, and will be removed from C++17. [...]

I assume you meant deprecated there rather than depreciated.

>> 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'm curious what for?  I haven't written one in so many years that
> when I found one in some old code, and had to read the manual to
> figure out how part of it worked.

I was compiling some code that was incomplete (eg, I had only
some of the .c files but not the .h files - I don't recall
the exact particulars).  To fix up the problem of undeclared
functions, I wrote declarations like

    int foo();
    void *bas();

which got rid of those errors without needing a lot of effort.
(And in almost all cases either 'int' or 'void *' works as a
return type.)  Of course I could have written prototypes
instead, but it would have been a lot more work without giving
much value, because it wasn't necessary for what I was trying
to do.

There are other circumstances where I find non-prototype
function types useful, but this one is what I happened
on the other day.

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

#103284

On Sat, 04 Feb 2017 11:12:11 -0800, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
>>
>>> 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.
>>
>> It was depreciated in C++14, and will be removed from C++17. [...]
>
>I assume you meant deprecated there rather than depreciated.


Of course.  I'm going to blame the spell checker.  Conveniently it
can't really defend itself.


>>> 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'm curious what for?  I haven't written one in so many years that
>> when I found one in some old code, and had to read the manual to
>> figure out how part of it worked.
>
>I was compiling some code that was incomplete (eg, I had only
>some of the .c files but not the .h files - I don't recall
>the exact particulars).  To fix up the problem of undeclared
>functions, I wrote declarations like
>
>    int foo();
>    void *bas();
>
>which got rid of those errors without needing a lot of effort.
>(And in almost all cases either 'int' or 'void *' works as a
>return type.)  Of course I could have written prototypes
>instead, but it would have been a lot more work without giving
>much value, because it wasn't necessary for what I was trying
>to do.
>
>There are other circumstances where I find non-prototype
>function types useful, but this one is what I happened
>on the other day.


Interesting.  I had a case where that would have saved some work a
couple of years ago, except for the fact that this was C++.

To simplify, there was a (quite complex) configuration file being
loaded, and it was decided to build a stand-along configuration file
validator.  Obviously we just reused the normal code that loaded the
configuration file in the actual system.  We needed to define a fair
number of stubs to allow compilation, for functions/methods that only
go invoked at runtime (after the configuration was loaded).  Many just
turned into "return NULL;" or something.  Not having to actually
specify the parameters would have saved at least a smidge of work.

Still, the actual work saved would have been modest, and had it been
allowed in C++, and had I thought of it, I suspect I still wouldn't
have done it.

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

#103511

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Sat, 04 Feb 2017 11:12:11 -0800, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>[...]
>
>>>> 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'm curious what for?  I haven't written one in so many years that
>>> when I found one in some old code, and had to read the manual to
>>> figure out how part of it worked.
>>
>> I was compiling some code that was incomplete (eg, I had only
>> some of the .c files but not the .h files - I don't recall
>> the exact particulars).  To fix up the problem of undeclared
>> functions, I wrote declarations like
>>
>>    int foo();
>>    void *bas();
>>
>> which got rid of those errors without needing a lot of effort.
>> (And in almost all cases either 'int' or 'void *' works as a
>> return type.)  Of course I could have written prototypes
>> instead, but it would have been a lot more work without giving
>> much value, because it wasn't necessary for what I was trying
>> to do.
>>
>> There are other circumstances where I find non-prototype
>> function types useful, but this one is what I happened
>> on the other day.
>
> Interesting.  I had a case where that would have saved some work a
> couple of years ago, except for the fact that this was C++.
>
> To simplify, there was a (quite complex) configuration file being
> loaded, and it was decided to build a stand-along configuration file
> validator.  Obviously we just reused the normal code that loaded the
> configuration file in the actual system.  We needed to define a fair
> number of stubs to allow compilation, for functions/methods that only
> go invoked at runtime (after the configuration was loaded).  Many just
> turned into "return NULL;" or something.  Not having to actually
> specify the parameters would have saved at least a smidge of work.
>
> Still, the actual work saved would have been modest, and had it been
> allowed in C++, and had I thought of it, I suspect I still wouldn't
> have done it.

Assuming for the moment the environment was C rather than C++, I
don't know what I would have done in the case you describe.
Certainly it is true that different circumstances favor different
choices for solutions.  This tool (ie, declaring a function type
without a prototype) is one I do find useful on occasion even if
the occasions are comparatively rare.  As I don't see much
downside for having these things in the language (because of
widely available compiler options that ferret out bad uses), I
don't see any really compelling reason to remove them.  Or, as an
alternative, change the meaning of () in C to be like it is in
C++, and supply another (and easy) way to do what () does now.  I
understand wanting to change what happens with () so there is
better type checking.  What baffles me is wanting to remove the
capability completely, rather than update it so the language
retains the benefits but lessens or gets rid of the disadvantages.

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

#103536

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
[...]
>>> 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'm curious what for?  I haven't written one in so many years that
>> when I found one in some old code, and had to read the manual to
>> figure out how part of it worked.
>
> I was compiling some code that was incomplete (eg, I had only
> some of the .c files but not the .h files - I don't recall
> the exact particulars).  To fix up the problem of undeclared
> functions, I wrote declarations like
>
>     int foo();
>     void *bas();
>
> which got rid of those errors without needing a lot of effort.
> (And in almost all cases either 'int' or 'void *' works as a
> return type.)  Of course I could have written prototypes
> instead, but it would have been a lot more work without giving
> much value, because it wasn't necessary for what I was trying
> to do.
>
> There are other circumstances where I find non-prototype
> function types useful, but this one is what I happened
> on the other day.

This is the example you offered that I vaguely referred to elsethread.

You refer to "the problem of undeclared functions".  I presume that they
were a problem because you written calls to them, and wanted to be able
to compile code containing those calls.

For example, you might have had something like:

    int main(void) {
        int n = foo("arg");
    }

That won't compile because there's no visible declaration for foo.  Your
temporary solution was to add a declaration:

    int foo();

My solution would have been to add a declaration:

    int foo(const char *s);

Is that a fair summary?  How is your solution better than mine?
(I presume that saving 13 keystrokes is not the reason.)

(I probably wouldn't even bother adding a temporary declaration.  The
compiler diagnostic for the missing declaration is a valuable reminder
and likely won;t prevent the compiler from processing the rest of the
source file.)

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

#103985

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>> On Thu, 02 Feb 2017 02:39:56 -0800, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>
> [...]
>
>>>> 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'm curious what for?  I haven't written one in so many years that
>>> when I found one in some old code, and had to read the manual to
>>> figure out how part of it worked.
>>
>> I was compiling some code that was incomplete (eg, I had only
>> some of the .c files but not the .h files - I don't recall
>> the exact particulars).  To fix up the problem of undeclared
>> functions, I wrote declarations like
>>
>>     int foo();
>>     void *bas();
>>
>> which got rid of those errors without needing a lot of effort.
>> (And in almost all cases either 'int' or 'void *' works as a
>> return type.)  Of course I could have written prototypes
>> instead, but it would have been a lot more work without giving
>> much value, because it wasn't necessary for what I was trying
>> to do.
>>
>> There are other circumstances where I find non-prototype
>> function types useful, but this one is what I happened
>> on the other day.
>
> This is the example you offered that I vaguely referred to elsethread.
>
> You refer to "the problem of undeclared functions".  I presume that they
> were a problem because you written calls to them, and wanted to be able
> to compile code containing those calls.

That may be true in some cases, but in this case the problem is
/someone else/ had written them, and I didn't have access to
other parts of the source.

> For example, you might have had something like:
>
>     int main(void) {
>         int n = foo("arg");
>     }
>
> That won't compile because there's no visible declaration for foo.  Your
> temporary solution was to add a declaration:
>
>     int foo();
>
> My solution would have been to add a declaration:
>
>     int foo(const char *s);
>
> Is that a fair summary?  How is your solution better than mine?

This assumes I know what the types of the arguments are.  I
don't.  Nor do I want to spend time pawing through the source
trying to figure out what they are, or if the types are the same
in all calls, which they may not be.  The code being worked on
may not have come out of a working program, or even one that
compiles if all the source were available.

> (I presume that saving 13 keystrokes is not the reason.)

Even in this example, 13 keystrokes more than doubles the amount
of typing needed.  For functions with multiple arguments the
overhead can be even higher.  Why should I type twice or three
times as much when it isn't needed?  Or even type by hand
anything at all?  Doing an initial compile and then running a
short awk script over the compiler output produces declarations
automatically for all non-declared functions.  It's true that
some of the return types need to be changed from 'void *' to
'int' or vice versa, but that is a lot less work than having to
type the whole declaration.

> (I probably wouldn't even bother adding a temporary declaration.  The
> compiler diagnostic for the missing declaration is a valuable reminder
> and likely won;t prevent the compiler from processing the rest of the
> source file.)

You have your preferred work modes, and I have mine.  For me any
missing-declaration diagnostics are not valuable reminders but
just noise that slows me down while I look at other diagnostics.
Different kinds of program development activities sometimes call
for different working modes.  I think you're assuming that your
normal working modes apply to all the different things I'm trying
to get done.  Sometimes that's probably true, other times maybe
not so much - it just depends.

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

#104679

On Thursday, February 16, 2017 at 3:28:37 AM UTC, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
> > (I presume that saving 13 keystrokes is not the reason.)
> 
> Even in this example, 13 keystrokes more than doubles the amount
> of typing needed.  For functions with multiple arguments the
> overhead can be even higher.  Why should I type twice or three
> times as much when it isn't needed?  Or even type by hand
> anything at all?  Doing an initial compile and then running a
> short awk script over the compiler output produces declarations
> automatically for all non-declared functions.  It's true that
> some of the return types need to be changed from 'void *' to
> 'int' or vice versa, but that is a lot less work than having to
> type the whole declaration.
>
I've never learnt to touch type.
Since I use a keyboard for a long time every single day, I have a 
pretty good idea of where they keys are. but I still hunt and peck.

But I suspect that typing is not a rate-limiting step in programming.

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

#104733

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, February 16, 2017 at 3:28:37 AM UTC, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> (I presume that saving 13 keystrokes is not the reason.)
>>
>> Even in this example, 13 keystrokes more than doubles the amount
>> of typing needed.  For functions with multiple arguments the
>> overhead can be even higher.  Why should I type twice or three
>> times as much when it isn't needed?  Or even type by hand
>> anything at all?  Doing an initial compile and then running a
>> short awk script over the compiler output produces declarations
>> automatically for all non-declared functions.  It's true that
>> some of the return types need to be changed from 'void *' to
>> 'int' or vice versa, but that is a lot less work than having to
>> type the whole declaration.
>
> I've never learnt to touch type.
> Since I use a keyboard for a long time every single day, I have a
> pretty good idea of where they keys are.  but I still hunt and peck.
>
> But I suspect that typing is not a rate-limiting step in programming.

That in no way changes the point I was making.  Time wasted
is time wasted, whether it's ten minutes or ten hours.

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

#102466

On 26/01/17 15:20, Alla _ wrote:
> On Thursday, January 26, 2017 at 4:53:30 PM UTC+3, Richard Heathfield wrote:
>> On 26/01/17 13:14, Alla _ wrote:
>>> Hello!
>>> Please, help me with this unexpected issue: for the whole
>>> day I am trying to find the problem, and I can't. I have added
>>> some information to my program, tested it, it worked; but now
>>> when only one more function left to be "turned on" in this
>>> part of the program, I get an undefined symbol error from
>>> compiler.
>>
>> It was not the compiler, but the linker, that complained. This suggests 
>> that you have a prototype for the function, and a call to the function, 
>> but not the body of the function itself.
>>
>> Check your spelling of the function name at the point where the function 
>> is defined.
>>
> Yes, the linker, sorry.
> And ... it can't get more embarrassing than this! just can't. 
> A few hours, hours, of writing, re-writing the code, copying, etc.
> Yes, a tiny misspelling - how could I miss it?! 
> And, what's even more embarrassing - for the last almost 10 
> attempts I was compiling one of the previous wrong files. Gee.
> And I had to bother people here with this stupid post - not that
> any other my posts are better; but some are much more 
> meaningful. 
> 

It looks like you are using clang as your compiler.  What compiler flags
are you using?  And are you using more than one source file but not
using a header to declare the external function(s)?  If this kind of
error is getting as far as the linker, you either have a poor choice of
compiler flags, or you are declaring external functions in your C files
rather than in a header file.  Either way, it should not be hard to
avoid such mistakes (once you know the settings to use, of course).

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

#102469

On Thursday, January 26, 2017 at 5:51:41 PM UTC+3, David Brown wrote:
> On 26/01/17 15:20, Alla _ wrote:
> > On Thursday, January 26, 2017 at 4:53:30 PM UTC+3, Richard Heathfield wrote:
> >> On 26/01/17 13:14, Alla _ wrote:
> >>> Hello!
> >>> Please, help me with this unexpected issue: for the whole
> >>> day I am trying to find the problem, and I can't. I have added
> >>> some information to my program, tested it, it worked; but now
> >>> when only one more function left to be "turned on" in this
> >>> part of the program, I get an undefined symbol error from
> >>> compiler.
> >>
> >> It was not the compiler, but the linker, that complained. This suggests 
> >> that you have a prototype for the function, and a call to the function, 
> >> but not the body of the function itself.
> >>
> >> Check your spelling of the function name at the point where the function 
> >> is defined.
> >>
> > Yes, the linker, sorry.
> > And ... it can't get more embarrassing than this! just can't. 
> > A few hours, hours, of writing, re-writing the code, copying, etc.
> > Yes, a tiny misspelling - how could I miss it?! 
> > And, what's even more embarrassing - for the last almost 10 
> > attempts I was compiling one of the previous wrong files. Gee.
> > And I had to bother people here with this stupid post - not that
> > any other my posts are better; but some are much more 
> > meaningful. 
> > 
> 
> It looks like you are using clang as your compiler.  What compiler flags
> are you using?  And are you using more than one source file but not
> using a header to declare the external function(s)?  If this kind of
> error is getting as far as the linker, you either have a poor choice of
> compiler flags, or you are declaring external functions in your C files
> rather than in a header file.  Either way, it should not be hard to
> avoid such mistakes (once you know the settings to use, of course).

Not me - Apple has changed gcc for clang. But I still use gcc command,
clang knows how to interpret that. 
-Wall -Werror -Wextra -pedantic -std=c99 ...
And no, I don't yet have any separate header files; everything is still
within one file. Headers are for later.

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

#102471

On 26/01/17 16:29, Alla _ wrote:
> On Thursday, January 26, 2017 at 5:51:41 PM UTC+3, David Brown wrote:
>> It looks like you are using clang as your compiler.  What compiler flags
>> are you using?  And are you using more than one source file but not
>> using a header to declare the external function(s)?  If this kind of
>> error is getting as far as the linker, you either have a poor choice of
>> compiler flags, or you are declaring external functions in your C files
>> rather than in a header file.  Either way, it should not be hard to
>> avoid such mistakes (once you know the settings to use, of course).
>
> Not me - Apple has changed gcc for clang. But I still use gcc command,
> clang knows how to interpret that.
> -Wall -Werror -Wextra -pedantic -std=c99 ...
> And no, I don't yet have any separate header files; everything is still
> within one file. Headers are for later.

Those flags are fine. The absence of a compiler warning suggests 
strongly, as I pointed out earlier, that you had declared a prototype 
for the function, but didn't have the function body itself.

Anyway, you now know what went wrong and why, and it seems that you've 
already fixed the problem, so all is well for the time being.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#102479

On Thursday, January 26, 2017 at 7:34:20 PM UTC+3, Richard Heathfield wrote:
> On 26/01/17 16:29, Alla _ wrote:
> > On Thursday, January 26, 2017 at 5:51:41 PM UTC+3, David Brown wrote:
> >> It looks like you are using clang as your compiler.  What compiler flags
> >> are you using?  And are you using more than one source file but not
> >> using a header to declare the external function(s)?  If this kind of
> >> error is getting as far as the linker, you either have a poor choice of
> >> compiler flags, or you are declaring external functions in your C files
> >> rather than in a header file.  Either way, it should not be hard to
> >> avoid such mistakes (once you know the settings to use, of course).
> >
> > Not me - Apple has changed gcc for clang. But I still use gcc command,
> > clang knows how to interpret that.
> > -Wall -Werror -Wextra -pedantic -std=c99 ...
> > And no, I don't yet have any separate header files; everything is still
> > within one file. Headers are for later.
> 
> Those flags are fine. The absence of a compiler warning suggests 
> strongly, as I pointed out earlier, that you had declared a prototype 
> for the function, but didn't have the function body itself.
> 
That was not the case, but as you point out further, indeed, the issue
is resolved ) Thank you )
> Anyway, you now know what went wrong and why, and it seems that you've 
> already fixed the problem, so all is well for the time being.
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

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

#102473

Alla _ <modelling.data@gmail.com> writes:
> On Thursday, January 26, 2017 at 5:51:41 PM UTC+3, David Brown wrote:
[...]
>> It looks like you are using clang as your compiler.
[snip]
>
> Not me - Apple has changed gcc for clang. But I still use gcc command,
> clang knows how to interpret that. 

Yes, you *are* using clang -- because Apple has made it inconvient not
to.  You're typing the command "gcc", and it's invoking the Clang
compiler.  (It's set up by the OS as a symlink or something similar.)

gcc and clang pretty much work alike, so it shouldn't be an issue.
(Apple set up the misleading name "gcc" to allow for scripts and
Makefile that assume the C compiler is named "gcc".)

[...]

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

#102482

On 01/26/2017 11:29 AM, Alla _ wrote:
> On Thursday, January 26, 2017 at 5:51:41 PM UTC+3, David Brown wrote:
>> On 26/01/17 15:20, Alla _ wrote:
>>> On Thursday, January 26, 2017 at 4:53:30 PM UTC+3, Richard Heathfield wrote:
....
>>>> It was not the compiler, but the linker, that complained. This suggests 
>>>> that you have a prototype for the function, and a call to the function, 
>>>> but not the body of the function itself.
>>>>
>>>> Check your spelling of the function name at the point where the function 
>>>> is defined.
>>>>
>>> Yes, the linker, sorry.
>>> And ... it can't get more embarrassing than this! just can't. 
>>> A few hours, hours, of writing, re-writing the code, copying, etc.
>>> Yes, a tiny misspelling - how could I miss it?! 
>>> And, what's even more embarrassing - for the last almost 10 
>>> attempts I was compiling one of the previous wrong files. Gee.
>>> And I had to bother people here with this stupid post - not that
>>> any other my posts are better; but some are much more 
>>> meaningful. 
>>>
>>
>> It looks like you are using clang as your compiler.  What compiler flags
>> are you using?  And are you using more than one source file but not
>> using a header to declare the external function(s)?  If this kind of
>> error is getting as far as the linker, you either have a poor choice of
>> compiler flags, or you are declaring external functions in your C files
>> rather than in a header file.  Either way, it should not be hard to
>> avoid such mistakes (once you know the settings to use, of course).
> 
> Not me - Apple has changed gcc for clang. But I still use gcc command,
> clang knows how to interpret that. 
> -Wall -Werror -Wextra -pedantic -std=c99 ...
> And no, I don't yet have any separate header files; everything is still
> within one file. Headers are for later.

If the name of a function or object is only ever used in the same
translation unit (TU) where it is defined, then it should be defined
with the static keyword, to give that name internal linkage. Why? So you
you can get an error message if that name is never used anywhere else in
the translation unit. A name that has internal linkage can only be used
within the same TU. By the time it reaches the end of the TU, if the
name has never been used, the compiler can figure out that you must have
made a mistake. A diagnostic is not mandatory, but gcc will provide one;
I suspect clang will do so too. This can protect you from a spelling
error like this one.

With the right compiler option enabled, gcc will warn you any time that
a function with external linkage function is defined without a prototype
already in scope. Why? Because there are two cases: if the function's
name will only be used in the same translation unit, it should have been
given internal linkage. If it will be used in other TUs, it should be
declared in a separate header file that is #included both in the TU
where it is defined, and also in every other TU where the function's
name is used.

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

#102483

On Thursday, January 26, 2017 at 12:53:24 PM UTC-6, James Kuyper wrote:
> With the right compiler option enabled, gcc will warn you any time that
> a function with external linkage function is defined without a prototype
> already in scope. Why? Because there are two cases: if the function's
> name will only be used in the same translation unit, it should have been
> given internal linkage. If it will be used in other TUs, it should be
> declared in a separate header file that is #included both in the TU
> where it is defined, and also in every other TU where the function's
> name is used.

Failure to use a declared static identifier should not always be
considered indicative of a problem.  If a source file uses compilation
flags to select various configuration options, and a function is required
for some combinations of options but not others, one could do something
like:

    #if defined(fooble) || (defined(woozle) && defined(wizzle)) || \
        (defined(foo) && (defined(moo) || defined(goo))
    static void wazoo(int whatever) ...
    {
    }
    #endif

but it would be more practical to have a compiler generate the source for
the function if it's needed, and omit the function if it's not.

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

#102503

On 26/01/17 17:29, Alla _ wrote:

> Not me - Apple has changed gcc for clang. But I still use gcc command,
> clang knows how to interpret that.
> -Wall -Werror -Wextra -pedantic -std=c99 ...

(As has been pointed out, you /are/ using clang.  clang accepts pretty 
much the same set of flags as gcc.  The list I give below is for gcc, 
based on the flag sets I use - I hope they match clang here.)

Those flags are fine as a starting point - but you can get more help 
from your compiler with more flags.  Because different people write code 
in different ways, and some warnings trigger on legal C that some people 
think is perfectly good, additional warnings are not included in the 
"-Wall -Wextra" sets.  It is up to the individual programmer (or project 
manager, etc.) to decide the details here.  But here are a few 
suggestions for additional or alternative flags that you might find 
helpful - I certainly do:


Consider using -std=c11.  For the kind of code you are writing, c11 does 
not add much - but it is the current standard.  The key benefit that I 
see is the _Static_assert() feature.  Personally, I have no use for 
"-pedantic" and prefer "-std=gnu11" because I feel the gcc extensions 
let me write better and safer code - but for learning, it is best to 
stick as close as possible to the standards with -pedantic.


Additional warning flags:

-Wlogical-op (Warns about odd-looking uses of logical operators)

-Wredundant-decls (Warns about duplicate declarations)

-Wmissing-prototypes -Wmissing-declarations (With these in place, your 
functions need to be either "static", or have a declarations before the 
definition - typically in a header)

-Wundef (Warn if an undefined identifier is used in an #if directive)

-Wnull-dereference (Warn if the compiler can spot a null deference when 
optimisation is on)

-Wduplicated-branches -Wduplicated-cond (Warn about branches and 
conditionals that have the duplicates)

-Wcast-qual -Wcast-align (Warn about some possible bad casts)

I also recommend using -O1 to enable optimisation - it also enables 
better code analysis, and therefore better static error checking.

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

#102525

On Friday, January 27, 2017 at 1:50:09 AM UTC+3, David Brown wrote:
> On 26/01/17 17:29, Alla _ wrote:
> 
> > Not me - Apple has changed gcc for clang. But I still use gcc command,
> > clang knows how to interpret that.
> > -Wall -Werror -Wextra -pedantic -std=c99 ...
> 
> (As has been pointed out, you /are/ using clang.  clang accepts pretty 
> much the same set of flags as gcc.  The list I give below is for gcc, 
> based on the flag sets I use - I hope they match clang here.)
> 
> Those flags are fine as a starting point - but you can get more help 
> from your compiler with more flags.  Because different people write code 
> in different ways, and some warnings trigger on legal C that some people 
> think is perfectly good, additional warnings are not included in the 
> "-Wall -Wextra" sets.  It is up to the individual programmer (or project 
> manager, etc.) to decide the details here.  But here are a few 
> suggestions for additional or alternative flags that you might find 
> helpful - I certainly do:
> 
> 
> Consider using -std=c11.  For the kind of code you are writing, c11 does 
> not add much - but it is the current standard.  The key benefit that I 
> see is the _Static_assert() feature.  Personally, I have no use for 
> "-pedantic" and prefer "-std=gnu11" because I feel the gcc extensions 
> let me write better and safer code - but for learning, it is best to 
> stick as close as possible to the standards with -pedantic.
> 
> 
> Additional warning flags:
> 
> -Wlogical-op (Warns about odd-looking uses of logical operators)
> 
> -Wredundant-decls (Warns about duplicate declarations)
> 
> -Wmissing-prototypes -Wmissing-declarations (With these in place, your 
> functions need to be either "static", or have a declarations before the 
> definition - typically in a header)
> 
> -Wundef (Warn if an undefined identifier is used in an #if directive)
> 
> -Wnull-dereference (Warn if the compiler can spot a null deference when 
> optimisation is on)
> 
> -Wduplicated-branches -Wduplicated-cond (Warn about branches and 
> conditionals that have the duplicates)
> 
> -Wcast-qual -Wcast-align (Warn about some possible bad casts)
> 
> I also recommend using -O1 to enable optimisation - it also enables 
> better code analysis, and therefore better static error checking.

What a wonderful list! Thank you so much. 

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

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

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

csiph-web