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

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

Error messages

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

Contents

  Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 02:36 +0200
    Re: Error messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:51 +0100
      Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-16 18:24 -0700
        Re: Error messages Lőrinczy Zsigmond <nospam@for.me> - 2015-07-17 09:31 +0200
          Re: Error messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 08:35 +0100
            Re: Error messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-17 09:11 +0000
              Re: Error messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 10:30 +0100
              Re: Error messages Ian Collins <ian-news@hotmail.com> - 2015-07-17 21:44 +1200
                Re: Error messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 12:55 +0100
                Re: Error messages Melzzzzz <mel@zzzzz.com> - 2015-07-17 19:53 +0200
                Re: Error messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-17 17:55 +0000
                  Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-17 14:19 -0400
              Re: Error messages raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:44 +0000
          Re: Error messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-17 07:38 +0000
            Re: Error messages Noob <root@127.0.0.1> - 2015-07-17 09:58 +0200
              Re: Error messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-17 13:32 +0000
        Re: Error messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 11:13 +0100
    Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-16 22:36 -0400
    Re: Error messages Reinhardt Behm <rbehm@hushmail.com> - 2015-07-17 13:05 +0800
      Re: Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 09:48 +0200
        Re: Error messages David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 19:23 -0700
          Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-17 21:24 -0700
            Re: Error messages David Kleinecke <dkleinecke@gmail.com> - 2015-07-18 18:29 -0700
              Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-18 20:59 -0700
                Re: Error messages David Kleinecke <dkleinecke@gmail.com> - 2015-07-19 19:22 -0700
              Re: Error messages David Brown <david.brown@hesbynett.no> - 2015-07-21 11:40 +0200
                Compiler conformance (Was: Error messages) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-21 11:40 +0000
                  Re: Compiler conformance Noob <root@127.0.0.1> - 2015-07-21 14:01 +0200
                    Re: Compiler conformance gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-21 13:47 +0000
          Re: Error messages Reinhardt Behm <rbehm@hushmail.com> - 2015-07-18 13:38 +0800
      Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-17 07:54 -0700
        Re: Error messages raltbos@xs4all.nl (Richard Bos) - 2015-07-19 22:00 +0000
          Re: Error messages Richard Damon <Richard@Damon-Family.org> - 2015-07-19 19:47 -0400
    Re: Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 10:06 +0200
    Re: Error messages Bartc <bc@freeuk.com> - 2015-07-17 12:07 +0100
    Re: Error messages Noob <root@127.0.0.1> - 2015-07-17 13:14 +0200
      Re: Error messages Bartc <bc@freeuk.com> - 2015-07-17 12:40 +0100
    Re: Error messages gwowen <gwowen@gmail.com> - 2015-07-17 04:32 -0700
      Re: Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 14:15 +0200
        Re: Error messages gwowen <gwowen@gmail.com> - 2015-07-17 05:25 -0700
          Re: Error messages Bartc <bc@freeuk.com> - 2015-07-17 13:34 +0100
            Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-17 08:07 -0700
          Re: Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 14:38 +0200
            Re: Error messages Martin Shobe <martin.shobe@yahoo.com> - 2015-07-17 08:50 -0500
              Re: Error messages jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-17 16:08 +0200
                Re: Error messages Martin Shobe <martin.shobe@yahoo.com> - 2015-07-17 09:24 -0500
                  Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-17 12:26 -0400
                    Re: Error messages Martin Shobe <martin.shobe@yahoo.com> - 2015-07-17 13:19 -0500
                      Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-17 14:28 -0400
                        Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-17 14:43 -0400
                          Re: Error messages Bartc <bc@freeuk.com> - 2015-07-17 20:31 +0100
                        Re: Error messages Martin Shobe <martin.shobe@yahoo.com> - 2015-07-18 08:41 -0500
                    Re: Error messages David Brown <david.brown@hesbynett.no> - 2015-07-21 12:25 +0200
                      Re: Error messages James Kuyper <jameskuyper@verizon.net> - 2015-07-21 13:20 -0400
                        Re: Error messages David Brown <david.brown@hesbynett.no> - 2015-07-22 00:05 +0200
            Re: Error messages Noob <root@127.0.0.1> - 2015-07-17 16:16 +0200
              Re: Error messages doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-17 14:49 +0000
                Re: Error messages Noob <root@127.0.0.1> - 2015-07-17 20:02 +0200
                  Re: Error messages The Doctor <doctor@doctor.nl2k.ab.ca> - 2015-07-17 22:24 +0000
                    Re: Error messages Noob <root@127.0.0.1> - 2015-07-20 10:46 +0200
                      Re: Error messages doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-20 14:59 +0000
            Re: Error messages Keith Thompson <kst-u@mib.org> - 2015-07-17 08:25 -0700
        Re: Error messages raltbos@xs4all.nl (Richard Bos) - 2015-07-19 22:07 +0000
    Re: Error messages Ed Prochak <edprochak@gmail.com> - 2015-07-17 20:11 -0700

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

