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

#65739 — Error messages

When missing an include file, c++ emits a parse error.

When I complained about it, people told me that lcc-win stops with a 
"syntax error" what is barely better.

Suppose the following file

size_t foo;

We have here two unknown identifiers separated by a space. Instead of a 
"syntax error", a better error message would be:

Usage of unknown identifier 'size_t'

THEN

syntax error or whatever.

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?

Having ONE unknown identifier is OK since it is the... declaration of 
course!

int foo; // Here "foo" is a new identifier.

The compiler can use a small data base with all the identifiers in its 
include directory:

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.

[toc] | [next] | [standalone]

#65743

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

<snip>

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

I believe so, yes.

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

#65748

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 17/07/15 01:36, jacobnavia wrote:
>
> <snip>
>
>> 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?
>
> I believe so, yes.

This:

    void func(struct foo param);

seems to be legal but useless.  gcc warns:

    c.c:1: warning: 'struct foo' declared inside parameter list
    c.c:1: warning: its scope is only this definition or declaration, which is probably not what you want

As far as I can tell there's no legal way to define or call func.

Since the motivation was to generate a diagnostic, and the above
declaration, even if it's legal (I'm not sure it is) certainly deserves
a diagnostic, I don't think that's a problem.

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

#65757

> This:
>
>      void func(struct foo param);
>
> seems to be legal but useless.  gcc warns:
>
>      c.c:1: warning: 'struct foo' declared inside parameter list
>      c.c:1: warning: its scope is only this definition or declaration, which is probably not what you want

This warning usually arises in header-files, the solution usually is:

sruct foo;
void func (struct foo *param); /* gcc is happy now */

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

#65758

On 17/07/15 08:31, Lőrinczy Zsigmond wrote:
>
>> This:
>>
>>      void func(struct foo param);
>>
>> seems to be legal but useless.  gcc warns:
>>
>>      c.c:1: warning: 'struct foo' declared inside parameter list
>>      c.c:1: warning: its scope is only this definition or declaration, which is probably not what you want
>
> This warning usually arises in header-files, the solution usually is:
>
> sruct foo;
> void func (struct foo *param); /* gcc is happy now */


Not /that/ happy. If you really want to cheer gcc up, change sruct to 
struct. That's guaranteed to bring a smile to any compiler's face.

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

#65763

Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 17/07/15 08:31, L??rinczy Zsigmond wrote:

(snip)
>> sruct foo;
>> void func (struct foo *param); /* gcc is happy now */
 
> Not /that/ happy. If you really want to cheer gcc up, change sruct to 
> struct. That's guaranteed to bring a smile to any compiler's face.

Not long after I started learning Fortran, just about the time
that work first began on C, someone commented to me about the
Fortran compiler not accepting their FROMAT statements.

Maybe it wasn't easy in 1970's technology, but it should not be
hard in current technology for a compiler to figure out sruct.

Why is it that none do?

-- glen

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

#65764

On 17/07/15 10:11, glen herrmannsfeldt wrote:

<snip>

> Maybe it wasn't easy in 1970's technology, but it should not be
> hard in current technology for a compiler to figure out sruct.
>
> Why is it that none do?

It's because *any* obstacle that you can put in the way of programmers 
who can't type is a Good Thing. The less code they generate, the better.

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

#65765

glen herrmannsfeldt wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 17/07/15 08:31, L??rinczy Zsigmond wrote:
>
> (snip)
>>> sruct foo;
>>> void func (struct foo *param); /* gcc is happy now */
>
>> Not /that/ happy. If you really want to cheer gcc up, change sruct to
>> struct. That's guaranteed to bring a smile to any compiler's face.
>
> Not long after I started learning Fortran, just about the time
> that work first began on C, someone commented to me about the
> Fortran compiler not accepting their FROMAT statements.
>
> Maybe it wasn't easy in 1970's technology, but it should not be
> hard in current technology for a compiler to figure out sruct.
>
> Why is it that none do?

Maybe for the same reason UNIX systems still don't understand gerp...

-- 
Ian Collins

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

#65772

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

