Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #102457 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2017-01-26 05:14 -0800 |
| Last post | 2017-01-27 01:26 -0800 |
| Articles | 20 on this page of 83 — 15 participants |
Back to article view | Back to comp.lang.c
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 1 of 5 [1] 2 3 4 5 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-26 05:14 -0800 |
| Subject | How to find the problem in the object file |
| Message-ID | <23ab01a2-5220-42cb-80b2-20a2b4a35d5c@googlegroups.com> |
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.
This function has worked perfectly previously. And it did
work perfectly with just the same combination - the program
called it from the same exact place, nothing new; but the
compiler is not happy.
Here is the message I get:
Undefined symbols for architecture x86_64:
"_assumptions_rates_1", referenced from:
_process_inc in nam_num_23ofstest-a590c3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
How can I find that place nam_num_23ofstest-a590c3.o in the object file?
I assume a590c3 is the address, am I right?
Here is the combination, which, I assume based on compiler's message,
causes the mistake:
if( parse_inc_num(token_inc, line_num1, offset_ptr->offset_income, offset_ptr->offset_cs_income, income_ptr, cs_income_ptr, &member_sum) )
{
assumptions_rates_1(offset_ptr->offset_rates, cs_income_ptr, rates, line_num1, member_sum);
}
Thank you very much!
[toc] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-26 13:22 +0000 |
| Message-ID | <o6ct3t$nmc$1@dont-email.me> |
| In reply to | #102457 |
On 26/01/2017 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.
> This function has worked perfectly previously. And it did
> work perfectly with just the same combination - the program
> called it from the same exact place, nothing new; but the
> compiler is not happy.
> Here is the message I get:
>
> Undefined symbols for architecture x86_64:
> "_assumptions_rates_1", referenced from:
> _process_inc in nam_num_23ofstest-a590c3.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> How can I find that place nam_num_23ofstest-a590c3.o in the object file?
> I assume a590c3 is the address, am I right?
>
> Here is the combination, which, I assume based on compiler's message,
> causes the mistake:
>
> if( parse_inc_num(token_inc, line_num1, offset_ptr->offset_income, offset_ptr->offset_cs_income, income_ptr, cs_income_ptr, &member_sum) )
> {
> assumptions_rates_1(offset_ptr->offset_rates, cs_income_ptr, rates, line_num1, member_sum);
> }
Where is assumptions_rates_1 defined? Is it spelled exactly the same as
this?
Is that file included in the linking?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-26 13:37 +0000 |
| Message-ID | <o6ctvc$qju$1@dont-email.me> |
| In reply to | #102458 |
On 26/01/2017 13:22, BartC wrote: > On 26/01/2017 13:14, Alla _ wrote: >> Undefined symbols for architecture x86_64: >> "_assumptions_rates_1", referenced from: >> _process_inc in nam_num_23ofstest-a590c3.o >> assumptions_rates_1(offset_ptr->offset_rates, cs_income_ptr, rates, >> line_num1, member_sum); >> } > > > Where is assumptions_rates_1 defined? Is it spelled exactly the same as > this? > > Is that file included in the linking? I've just noticed the "_" on the undefined symbols. That tends to be added on global symbols on 32-bit Windows. I don't know if that applies to your Mac but it might be worth checking all modules have been compiled in 64-bit mode if that's what you're using. But you don't want to be poking around inside object files; there will be a simple explanation! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-26 13:53 +0000 |
| Message-ID | <o6cut4$tfv$1@dont-email.me> |
| In reply to | #102457 |
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. -- 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]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-26 06:20 -0800 |
| Message-ID | <2beebc58-3f8f-46c6-bd10-e2ec3cf87906@googlegroups.com> |
| In reply to | #102460 |
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.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-26 14:28 +0000 |
| Message-ID | <o6d0uj$5kt$1@dont-email.me> |
| In reply to | #102461 |
On 26/01/2017 14: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?! Either your compiler is at fault or it's not set up properly to report undeclared functions. And blame the language for allowing undeclared functions to go undiagnosed by the compiler. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-26 06:48 -0800 |
| Message-ID | <7222f2bf-18c5-4afe-a22b-48a6e8caf426@googlegroups.com> |
| In reply to | #102462 |
On Thursday, January 26, 2017 at 5:28:23 PM UTC+3, Bart wrote: > On 26/01/2017 14: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?! > > Either your compiler is at fault or it's not set up properly to report > undeclared functions. And blame the language for allowing undeclared > functions to go undiagnosed by the compiler. I recall that there were many times when it did complain about such issues; I have no idea what could go wrong this time, apart from my missing the stupid mistake.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-26 08:29 -0800 |
| Message-ID | <lnfuk5eqeg.fsf@kst-u.example.com> |
| In reply to | #102462 |
BartC <bc@freeuk.com> writes:
> On 26/01/2017 14: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?!
>
> Either your compiler is at fault or it's not set up properly to report
> undeclared functions. And blame the language for allowing undeclared
> functions to go undiagnosed by the compiler.
Not necessarily. It's possible *and legal* to call a function
that's been declared but not defined. For example, this source
file / translation unit:
void not_defined(void);
int main(void) {
not_defined();
}
is perfectly valid, and a compiler has no reason to complain about
it, but it won't *link* unless you provide the linker with something
that defines the function.
Normally the function declaration should be in an included header
file, but that doesn't affect the issue.
--
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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-26 16:54 +0000 |
| Message-ID | <o6d9gm$7qm$1@dont-email.me> |
| In reply to | #102470 |
On 26/01/2017 16:29, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 26/01/2017 14: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?!
>>
>> Either your compiler is at fault or it's not set up properly to report
>> undeclared functions. And blame the language for allowing undeclared
>> functions to go undiagnosed by the compiler.
>
> Not necessarily. It's possible *and legal* to call a function
> that's been declared but not defined. For example, this source
> file / translation unit:
>
> void not_defined(void);
>
> int main(void) {
> not_defined();
> }
>
> is perfectly valid, and a compiler has no reason to complain about
> it, but it won't *link* unless you provide the linker with something
> that defines the function.
I was talking about compilation rather than linking. If your example was:
void not_defined(void);
int main(void) {
notdefined();
}
then the compiler might not say anything about 'notdefined'. Then a
subsequent linker error would be ambiguous; has a module been omitted,
or is there a typo somewhere?
But yes, there could be another type of error, I think less common,
where the name of the function in the declaration, and in the call, are
both misspelled the same way, and different from the actual definition.
This would be a consequence of having to specify the function name at
least twice, once for the definition, again for the header. But every
time I'm brought up this as a possible source of errors, I've been
assured that it's not a problem...
Yet another kind of error that the latter can cause, possibly the most
serious, is where the name in the definition, and in the call (in
another module) are both spelled correctly, but the declaration in the
header is wrong.
It will compile 'correctly', if the compiler doesn't report it, and it
will likely link properly, but the program can now crash if the caller
thinks the interface is different from it is.
(On my gcc, it will give a warning about 'implicit declaration', which
it is possible can be missed if there are many other warnings or some
automatic build system is in use that doesn't abort on warnings.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-01-26 09:01 -0800 |
| Message-ID | <a45a3826-82ac-4dda-a571-5a87bf91890c@googlegroups.com> |
| In reply to | #102474 |
On Thursday, January 26, 2017 at 10:54:25 AM UTC-6, Bart wrote: > This would be a consequence of having to specify the function name at > least twice, once for the definition, again for the header. But every > time I'm brought up this as a possible source of errors, I've been > assured that it's not a problem... I don't recall anyone saying that. But there exist solutions (well, conventions), but new proposed solutions have the extreme disadvantage that they do not as yet exist. So any ease of use advantage that a new solution might have is also measured against the work of rewriting, retraining, and rethinking over all the issues.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-26 11:20 -0800 |
| Message-ID | <ln37g5eihq.fsf@kst-u.example.com> |
| In reply to | #102474 |
BartC <bc@freeuk.com> writes:
> On 26/01/2017 16:29, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
[...]
>>> Either your compiler is at fault or it's not set up properly to report
>>> undeclared functions. And blame the language for allowing undeclared
>>> functions to go undiagnosed by the compiler.
>>
>> Not necessarily. It's possible *and legal* to call a function
>> that's been declared but not defined. For example, this source
>> file / translation unit:
>>
>> void not_defined(void);
>>
>> int main(void) {
>> not_defined();
>> }
>>
>> is perfectly valid, and a compiler has no reason to complain about
>> it, but it won't *link* unless you provide the linker with something
>> that defines the function.
>
> I was talking about compilation rather than linking.
Why? Alla reported a link-time error, and she later said that she had
been compiling the wrong source file(s).
> If your example was:
>
> void not_defined(void);
>
> int main(void) {
> notdefined();
> }
then it would be an example of an entirely different problem.
> then the compiler might not say anything about 'notdefined'.
A C90 or non-conforming compiler might not say anything. A conforming
C99 or C11 compiler will at least warn about it -- including the one
Alla is using.
> Then a
> subsequent linker error would be ambiguous; has a module been omitted,
> or is there a typo somewhere?
That kind of problem is exactly why the language was changed in 1999 to
disallow calls to undeclared functions (more precisely, to make such
calls constraint violations, requiring a diagnostic).
> But yes, there could be another type of error, I think less common,
> where the name of the function in the declaration, and in the call, are
> both misspelled the same way, and different from the actual definition.
Again, not the problem Alla was asking about.
> This would be a consequence of having to specify the function name at
> least twice, once for the definition, again for the header. But every
> time I'm brought up this as a possible source of errors, I've been
> assured that it's not a problem...
It usually isn't, but making it not a problem requires a little
discipline. If the source file that *defines* a function has a #include
for the header that *declares* it, then the compiler is able to diagnose
any mismatch. Mistakes are of course possible, but they typically won't
survive past the first attempt to compile the code.
> Yet another kind of error that the latter can cause, possibly the most
> serious, is where the name in the definition, and in the call (in
> another module) are both spelled correctly, but the declaration in the
> header is wrong.
>
> It will compile 'correctly', if the compiler doesn't report it, and it
> will likely link properly, but the program can now crash if the caller
> thinks the interface is different from it is.
If the definition is not visible at the point of the call, and the
visible declaration doesn't match the call, then that's a constraint
violation (for C99 or later), requiring a diagnostic.
> (On my gcc, it will give a warning about 'implicit declaration', which
> it is possible can be missed if there are many other warnings or some
> automatic build system is in use that doesn't abort on warnings.)
One thing I dislike about gcc is that, by default, many constraint
violation diagnostics are non-fatal warnings rather than fatal errors.
But it's easy enough to invoke it with options that tell it to treat
them as fatal errors, such as "-std=c11 -pedantic-errors".
If you're getting so many warnings that you miss important ones, perhaps
you code needs some cleanup. Or, if the excess warnings really are
ones that can be safely ignored, you might try to find a way to disable
them. Figuring out how to enable just the diagnostics you want, and how
to make them fatal if desired, can be more difficult than it should be,
but that's a compiler issue, not a language issue.
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-26 23:12 +0100 |
| Message-ID | <o6ds65$18e$1@dont-email.me> |
| In reply to | #102474 |
On 26/01/17 17:54, BartC wrote: > But yes, there could be another type of error, I think less common, > where the name of the function in the declaration, and in the call, are > both misspelled the same way, and different from the actual definition. > > This would be a consequence of having to specify the function name at > least twice, once for the definition, again for the header. But every > time I'm brought up this as a possible source of errors, I've been > assured that it's not a problem... That /can/ be a problem. Many, many years ago, the gcc developers realised that it can be a problem for some people - and they helpfully added warnings "-Wmissing-prototypes" and "-Wmissing-declarations" to spot this situation. The warnings are optional, because some people don't like to have to declare their (non-static) functions before defining them, but for many people the warnings are a simple check for such typos. Many other compilers no doubt have similar warnings. So while I think it would be nice if the language made this sort of thing an error in some way, I find it is no problem in practice when you use tools designed to help spot errors.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-27 01:32 +0000 |
| Message-ID | <o6e7sl$blj$1@dont-email.me> |
| In reply to | #102502 |
On 26/01/2017 22:12, David Brown wrote: > On 26/01/17 17:54, BartC wrote: > >> But yes, there could be another type of error, I think less common, >> where the name of the function in the declaration, and in the call, are >> both misspelled the same way, and different from the actual definition. >> >> This would be a consequence of having to specify the function name at >> least twice, once for the definition, again for the header. But every >> time I'm brought up this as a possible source of errors, I've been >> assured that it's not a problem... > > That /can/ be a problem. Many, many years ago, the gcc developers > realised that it can be a problem for some people - and they helpfully > added warnings "-Wmissing-prototypes" and "-Wmissing-declarations" to > spot this situation. The warnings are optional, because some people > don't like to have to declare their (non-static) functions before > defining them, How does that work? How does the compiler know what the function interface is? I can't believe that people are happy with it just assuming arguments and return value are all ints; suppose that assumption is wrong - or changes? but for many people the warnings are a simple check for > such typos. Many other compilers no doubt have similar warnings. > > So while I think it would be nice if the language made this sort of > thing an error in some way, Neither can I believe that gcc doesn't have an option to turn such a warning into an actual error. (All the tools I create can /only/ report errors; never warnings. It's stricter but it pays off.0 -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-27 09:50 +0100 |
| Message-ID | <o6f1h9$3qb$1@dont-email.me> |
| In reply to | #102508 |
On 27/01/17 02:32, BartC wrote:
> On 26/01/2017 22:12, David Brown wrote:
>> On 26/01/17 17:54, BartC wrote:
>>
>>> But yes, there could be another type of error, I think less common,
>>> where the name of the function in the declaration, and in the call, are
>>> both misspelled the same way, and different from the actual definition.
>>>
>>> This would be a consequence of having to specify the function name at
>>> least twice, once for the definition, again for the header. But every
>>> time I'm brought up this as a possible source of errors, I've been
>>> assured that it's not a problem...
>>
>> That /can/ be a problem. Many, many years ago, the gcc developers
>> realised that it can be a problem for some people - and they helpfully
>> added warnings "-Wmissing-prototypes" and "-Wmissing-declarations" to
>> spot this situation. The warnings are optional, because some people
>> don't like to have to declare their (non-static) functions before
>> defining them,
>
> How does that work? How does the compiler know what the function
> interface is? I can't believe that people are happy with it just
> assuming arguments and return value are all ints; suppose that
> assumption is wrong - or changes?
Why would you possibly think that? What part of the flag name
"-Wmissing-prototypes" - "Warn on missing /prototypes/" - makes you
think that this works by allowing prototypes to be missing and assumed
to be all int-to-int functions? What part of my description makes you
think these /additional/ warnings takes modern C standards and /reduces/
code correctness safety to pre-C90 levels?
Together with a little discipline about headers, these two warnings trap
code that looks okay, but has inconsistencies due to typos in function
names. Consider code like this:
// foo.h
char func(int a, double b); // <- name 1
// foo.c
#include "foo.h"
char func(int a, double b) // <- name 2
{ ... }
// bar.c
#include "foo.h"
void bar(void) {
char x = func(1, 3.0); // <- name 3
...
}
This is a very common way of structuring your code layout. C99 will
give you a warning or error if name 3 does not match name 1 - you are
trying to use a function without a prototype. But there is no check
that name 2 matches name 1 - just a check that the declarations are
compatible if the names /do/ match.
Adding the warnings above means that gcc will complain when it sees the
definition of func in foo.c if it has not previously seen a prototype
declarations - i.e., if name 2 does not match name 1.
The exception is for "static" functions, which are accepted without
needing an additional prototype declaration (though you can have one if
you want, obviously).
The combined effect is therefore to enforce at the /compiler/ level that
names 1, 2, and 3 all match.
However, because some people prefer to write their code without this
strict structure, these warnings are options that must be specified by
the user.
>
>> but for many people the warnings are a simple check for
>> such typos. Many other compilers no doubt have similar warnings.
>>
>> So while I think it would be nice if the language made this sort of
>> thing an error in some way,
>
> Neither can I believe that gcc doesn't have an option to turn such a
> warning into an actual error.
Of course gcc has an option to turn this warning (and any other warnings
you like) into an error. But the C language, as given in the standards,
does not require such checking.
>
> (All the tools I create can /only/ report errors; never warnings. It's
> stricter but it pays off.0
>
I usually have "-Werror" to turn warnings into errors in gcc. But there
may be occasions where warnings give false positives and people would
prefer to allow a few such warnings without stopping code generation.
In particular, code commonly has a lot of warnings during early development.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-26 09:19 -0800 |
| Message-ID | <a84e9771-1ae7-4e4f-9602-259e6c25a7ce@googlegroups.com> |
| In reply to | #102470 |
On Thursday, January 26, 2017 at 10:29:18 AM UTC-6, Keith Thompson wrote:
> Not necessarily. It's possible *and legal* to call a function
> that's been declared but not defined. For example, this source
> file / translation unit:
>
> void not_defined(void);
>
> int main(void) {
> not_defined();
> }
Or even
void barely_defined();
int main(int argc, char *argv[]) {
barely_defined(42);
}
A compiler would have no way of knowing whether "barely_defined" was
expecting to receive one argument of type "int", and the lack of a
prototype would prevent it from performing any conversion that would be
necessary if the function expected a some other numeric type, but the
presence of a definition would make the above code defined under the
Standard if the proper function exists in another translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-26 11:21 -0800 |
| Message-ID | <lny3xxd3ul.fsf@kst-u.example.com> |
| In reply to | #102476 |
supercat@casperkitty.com writes:
> On Thursday, January 26, 2017 at 10:29:18 AM UTC-6, Keith Thompson wrote:
>> Not necessarily. It's possible *and legal* to call a function
>> that's been declared but not defined. For example, this source
>> file / translation unit:
>>
>> void not_defined(void);
>>
>> int main(void) {
>> not_defined();
>> }
>
> Or even
>
> void barely_defined();
>
> int main(int argc, char *argv[]) {
> barely_defined(42);
> }
[...]
Yes, it's IMHO infortunate that the language still allows non-prototype
function declarations and definitions. The solution is fairly simple:
always use prototypes. (This isn't the problem Alla was asking about.)
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-02 02:39 -0800 |
| Message-ID | <kfnfujwc1vn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102487 |
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.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-02 04:08 -0800 |
| Message-ID | <b92ddd89-a93f-4e22-b9d8-0a06132908d2@googlegroups.com> |
| In reply to | #102954 |
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?
on right side candidates are mostly main(void)
and main(...) especially main(void)
[the options in fact could be a bit more - i mean,
there could be a bit more options in fact, esp im thinking about void main(a) declaration where a could
be like a generic - one could also consider promoting byte[] type ]
on left side the candidates would be mostly
void main(), int main(), and ... main()
(where by ... main() i mean main my return
various data)
in fact there are also options when
foo()
{
}
could describe states where functions could
return nothing or int or for example float too
like
foo1(){}
foo2(){return 1;}
foo3(){return 1.1;}
main()
{
foo1();
int n = foo2();
int m = foo3(); //return float
}
that would just spare a bit of writing (return type deduced from function body)
this can be even considered,
im not decided which one i would like to have here
though could say that default int is probably not
much good for me
i would better understand if main() would default to
void main(void) though on the other side the deduced
version seem to have also some tradition
(though it is conceptually harder, old c braks levels
like in physics they say somethin breaks the symetry
spontanueusly)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-02 04:31 -0800 |
| Message-ID | <74887dd3-85de-4393-9330-5aa6e5941ca6@googlegroups.com> |
| In reply to | #102955 |
W dniu czwartek, 2 lutego 2017 13:08:38 UTC+1 użytkownik fir napisał:
> 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?
>
> on right side candidates are mostly main(void)
> and main(...) especially main(void)
>
> [the options in fact could be a bit more - i mean,
> there could be a bit more options in fact, esp im thinking about void main(a) declaration where a could
> be like a generic - one could also consider promoting byte[] type ]
>
>
>
> on left side the candidates would be mostly
> void main(), int main(), and ... main()
> (where by ... main() i mean main my return
> various data)
>
> in fact there are also options when
>
> foo()
> {
>
> }
>
> could describe states where functions could
> return nothing or int or for example float too
>
> like
>
> foo1(){}
> foo2(){return 1;}
> foo3(){return 1.1;}
>
> main()
> {
> foo1();
> int n = foo2();
> int m = foo3(); //return float
> }
>
> that would just spare a bit of writing (return type deduced from function body)
>
> this can be even considered,
> im not decided which one i would like to have here
>
> though could say that default int is probably not
> much good for me
>
> i would better understand if main() would default to
> void main(void) though on the other side the deduced
> version seem to have also some tradition
>
> (though it is conceptually harder, old c braks levels
> like in physics they say somethin breaks the symetry
> spontanueusly)
this plane is broken just by defaulting btw here
id do not gives much but may be the option to considering
even if skip those type deductions here there is also
a problem
if
main()
I. should defaults to void main() (where both could be used)
II. or maybe void word should be forbidden (as not necessary) or
III. empty space should be also forbidden here (as void would look more uniform)
got no much idea, i seem to be closer that it probably could be most usable if would mean type is deduced (oldschool way) but not decided here, it seem somewhat risky and really oldschool
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-04 10:48 -0800 |
| Message-ID | <kfnefzd94h4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102955 |
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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web