#65824

On Friday, July 17, 2015 at 12:49:03 AM UTC-7, jacobnavia wrote:
> Le 17/07/2015 07:05, Reinhardt Behm a écrit :
> > jacobnavia wrote:
> >
> >> FILE c:\lcc\include64\stdio.h 123
> >>
> >> and when emitting the error message the compiler could improve it to
> >>
> >> "Missing <stdio.h> Identifier 'FILE ' is not defined.
> >> Include stdio.h and proceed.
> >>
> >> This will cost me around 1 day development, and 1 day testing. Is that
> >> still possible for gcc and c++?
> >>
> >> I think that I could do that improvement to gcc's C front end, but the
> >> C++ front end?
> >>
> >> Impossible.
> >
> > True, it is impossible.
> >
> > You want the compiler to _your_ job to specify what has to be included.
> >  From where should the compiler know what "FILE" means and where it is
> > defined?
> >
> > Instead of the usual definition in stdio.h "FILE" could be the definition of
> > a structure to hold the flight path of the New Horizon spacecraft. And this
> > definition is in a file that you not only forgot to include but even forgot
> > to download from that server in Mongolia which is only online when the moon
> > rises over the horizon.
> >
> 
> Sure...
> 
> Who cares?
> 
> People that are redefining parts of the language (as they have the right 
> to do so) can ignore this message!
> 
> They WILL KNOW however that FILE is being used without being defined. 
> Much better than "syntax error" or even "parse error"!!!

A compiler implementation could have a dictionary of all the identifiers
in the Standard Library (and feel free to extend to any other units 
you like) so that if it sees an identifier in a position where it is not
being declared it could search for the identifier in the dictionary and 
add the needed header before proceeding. The compiler must emit a 
message (warning?) teeling you what it did.  

Anybody ever done that?

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

#65828

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> A compiler implementation could have a dictionary of all the identifiers
> in the Standard Library (and feel free to extend to any other units 
> you like) so that if it sees an identifier in a position where it is not
> being declared it could search for the identifier in the dictionary and 
> add the needed header before proceeding. The compiler must emit a 
> message (warning?) teeling you what it did.  
>
> Anybody ever done that?

Certainly.

$ cat c.c
int main(void) {
    printf("hello\n");
}
$ c gcc -c c.c
c.c: In function 'main':
c.c:2:5: warning: incompatible implicit declaration of built-in function
'printf' [enabled by default]
     printf("hello\n");
     ^
$ 

It happens to do this for "printf" but not for FILE -- though if you
write

    FILE *tmp;

without the proper #include, it does recognize that it's a type name.

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

#65877

On Friday, July 17, 2015 at 9:25:01 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > A compiler implementation could have a dictionary of all the identifiers
> > in the Standard Library (and feel free to extend to any other units 
> > you like) so that if it sees an identifier in a position where it is not
> > being declared it could search for the identifier in the dictionary and 
> > add the needed header before proceeding. The compiler must emit a 
> > message (warning?) teeling you what it did.  
> >
> > Anybody ever done that?
> 
> Certainly.
> 
> $ cat c.c
> int main(void) {
>     printf("hello\n");
> }
> $ c gcc -c c.c
> c.c: In function 'main':
> c.c:2:5: warning: incompatible implicit declaration of built-in function
> 'printf' [enabled by default]
>      printf("hello\n");
       ^