> glen herrmannsfeldt wrote:
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>> On 17/07/15 08:31, L??rinczy Zsigmond wrote:
>>
>> (snip)
>>>> sruct foo;
>>>> void func (struct foo *param); /* gcc is happy now */
>>
>>> Not /that/ happy. If you really want to cheer gcc up, change sruct to
>>> struct. That's guaranteed to bring a smile to any compiler's face.
>>
>> Not long after I started learning Fortran, just about the time
>> that work first began on C, someone commented to me about the
>> Fortran compiler not accepting their FROMAT statements.
>>
>> Maybe it wasn't easy in 1970's technology, but it should not be
>> hard in current technology for a compiler to figure out sruct.
>>
>> Why is it that none do?
>
> Maybe for the same reason UNIX systems still don't understand gerp...

...though some will try to help out:

  $ gerp
  No command 'gerp' found, did you mean:
   Command 'grep' from package 'grep' (main)
  gerp: command not found

-- 
Ben.

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

#65792

On Fri, 17 Jul 2015 21:44:04 +1200
Ian Collins <ian-news@hotmail.com> wrote:

> glen herrmannsfeldt wrote:
> > Richard Heathfield <rjh@cpax.org.uk> wrote:
> >> On 17/07/15 08:31, L??rinczy Zsigmond wrote:
> >
> > (snip)
> >>> sruct foo;
> >>> void func (struct foo *param); /* gcc is happy now */
> >
> >> Not /that/ happy. If you really want to cheer gcc up, change sruct
> >> to struct. That's guaranteed to bring a smile to any compiler's
> >> face.
> >
> > Not long after I started learning Fortran, just about the time
> > that work first began on C, someone commented to me about the
> > Fortran compiler not accepting their FROMAT statements.
> >
> > Maybe it wasn't easy in 1970's technology, but it should not be
> > hard in current technology for a compiler to figure out sruct.
> >
> > Why is it that none do?
> 
> Maybe for the same reason UNIX systems still don't understand gerp...
> 

I always mistype joe into jeo, must make an alias ;p

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

#65793

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

(snip, I wrote)

>> Not long after I started learning Fortran, just about the time
>> that work first began on C, someone commented to me about the
>> Fortran compiler not accepting their FROMAT statements.

>> Maybe it wasn't easy in 1970's technology, but it should not be
>> hard in current technology for a compiler to figure out sruct.

>> Why is it that none do?
 
> Maybe for the same reason UNIX systems still don't understand gerp...

Someone on the systems I first used SunOS (3.x) on had something like:

alias mroe more

(I think I specifically remember that one)

you could add 

alias gerp grep

There are some that I spell wrong, in the same way, pretty often.
(Partly related to which hand the keys are on.)

-- glen

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

#65798

On 07/17/2015 01:55 PM, glen herrmannsfeldt wrote:
...
> Someone on the systems I first used SunOS (3.x) on had something like:
> 
> alias mroe more
> 
> (I think I specifically remember that one)
> 
> you could add 
> 
> alias gerp grep

Whenever the sysadmins set up an account for me on a new machine, the
default .cshrc usually sets up a number of similar aliases - mroe is by
far the most popular for some reason. I make a point of disabling them.
It's much easier to learn to type things correctly when you don't have
such aliases set up. You can learn even faster is you do the following,
instead:

	alias mroe 'echo "It is spelled more, not mroe!"'

I've never needed to go that far.

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

#65931

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Heathfield <rjh@cpax.org.uk> wrote:
> > On 17/07/15 08:31, L??rinczy Zsigmond wrote:
> 
> (snip)
> >> sruct foo;
> >> void func (struct foo *param); /* gcc is happy now */
>  
> > Not /that/ happy. If you really want to cheer gcc up, change sruct to 
> > struct. That's guaranteed to bring a smile to any compiler's face.
> 
> Not long after I started learning Fortran, just about the time
> that work first began on C, someone commented to me about the
> Fortran compiler not accepting their FROMAT statements.
> 
> Maybe it wasn't easy in 1970's technology, but it should not be
> hard in current technology for a compiler to figure out sruct.
> 
> Why is it that none do?