Well at least it recognized that "printf" was a library (built-in!)
function. It didn't, as I asked, correct the code and continue. The 
error description is very confusing. At that position the statement 
cannot be a function declaration because it's inside a compound 
statement. The compliler seems to think it is the old (now dropped) 
form of a function definition.

But it does not make the easy repair and continue.

> It happens to do this for "printf" but not for FILE -- though if you
> write
> 
>     FILE *tmp;
> 
> without the proper #include, it does recognize that it's a type name.
 
It sounds like the libraray identifier data base may only cover
function names. It is inconvenient for me to run a test just now -
does it recognize a macro, say, EOF or NULL, without an #include?  

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

#65881

David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, July 17, 2015 at 9:25:01 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > A compiler implementation could have a dictionary of all the identifiers
>> > in the Standard Library (and feel free to extend to any other units 
>> > you like) so that if it sees an identifier in a position where it is not
>> > being declared it could search for the identifier in the dictionary and 
>> > add the needed header before proceeding. The compiler must emit a 
>> > message (warning?) teeling you what it did.  
>> >
>> > Anybody ever done that?
>> 
>> Certainly.
>> 
>> $ cat c.c
>> int main(void) {
>>     printf("hello\n");
>> }
>> $ c gcc -c c.c
>> c.c: In function 'main':
>> c.c:2:5: warning: incompatible implicit declaration of built-in function
>> 'printf' [enabled by default]
>>      printf("hello\n");
>        ^
>
> Well at least it recognized that "printf" was a library (built-in!)
> function. It didn't, as I asked, correct the code and continue. The 
> error description is very confusing. At that position the statement 
> cannot be a function declaration because it's inside a compound 
> statement. The compliler seems to think it is the old (now dropped) 
> form of a function definition.

Yes, that's what the error message indicates.  gcc is using the old
"implicit int" rule (but with a warning).  It needs to be able to
recognize it because it still supports C90.  I'm not 100% happy with the
way it does this (even with "-std=c99" or "-std=c11"), but it doesn't
seem to affect anything other than the wording of diagnostics.

> But it does not make the easy repair and continue.

I missed the part where you suggested the compiler should add the needed
header.

Personally, I'm glad it doesn't.  I presume you're not suggesting that
the compiler should modify the source file.  But even having the
compiler *assume* the presence of a missing #include would encourage
sloppy coding.  IMHO gcc is too lax as it is.

>> It happens to do this for "printf" but not for FILE -- though if you
>> write
>> 
>>     FILE *tmp;
>> 
>> without the proper #include, it does recognize that it's a type name.
>  
> It sounds like the libraray identifier data base may only cover
> function names. It is inconvenient for me to run a test just now -
> does it recognize a macro, say, EOF or NULL, without an #include?  

I suspect the existing behavior is based on C90 rules, where functions
declarations may be omitted but other declarations cannot.

I suppose it would be nice if gcc recognized other declarations from
standard headers and tailored its diagnostic messages accordingly.  On
the other hand, if the compiler complains that it doens't recognize NULL
or EOF, the fix is obvious -- at least to me.

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

#65949

On Saturday, July 18, 2015 at 9:00:03 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Friday, July 17, 2015 at 9:25:01 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > A compiler implementation could have a dictionary of all the identifiers
> >> > in the Standard Library (and feel free to extend to any other units 
> >> > you like) so that if it sees an identifier in a position where it is not
> >> > being declared it could search for the identifier in the dictionary and 
> >> > add the needed header before proceeding. The compiler must emit a 
> >> > message (warning?) teeling you what it did.  
> >> >
> >> > Anybody ever done that?
> >> 
> >> Certainly.
> >> 
> >> $ cat c.c
> >> int main(void) {
> >>     printf("hello\n");
> >> }
> >> $ c gcc -c c.c
> >> c.c: In function 'main':
> >> c.c:2:5: warning: incompatible implicit declaration of built-in function
> >> 'printf' [enabled by default]
> >>      printf("hello\n");
> >        ^
> >
> > Well at least it recognized that "printf" was a library (built-in!)
> > function. It didn't, as I asked, correct the code and continue. The 
> > error description is very confusing. At that position the statement 
> > cannot be a function declaration because it's inside a compound 
> > statement. The compliler seems to think it is the old (now dropped) 
> > form of a function definition.
> 
> Yes, that's what the error message indicates.  gcc is using the old
> "implicit int" rule (but with a warning).  It needs to be able to
> recognize it because it still supports C90.  I'm not 100% happy with the
> way it does this (even with "-std=c99" or "-std=c11"), but it doesn't
> seem to affect anything other than the wording of diagnostics.
> 
> > But it does not make the easy repair and continue.
> 
> I missed the part where you suggested the compiler should add the needed
> header.
> 
> Personally, I'm glad it doesn't.  I presume you're not suggesting that
> the compiler should modify the source file.  But even having the
> compiler *assume* the presence of a missing #include would encourage
> sloppy coding.  IMHO gcc is too lax as it is.
> 
> >> It happens to do this for "printf" but not for FILE -- though if you
> >> write
> >> 
> >>     FILE *tmp;
> >> 
> >> without the proper #include, it does recognize that it's a type name.
> >  
> > It sounds like the libraray identifier data base may only cover
> > function names. It is inconvenient for me to run a test just now -
> > does it recognize a macro, say, EOF or NULL, without an #include?  
> 
> I suspect the existing behavior is based on C90 rules, where functions
> declarations may be omitted but other declarations cannot.
> 
> I suppose it would be nice if gcc recognized other declarations from
> standard headers and tailored its diagnostic messages accordingly.  On
> the other hand, if the compiler complains that it doens't recognize NULL
> or EOF, the fix is obvious -- at least to me.
 
The possible benefit, as another poster agrees, is that you can collect
multiple errors on a single run. 

Of course, if you never make multiple errors ...

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

#66090

On 19/07/15 03:29, David Kleinecke wrote:
> On Friday, July 17, 2015 at 9:25:01 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>>> A compiler implementation could have a dictionary of all the identifiers
>>> in the Standard Library (and feel free to extend to any other units 
>>> you like) so that if it sees an identifier in a position where it is not
>>> being declared it could search for the identifier in the dictionary and 
>>> add the needed header before proceeding. The compiler must emit a 
>>> message (warning?) teeling you what it did.  
>>>
>>> Anybody ever done that?
>>
>> Certainly.
>>
>> $ cat c.c
>> int main(void) {
>>     printf("hello\n");
>> }
>> $ c gcc -c c.c
>> c.c: In function 'main':
>> c.c:2:5: warning: incompatible implicit declaration of built-in function
>> 'printf' [enabled by default]
>>      printf("hello\n");
>        ^
> 
> Well at least it recognized that "printf" was a library (built-in!)
> function. It didn't, as I asked, correct the code and continue. The 
> error description is very confusing. At that position the statement 
> cannot be a function declaration because it's inside a compound 
> statement. The compliler seems to think it is the old (now dropped) 
> form of a function definition.
> 

No, the compiler does not think "printf("hello\n");" is a declaration -
nor does the error message suggest that.  It tells you that the
/implicit/ declaration - i.e., the one that is assumed but not given
explicitly - is incompatible with the "builtin declaration".  (gcc
builtin declarations are a bit weird, in that the compiler checks for
compatibility but you can't use them yourself - you still need a proper
declaration.)

> But it does not make the easy repair and continue.

"Repairing and continuing" is a terrible idea, though trying to avoid
spurious extra diagnostics as a follow-on is useful.  If you want to
look at this sort of thing in practice, try clang or recent versions of
gcc (diagnostics have improved significantly in the past few versions),
especially with -Wall -Wextra, and perhaps some of the other warning
flags according to taste.

> 
>> It happens to do this for "printf" but not for FILE -- though if you
>> write
>>
>>     FILE *tmp;
>>
>> without the proper #include, it does recognize that it's a type name.
>  
> It sounds like the libraray identifier data base may only cover
> function names. It is inconvenient for me to run a test just now -
> does it recognize a macro, say, EOF or NULL, without an #include?  
> 