Because they'd fsck up my (rethorical) code which declares an object (or
even typedef!) for the current Shop-Replacable Unit CounT.

Richard

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

#65759

In article <moab0f$rn9$1@speranza.aioe.org>,
LÅ rinczy Zsigmond  <nospam@for.me> wrote:
>
>> This:
>>
>>      void func(struct foo param);
>>
>> seems to be legal but useless.  gcc warns:
>>
>>      c.c:1: warning: 'struct foo' declared inside parameter list
>>      c.c:1: warning: its scope is only this definition or declaration, which is
>probably not what you want
>
>This warning usually arises in header-files, the solution usually is:
>
>sruct foo;
>void func (struct foo *param); /* gcc is happy now */

Kiki should be by any minute now to tell you that "sruct" is a syntax error
and that according to section 9.12.132 of the holy standard, requires a
diagnostic from a conforming C compiler.

-- 

There are many self-professed Christians who seem to think that because
they believe in Jesus' sacrifice they can reject Jesus' teachings about
how we should treat others. In this country, they show that they reject
Jesus' teachings by voting for Republicans.

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

#65761

On 17/07/2015 09:38, Kenny McCormack wrote:

> Kiki should be by any minute now to tell you that "sruct" is a syntax
> error and that according to section 9.12.132 of the holy standard,
> requires a diagnostic from a conforming C compiler.

You need a better hobby than this.

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

#65778

In article <moacfs$fgv$1@dont-email.me>, Noob  <root@127.0.0.1> wrote:
>On 17/07/2015 09:38, Kenny McCormack wrote:
>
>> Kiki should be by any minute now to tell you that "sruct" is a syntax
>> error and that according to section 9.12.132 of the holy standard,
>> requires a diagnostic from a conforming C compiler.
>
>You need a better hobby than this.
>

Actually, I often wonder what people like Kiki and the other regs are doing
here.  What's in it for them???

Seriously, I'm having FUN.  Pointing out the idiocies of the CLC regs is
like poking fun at politicians.  Granted, poking fun at politicians doesn't
really accomplish anything - they just get more stupid and more entrenched
with each passing year - but it *is* FUN.

But what kind of hobby is this for people like Kiki (&etc)?  Supposedly,
they're all busy, productive programmers!  Where do people like Kiki and
Kuyper find the many hours a day that they spend on CLC?  Do their assumed
employers know about this?  Should we tell them?

-- 

Some of the more common characteristics of Asperger syndrome include: 

* Inability to think in abstract ways (eg: puns, jokes, sarcasm, etc)
* Difficulties in empathising with others
* Problems with understanding another person's point of view
* Hampered conversational ability
* Problems with controlling feelings such as anger, depression 
    and anxiety
* Adherence to routines and schedules, and stress if expected routine 
    is disrupted
* Inability to manage appropriate social conduct
* Delayed understanding of sexual codes of conduct
* A narrow field of interests. For example a person with Asperger 
    syndrome may focus on learning all there is to know about 
    baseball statistics, politics or television shows.
* Anger and aggression when things do not happen as they want
* Sensitivity to criticism
* Eccentricity
* Behaviour varies from mildly unusual to quite aggressive 
    and difficult

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

#65842

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

> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 17/07/15 01:36, jacobnavia wrote:
>>
>> <snip>
>>
>>> 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?
>>
>> I believe so, yes.
>
> This:
>
>     void func(struct foo param);
>
> seems to be legal but useless.

There are not useless constructs that put two identifiers together but
they may not count for Jacob's purpose depending on what he means by
unknown:

  typedef struct a b;
  struct x y(void);

In both cases the first identifier is not entirely unknown as you can
tell that it's a struct tag right away.

<snip>
-- 
Ben.

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

#65750

On 07/16/2015 08:36 PM, jacobnavia wrote:
> When missing an include file, c++ emits a parse error.

The C++ language itself only requires a diagnostic, contents
unspecified. If you're talking about the detailed contents of the
diagnostic message, it's essential that you identify which particular
implementation of C++ you're referring to.
-- 
James Kuyper

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

#65753

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.

-- 
Reinhardt

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

#65760

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"!!!

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web