gcc does not have a database of standard library identifiers - it is
designed to work with a range of libraries, including freestanding
(i.e., not hosted) libraries that may be very much smaller than the full
C library.

But it has "builtins" for a number of common standard library functions,
in order to improve optimisation.  For example, it has built-in support
for memcpy which allows it to optimise calls to memcpy into loops, or to
optimise "printf("Hello\n");" into "puts("Hello\n")", as well as
allowing it to perform additional checking such as matching printf
specifiers with actual parameters.  The real work behind printf and
friends is still carried out by the library function, and you still need
to declare the functions properly before using them.

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

#66100 — Compiler conformance (Was: Error messages)

In article <mol3vp$ptd$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>..., or to
>optimise "printf("Hello\n");" into "puts("Hello\n")", ...

Kiki will be along any minute now to tell you that a compiler that did that
optimization would not be a conforming compiler and thus would be off-topic
in this newsgroup.

-- 
Mike Huckabee has yet to consciously uncouple from Josh Duggar.

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

#66103 — Re: Compiler conformance

On 21/07/2015 13:40, Kenny McCormack wrote:

> David Brown wrote:
> 
>> optimise "printf("Hello\n");" into "puts("Hello\n")", ...
> 
> Kiki will be along any minute now to tell you that a compiler that did that
> optimization would not be a conforming compiler and thus would be off-topic
> in this newsgroup.

Because of the extra newline?

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

#66110 — Re: Compiler conformance

In article <molc7u$mtu$1@dont-email.me>, Noob  <root@127.0.0.1> wrote:
>On 21/07/2015 13:40, Kenny McCormack wrote:
>
>> David Brown wrote:
>> 
>>> optimise "printf("Hello\n");" into "puts("Hello\n")", ...
>> 
>> Kiki will be along any minute now to tell you that a compiler that did that
>> optimization would not be a conforming compiler and thus would be off-topic
>> in this newsgroup.
>
>Because of the extra newline?
>

Correct.  That makes it non-conforming.

-- 
    Nov 4, 2008 - the day when everything went
    from being Clinton's fault to being Obama's fault.

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

#65830

David Kleinecke wrote:

> On Friday, July 17, 2015 at 12:49:03 AM UTC-7, jacobnavia wrote:
>> Le 17/07/2015 07:05, Reinhardt Behm a écrit :
>> > jacobnavia wrote:
>> >
>> >> FILE c:\lcc\include64\stdio.h 123
>> >>
>> >> and when emitting the error message the compiler could improve it to
>> >>
>> >> "Missing <stdio.h> Identifier 'FILE ' is not defined.
>> >> Include stdio.h and proceed.
>> >>
>> >> This will cost me around 1 day development, and 1 day testing. Is that
>> >> still possible for gcc and c++?
>> >>
>> >> I think that I could do that improvement to gcc's C front end, but the
>> >> C++ front end?
>> >>
>> >> Impossible.
>> >
>> > True, it is impossible.
>> >
>> > You want the compiler to _your_ job to specify what has to be included.
>> >  From where should the compiler know what "FILE" means and where it is
>> > defined?
>> >
>> > Instead of the usual definition in stdio.h "FILE" could be the
>> > definition of a structure to hold the flight path of the New Horizon
>> > spacecraft. And this definition is in a file that you not only forgot
>> > to include but even forgot to download from that server in Mongolia
>> > which is only online when the moon rises over the horizon.
>> >
>> 
>> Sure...
>> 
>> Who cares?
>> 
>> People that are redefining parts of the language (as they have the right
>> to do so) can ignore this message!
>> 
>> They WILL KNOW however that FILE is being used without being defined.
>> Much better than "syntax error" or even "parse error"!!!
> 
> A compiler implementation could have a dictionary of all the identifiers
> in the Standard Library (and feel free to extend to any other units
> you like) so that if it sees an identifier in a position where it is not
> being declared it could search for the identifier in the dictionary and
> add the needed header before proceeding. The compiler must emit a
> message (warning?) teeling you what it did.
> 
> Anybody ever done that?

Yes, it was even known before C was invented. 
Denis Ritchie et al. perfected it to the most flexible form with the 
#include directive. :-)

-- 
Reinhardt

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

#65785

Reinhardt Behm <rbehm@hushmail.com> writes:
> jacobnavia wrote:
>
>> FILE c:\lcc\include64\stdio.h 123
>> 
>> and when emitting the error message the compiler could improve it to
>> 
>> "Missing <stdio.h> Identifier 'FILE ' is not defined.
>> Include stdio.h and proceed.
>> 
>> This will cost me around 1 day development, and 1 day testing. Is that
>> still possible for gcc and c++?
>> 
>> I think that I could do that improvement to gcc's C front end, but the
>> C++ front end?
>> 
>> Impossible.
>
> True, it is impossible.
>
> You want the compiler to _your_ job to specify what has to be included.
> From where should the compiler know what "FILE" means and where it is 
> defined?
>
> Instead of the usual definition in stdio.h "FILE" could be the definition of 
> a structure to hold the flight path of the New Horizon spacecraft. And this 
> definition is in a file that you not only forgot to include but even forgot 
> to download from that server in Mongolia which is only online when the moon 
> rises over the horizon.

A compiler can easily recognize identifiers defined in the standard
library and tailor its diagnostic messages to catch problems caused by
using an identifier without #including the corresponding header.

If FILE is used without a visible declaration, it's entirely reasonable
for a compiler to suggest adding `#include <stdio.h>`.  Maybe FILE is
really a type name defined in some application-specific header that you
forgot to #include, but that's both unlikely and a bad idea, and if the
compiler guesses wrong it's not likely to cause any real problems.

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

#65936

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

> A compiler can easily recognize identifiers defined in the standard
> library and tailor its diagnostic messages to catch problems caused by
> using an identifier without #including the corresponding header.
> 
> If FILE is used without a visible declaration, it's entirely reasonable
> for a compiler to suggest adding `#include <stdio.h>`.  Maybe FILE is
> really a type name defined in some application-specific header that you
> forgot to #include, but that's both unlikely and a bad idea, and if the
> compiler guesses wrong it's not likely to cause any real problems.

Hmmm... yes, provided it only _suggests_ to the programmer than
<stdio.h> should be #included. I would never, ever advocate or even
condone an implementation which has the gall to do the #inclusion
itself, on its own initiative.

Richard

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

#65944

On 7/19/15 6:00 PM, Richard Bos wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
>> A compiler can easily recognize identifiers defined in the standard
>> library and tailor its diagnostic messages to catch problems caused by
>> using an identifier without #including the corresponding header.
>>
>> If FILE is used without a visible declaration, it's entirely reasonable
>> for a compiler to suggest adding `#include <stdio.h>`.  Maybe FILE is
>> really a type name defined in some application-specific header that you
>> forgot to #include, but that's both unlikely and a bad idea, and if the
>> compiler guesses wrong it's not likely to cause any real problems.
>
> Hmmm... yes, provided it only _suggests_ to the programmer than
> <stdio.h> should be #included. I would never, ever advocate or even
> condone an implementation which has the gall to do the #inclusion
> itself, on its own initiative.
>
> Richard
>

Actually, if the compiler treated this as an error (so it didn't generate an output file), gave an appropriate message indicating that a symbol was undefined and suggested the file to include, and then read the header file and injected it into the global namespace so that further errors would be more appropriate, I wouldn't have a problem with it.

I can see the issue with it being just a warning, and thus ignorable.

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

#65762

OK, I have done it in just 1 hour of work!

C:\lcc64\src72\test>type terr.c
int f(size_t m)
{
}

C:\lcc64\src72\test>lcc64 terr.c
Warning terr.c: 1  Identifier 'size_t' used without previous definition.
Error terr.c: 1  syntax error; found `m' expecting ')'
Error terr.c: 1  skipping `m'
Warning terr.c: 3  missing return value
2 errors, 2 warnings

C:\lcc64\src72\test>type terr1.c
size_t m;

C:\lcc64\src72\test>lcc64 terr1.c
Warning terr1.c: 1  Identifier 'size_t' used without previous definition.
Error terr1.c: 1  Syntax error; missing semicolon before  `m'
Warning terr1.c: 1  Identifier 'm' used without previous definition.
1 error, 2 warnings

C:\lcc64\src72\test>type terr2.c
int f(int m)
{
         size_t f;
}

C:\lcc64\src72\test>lcc64 terr2.c
Error terr2.c: 3  undeclared identifier 'size_t'
Warning terr2.c: 3  Statement has no effect
Error terr2.c: 3  Syntax error; missing semicolon before  `f'
Warning terr2.c: 3  possible usage of size_t before definition
Warning terr2.c: 4  missing return value
2 errors, 3 warnings

C:\lcc64\src72\test>


The "root cause" of the error is now evident!

jacob

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

#65768

On 17/07/2015 01:36, jacobnavia wrote:

> As far as I can see, we can never have two unknown identifiers separated
> by white space in a legal C program.
>
> Is that correct?

If the input is:

  ...;
  A B ...

then this is mostly likely to be a declaration of a variable or function 
with type A. If the compiler doesn't know A or B, then the most apt 
message is that type 'A' is not defined.

Then that might give a clue as to what the problem might be (missing or 
misspelled type declaration).

In fact this is pretty much what gcc says.

-- 
Bartc

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

#65769

On 17/07/2015 02:36, jacobnavia wrote:

> I think that I could do that improvement to gcc's C front end

For the record, the gcc project is aware that the diagnostic
messages need an overhaul -- especially since Clang came out with
better diagnostics than gcc 4.2 (I guess we can thank Clang for
giving gcc a kick in the nads).

There is a project dedicated to improving the situation:
https://gcc.gnu.org/wiki/Better_Diagnostics
https://gcc.gnu.org/wiki/ClangDiagnosticsComparison

Regards.

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

#65771

On 17/07/2015 12:14, Noob wrote:
> On 17/07/2015 02:36, jacobnavia wrote:
>
>> I think that I could do that improvement to gcc's C front end
>
> For the record, the gcc project is aware that the diagnostic
> messages need an overhaul -- especially since Clang came out with
> better diagnostics than gcc 4.2 (I guess we can thank Clang for
> giving gcc a kick in the nads).

Actually it's gcc (4.8.1) that says 'unknown type', and clang (3.6.0) 
that still says 'undeclared identifier'.

-- 
Bartc

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

#65770

On Friday, July 17, 2015 at 1:36:54 AM UTC+1, jacobnavia wrote:
> This will cost me around 1 day development, and 1 day testing. Is that
> still possible for gcc and c++?

$ cat foo.c

int main()
{
  TYPE t;
  
  t = 17;
}

$ gcc-4.8 foo.c
foo.c: In function 'main':
foo.c:3:3: error: unknown type name 'TYPE'
   TYPE t;
   ^
> I think that I could do that improvement to gcc's C front end, 

I think its already been done!

$ cp foo.c foo.cpp
$ g++-4.8 foo.cpp 
foo.cpp: In function 'int main()':
foo.cpp:3:3: error: 'TYPE' was not declared in this scope
   TYPE t;
   ^
foo.cpp:3:8: error: expected ';' before 't'
   TYPE t;
        ^
foo.cpp:5:3: error: 't' was not declared in this scope
   t = 17;

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

#65773

Le 17/07/2015 13:32, gwowen a écrit :
> On Friday, July 17, 2015 at 1:36:54 AM UTC+1, jacobnavia wrote:
>> This will cost me around 1 day development, and 1 day testing. Is that
>> still possible for gcc and c++?
>
> I think its already been done!

Then why do not do it for C++?

You see?

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

#65774

On Friday, July 17, 2015 at 1:15:58 PM UTC+1, jacobnavia wrote:
> Le 17/07/2015 13:32, gwowen a écrit :
> > On Friday, July 17, 2015 at 1:36:54 AM UTC+1, jacobnavia wrote:
> >> This will cost me around 1 day development, and 1 day testing. Is that
> >> still possible for gcc and c++?
> >
> > I think its already been done!
> 
> Then why do not do it for C++?

Huh?

> You see?

No.

foo.cpp:3:3: error: 'TYPE' was not declared in this scope
   TYPE t;
   ^

seems pretty unambiguous to me.

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

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

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

csiph-web