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

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

Compiler bug in lcc-win32

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

Contents

  Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 02:58 -0700
    Re: Compiler bug in lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2011-07-17 08:39 -0400
      Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 09:46 -0700
        Re: Compiler bug in lcc-win32 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-17 13:44 -0400
          Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 11:23 -0700
            Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 11:37 -0700
            Re: Compiler bug in lcc-win32 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-17 15:27 -0400
              Re: Compiler bug in lcc-win32 "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-07-18 10:02 +0200
                Re: Compiler bug in lcc-win32 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-18 07:32 -0400
                  Re: Compiler bug in lcc-win32 gwowen <gwowen@gmail.com> - 2011-07-18 05:07 -0700
            Re: Compiler bug in lcc-win32 Keith Thompson <kst-u@mib.org> - 2011-07-17 13:19 -0700
              Re: Compiler bug in lcc-win32 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-07-17 20:59 +0000
                Re: Compiler bug in lcc-win32 Keith Thompson <kst-u@mib.org> - 2011-07-17 14:22 -0700
              Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 14:08 -0700
                Re: Compiler bug in lcc-win32 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-18 20:51 -0400
                  Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-18 23:46 -0700
                    Re: Compiler bug in lcc-win32 Keith Thompson <kst-u@mib.org> - 2011-07-19 08:33 -0700
        Re: Compiler bug in lcc-win32 jacob navia <jacob@spamsink.net> - 2011-07-17 21:04 +0200
          Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 12:13 -0700
        Re: Compiler bug in lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2011-07-17 16:44 -0400
          Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-17 23:48 -0700
            Re: Compiler bug in lcc-win32 gwowen <gwowen@gmail.com> - 2011-07-18 03:46 -0700
              Re: Compiler bug in lcc-win32 "BartC" <bc@freeuk.com> - 2011-07-18 12:07 +0100
            Re: Compiler bug in lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2011-07-18 09:28 -0400
              Re: Compiler bug in lcc-win32 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-18 14:37 +0100
                Re: Compiler bug in lcc-win32 Keith Thompson <kst-u@mib.org> - 2011-07-18 08:55 -0700
              Re: Compiler bug in lcc-win32 tm <thomas.mertes@gmx.at> - 2011-07-18 07:42 -0700
                Re: Compiler bug in lcc-win32 jacob navia <jacob@spamsink.net> - 2011-07-18 18:45 +0200
                Re: Compiler bug in lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2011-07-19 07:42 -0400
                  Re: Compiler bug in lcc-win32 gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-19 11:52 +0000
                Re: Compiler bug in lcc-win32 James Kuyper <jameskuyper@verizon.net> - 2011-07-20 06:26 -0400
                  Re: Compiler bug in lcc-win32 Noob <root@127.0.0.1> - 2011-07-20 14:25 +0200

Page 1 of 2  [1] 2  Next page →

#8378 — Compiler bug in lcc-win32

Hello,

I discovered a compiler bug in lcc-win32 under Windows XP.
The || and && operators work wrong when -O is used.
The following program shows the bug:

-------------------- Begin file testlcc.c --------------------
/*  Compile with:
 *  lc -O -g5 -A testlcc.c -o testlcc.exe
 */

#include "stdio.h"

typedef enum {ILLEGALCHAR, EOFCHAR, LETTERCHAR, DIGITCHAR,
    UNDERLINECHAR, SHARPCHAR, QUOTATIONCHAR, APOSTROPHECHAR,
    LEFTPARENCHAR, PARENCHAR, SPECIALCHAR, SPACECHAR,
    NEWLINECHAR} charclass;

typedef int booltype;

charclass ch_class[256 - EOF];
booltype ch_op[256 - EOF];

#define char_class(CHARACTER) ch_class [((int)(CHARACTER)) - EOF]
#define op_char(CHARACTER)    ch_op    [((int)(CHARACTER)) - EOF]

void get_ident (unsigned char *name, unsigned int length)
{
  printf("length:\n%d        # should be: 1\n", length);
  printf("name[0]:\n'%c' (%d) # should be: '$' (36)\n",
          name[0], name[0]);
  printf("op_char(name[0]):\n%d        # should be: 1\n",
          op_char(name[0]));
  printf("char_class(name[0]):\n%2d       # should be: 10\n",
          char_class(name[0]));
  printf("char_class(name[0])==LEFTPARENCHAR:\n");
  printf("%d        # should be: 0\n",
          char_class(name[0])==LEFTPARENCHAR);
  printf("op_char(name[0]) || "
         "char_class(name[0])==LEFTPARENCHAR:\n");
  printf("%d        # should be: 1\n",
          op_char(name[0]) ||
          char_class(name[0])==LEFTPARENCHAR);
  printf("char_class(name[0])==PARENCHAR:\n");
  printf("%d        # should be: 0\n",
          char_class(name[0])==PARENCHAR);
  printf("op_char(name[0]) || "
         "char_class(name[0])==LEFTPARENCHAR || "
         "char_class(name[0])==PARENCHAR:\n");
  printf("%d        # should be 1\n",
          op_char(name[0]) ||
          char_class(name[0])==LEFTPARENCHAR ||
          char_class(name[0])==PARENCHAR);
  printf("length==1 && (op_char(name[0]) || "
         "char_class(name[0])==LEFTPARENCHAR || "
         "char_class(name[0])==PARENCHAR):\n");
  printf("%d        # should be 1\n",
          length==1 && (op_char(name[0]) ||
                        char_class(name[0])==LEFTPARENCHAR ||
                        char_class(name[0])==PARENCHAR));
}

int main (int argc, char *argv[])
{
  char_class('$') = SPECIALCHAR;
  op_char('$') = 1;
  get_ident("$", 1);
}
-------------------- End file testlcc.c --------------------

When I compile with

  lc -O -g5 -A testlcc.c -o testlcc.exe

and start testlcc.exe, I get the following output:

length:
1        # should be: 1
name[0]:
'$' (36) # should be: '$' (36)
op_char(name[0]):
1        # should be: 1
char_class(name[0]):
10       # should be: 10
char_class(name[0])==LEFTPARENCHAR:
0        # should be: 0
op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR:
0        # should be: 1
char_class(name[0])==PARENCHAR:
0        # should be: 0
op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR ||
char_class(name[0])==PARENCHAR:
0        # should be 1
length==1 && (op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR
|| char_class(name[0])==PARENCHAR):
0        # should be 1

--------------------

The correct result can be obtained with gcc:

  gcc testlcc.c -o testlcc

1        # should be: 1
name[0]:
'$' (36) # should be: '$' (36)
op_char(name[0]):
1        # should be: 1
char_class(name[0]):
10       # should be: 10
char_class(name[0])==LEFTPARENCHAR:
0        # should be: 0
op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR:
1        # should be: 1
char_class(name[0])==PARENCHAR:
0        # should be: 0
op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR ||
char_class(name[0])==PARENCHAR:
1        # should be 1
length==1 && (op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR
|| char_class(name[0])==PARENCHAR):
1        # should be 1

--------------------

I hope this helps to find and correct the compiler bug.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [next] | [standalone]

#8380

On 07/17/2011 05:58 AM, tm wrote:
> Hello,
> 
> I discovered a compiler bug in lcc-win32 under Windows XP.

Why are you posting this here, instead of contacting the vendor
directly? It gives the (possibly correct) impression that your main
purpose is to embarrass the vendor, rather than simply getting the bug
fixed (assuming that it actually is a bug - I didn't bother to check).
Even if you were justified in making a big public issue about this,
comp.compilers.lcc would have been the more appropriate forum.

While I did not examine your code closely, I did notice one minor issue:
...
> #include "stdio.h"

That should be <stdio.h>; it can make a difference which one you use.

...
>   lc -O -g5 -A testlcc.c -o testlcc.exe
...
>   gcc testlcc.c -o testlcc

Keep in mind that, like most compilers, neither of the compilers that
you're comparing fully conforms to any version of the C standard in
their default mode. You haven't chosen the correct options to put gcc
into a fully conforming mode - you need to use at least -ansi -pedantic.
I'm not sure which options you should use with lcc, but whichever ones
they are, you should use them before comparing the results with gcc;
otherwise the comparison is meaningless.

-- 
James Kuyper

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

#8383

On 17 Jul., 14:39, James Kuyper <jameskuy...@verizon.net> wrote:
> On 07/17/2011 05:58 AM, tm wrote:
>
> > Hello,
>
> > I discovered a compiler bug in lcc-win32 under Windows XP.
>
> Why are you posting this here, instead of contacting the vendor
> directly?

Because jacob navia often discusses in this group.

[snip accusation]

It is not my intention to embarrass anybody.
A compiler is not a religion. Please calm down.

> While I did not examine your code closely, I did notice one minor issue:
> ...
>
> > #include "stdio.h"
>
> That should be <stdio.h>; it can make a difference which one you use.

For the purpose of showing this bug, this does not make
any difference.

[snip]

> You haven't chosen the correct options to put gcc
> into a fully conforming mode - you need to use at least -ansi -pedantic.

No, The expression

op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR

where name[0] is '$' and op_char('$') is 1, should
always return 1, independend of K&R, ANSI C89, ANSI C99
and probably also for a future version. The expression

1 || anyting

should always evaluate to 1, independend of C version
or compiler. Otherwise it is not C.

> I'm not sure which options you should use with lcc, but whichever ones
> they are, you should use them before comparing the results with gcc;
> otherwise the comparison is meaningless.

I do not agree. See above.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#8384

On 7/17/2011 12:46 PM, tm wrote:
> [...]The expression
>
> 1 || anyting
>
> should always evaluate to 1, independend of C version
> or compiler. Otherwise it is not C.

     No matter: Neither is your program.  Once you invoke undefined
behavior, the implementation is not obliged to live up to anything
the C Standard promises.

     I grant that the particular instances of undefined behavior (two)
and of implementation-defined behavior (one) are extremely unlikely
to be responsible for the results you report.  Nonetheless, the claim
"Frobozz Magic C doesn't treat my buggy program the way I want, ergo
Frobozz Magic C is at fault" is a bit of a stretch.

>> I'm not sure which options you should use with lcc, but whichever ones
>> they are, you should use them before comparing the results with gcc;
>> otherwise the comparison is meaningless.
>
> I do not agree. See above.

     Any implementation conforming to C90 or to C99 is required to
issue diagnostics for your code.  Have you complained to the gcc
folks about their compiler's failure to do so?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#8385

On 17 Jul., 19:44, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 7/17/2011 12:46 PM, tm wrote:
>
> > [...]The expression
>
> > 1 || anyting
>
> > should always evaluate to 1, independend of C version
> > or compiler. Otherwise it is not C.
>
>      No matter: Neither is your program.

Would you please be so kindly to explain, where did I
invoke undefined behavior.

AFAIK. The if-statement

if (1 || sub_expression)
  print("TRUE\n");

should print TRUE. Why should this be invoke undefined
behavior?

To state it clear:

**** LCC FAILS TO WRITE TRUE WITH THIS IF STATEMENT ****

[snip]

I think the next time I will not spend my time to
examine a compiler bug, write a test program and
tell about it. I will just refuse to use that compiler.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#8386

On 17 Jul., 20:23, tm <thomas.mer...@gmx.at> wrote:
> On 17 Jul., 19:44, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> > On 7/17/2011 12:46 PM, tm wrote:
>
> > > [...]The expression
>
> > > 1 || anyting
>
> > > should always evaluate to 1, independend of C version
> > > or compiler. Otherwise it is not C.
>
> >      No matter: Neither is your program.
>
> Would you please be so kindly to explain, where did I
> invoke undefined behavior.
>
> AFAIK. The if-statement
>
> if (1 || sub_expression)
>   print("TRUE\n");

Before some nitpicker shows up. This should be:

if (1 || sub_expression)
  printf("TRUE\n");

> should print TRUE. Why should this be invoke undefined
> behavior?

And this should be:

Why should this invoke undefined behavior?

> To state it clear:
>
> **** LCC FAILS TO WRITE TRUE WITH THIS IF STATEMENT ****
>
> [snip]
>
> I think the next time I will not spend my time to
> examine a compiler bug, write a test program and
> tell about it. I will just refuse to use that compiler.
>
> Greetings Thomas Mertes
>
> --
> Seed7 Homepage:  http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.

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

#8389

On 7/17/2011 2:23 PM, tm wrote:
> On 17 Jul., 19:44, Eric Sosman<esos...@ieee-dot-org.invalid>  wrote:
>> On 7/17/2011 12:46 PM, tm wrote:
>>
>>> [...]The expression
>>
>>> 1 || anyting
>>
>>> should always evaluate to 1, independend of C version
>>> or compiler. Otherwise it is not C.
>>
>>       No matter: Neither is your program.
>
> Would you please be so kindly to explain, where did I
> invoke undefined behavior.

     Run the compiler(s) in a conforming mode, and they'll tell you
about one instance of U.B. (the diagnostic is required).  I don't
know about lcc, but gcc will tell you about the other instance, too,
if you ask it politely.  The instance of implementation-defined
behavior has already been brought to your attention.  (It occurs
to me that there are other instances of I-D behavior in your code,
but they're of the extremely far-fetched and nit-picky variety.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#8411

Eric Sosman wrote:
> On 7/17/2011 2:23 PM, tm wrote:
>> On 17 Jul., 19:44, Eric Sosman<esos...@ieee-dot-org.invalid>  wrote:
>>> On 7/17/2011 12:46 PM, tm wrote:
>>>
>>>> [...]The expression
>>>
>>>> 1 || anyting
>>>
>>>> should always evaluate to 1, independend of C version
>>>> or compiler. Otherwise it is not C.
>>>
>>>       No matter: Neither is your program.
>>
>> Would you please be so kindly to explain, where did I
>> invoke undefined behavior.
>
>     Run the compiler(s) in a conforming mode, and they'll tell you
> about one instance of U.B. (the diagnostic is required).  I don't
> know about lcc, but gcc will tell you about the other instance, too,
> if you ask it politely.  The instance of implementation-defined
> behavior has already been brought to your attention.  (It occurs
> to me that there are other instances of I-D behavior in your code,
> but they're of the extremely far-fetched and nit-picky variety.)

Please tell us more. I did compile it with a 2 usually very strict 
compilers, for C89 and C99 (non of them gcc though) and neither complained 
nor showed the problem the OP described.

Bye, Jojo 

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

#8422

On 7/18/2011 4:02 AM, Joachim Schmitz wrote:
> Eric Sosman wrote:
>> [...]
>> Run the compiler(s) in a conforming mode, and they'll tell you
>> about one instance of U.B. (the diagnostic is required). I don't
>> know about lcc, but gcc will tell you about the other instance, too,
>> if you ask it politely. The instance of implementation-defined
>> behavior has already been brought to your attention. (It occurs
>> to me that there are other instances of I-D behavior in your code,
>> but they're of the extremely far-fetched and nit-picky variety.)
>
> Please tell us more. I did compile it with a 2 usually very strict
> compilers, for C89 and C99 (non of them gcc though) and neither
> complained nor showed the problem the OP described.

gcc -Wall -W -std=c99 testlcc.c
testlcc.c: In function 'main':
testlcc.c:56: warning: pointer targets in passing argument 1 of 
'get_ident' differ in signedness
testlcc.c:16: note: expected 'unsigned char *' but argument is of type 
'char *'
testlcc.c:52: warning: unused parameter 'argc'
testlcc.c:52: warning: unused parameter 'argv'

     To my surprise, gcc did *not* complain about the other instance
of undefined behavior.  I'm surprised; usually it catches that sort
of thing.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#8426

On Jul 18, 12:32 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>      To my surprise, gcc did *not* complain about the other instance
> of undefined behavior.  I'm surprised; usually it catches that sort
> of thing.

Using -std=c90 warns about falling off the bottom of main(), -std=c99
doesn't (gcc 4.5.2).

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

#8390

tm <thomas.mertes@gmx.at> writes:
[...]
> To state it clear:
>
> **** LCC FAILS TO WRITE TRUE WITH THIS IF STATEMENT ****
>
> [snip]
>
> I think the next time I will not spend my time to
> examine a compiler bug, write a test program and
> tell about it. I will just refuse to use that compiler.

Why on Earth would you say that?

Nobody is criticizing you for reporting a bug.  Reporting bugs is A
Good Thing.  We're just suggesting that a newsgroup (comp.lang.c)
that discusses a programming language is not the best place to do
it, since you're not really talking about the language.  Especially
since there's a newsgroup, comp.compilers.lcc that discusses that
particular compiler (both lcc-win32 and the original lcc), and
because it would make more sense to contact the author direction.
Yes, jacob regularly posts here; I'm sure he reularly reads his
e-mail.

It's not even that big a deal.  We get a lot of off-topic posts in
clc; yours is far from the worst.  Why are you overreacting like
this to the simple suggestion that there are better places for
bug reports?

(Yes, this is cross-posted to a more appropriate newsgroup, but the
original post, and most of the discussion, were just in clc.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8394

In comp.compilers.lcc Keith Thompson <kst-u@mib.org> wrote:

(snip)
> Why on Earth would you say that?

> Nobody is criticizing you for reporting a bug.  Reporting bugs is A
> Good Thing.  We're just suggesting that a newsgroup (comp.lang.c)
> that discusses a programming language is not the best place to do
> it, since you're not really talking about the language.  

I missed the beginning, but sometimes it is hard to know what
is a compiler bug and what is a language (mis)feature.  That comes
up pretty often in Fortran as new features are added and it takes
some time for people to understand how to use them.

> Especially
> since there's a newsgroup, comp.compilers.lcc that discusses that
> particular compiler (both lcc-win32 and the original lcc), and
> because it would make more sense to contact the author direction.
> Yes, jacob regularly posts here; I'm sure he reularly reads his
> e-mail.

If you are sure that it is a compiler bug, then that does
seem a better way.

-- glen

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

#8399

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.compilers.lcc Keith Thompson <kst-u@mib.org> wrote:
> (snip)
>> Why on Earth would you say that?
>
>> Nobody is criticizing you for reporting a bug.  Reporting bugs is A
>> Good Thing.  We're just suggesting that a newsgroup (comp.lang.c)
>> that discusses a programming language is not the best place to do
>> it, since you're not really talking about the language.  
>
> I missed the beginning, but sometimes it is hard to know what
> is a compiler bug and what is a language (mis)feature.  That comes
> up pretty often in Fortran as new features are added and it takes
> some time for people to understand how to use them.

Did you miss the subject header, where it says "Compiler bug in
lcc-win32"?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8396

On 17 Jul., 22:19, Keith Thompson <ks...@mib.org> wrote:
> tm <thomas.mer...@gmx.at> writes:
>
> [...]
>
> > To state it clear:
>
> > **** LCC FAILS TO WRITE TRUE WITH THIS IF STATEMENT ****
>
> > [snip]
>
> > I think the next time I will not spend my time to
> > examine a compiler bug, write a test program and
> > tell about it. I will just refuse to use that compiler.
>
> Why on Earth would you say that?
>
> Nobody is criticizing you for reporting a bug.  Reporting bugs is A
> Good Thing.  We're just suggesting that a newsgroup (comp.lang.c)
> that discusses a programming language is not the best place to do
> it, since you're not really talking about the language.  Especially
> since there's a newsgroup, comp.compilers.lcc that discusses that
> particular compiler (both lcc-win32 and the original lcc), and
> because it would make more sense to contact the author direction.
> Yes, jacob regularly posts here; I'm sure he reularly reads his
> e-mail.

Maybe you saw it. I posted to comp.compilers.lcc shortly
after I heared from it.

> It's not even that big a deal.  We get a lot of off-topic posts in
> clc; yours is far from the worst.  Why are you overreacting like
> this to the simple suggestion that there are better places for
> bug reports?

Using the word "overreacting" is a little bit overreacting. :-)

Eric Sosman wrote:
> No matter: Neither is your program.  Once you invoke undefined
> behavior, the implementation is not obliged to live up to anything
> the C Standard promises.

With -Wall gcc complains a little bit:
Control reaches the end of the non-void function 'main'
and the function 'get_ident' expects ‘unsigned char *’
but the argument is of type ‘char *’.

This two things have no influence on the compiler bug.

Instead of telling me this two things straight forward, he
started with a quiz: Your program has 'undefined behavior',
find them out.

After searching a compiler bug for two days I was not
interested to discuss at this level. Especially because
I was busy to prepare my new Seed7 release. Sorry for my
"overreaction".

I like to hear about errors and undefined behavior in my
programs. If you are interested, you can download Seed7
and check it.

This would be a real challenge. :-)


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#8468

On 7/17/2011 5:08 PM, tm wrote:
> [...]
> Eric Sosman wrote:
>> No matter: Neither is your program.  Once you invoke undefined
>> behavior, the implementation is not obliged to live up to anything
>> the C Standard promises.
>
> With -Wall gcc complains a little bit:
> Control reaches the end of the non-void function 'main'
> and the function 'get_ident' expects ‘unsigned char *’
> but the argument is of type ‘char *’.
>
> This two things have no influence on the compiler bug.

     By my count, that makes two issues you've dismissed as "has no
influence" and "does not make any difference."  You may be right (I
will even go so far as to say you are probably right), but one has
to ask: What evidence supports your claims?  Would it not have been
simpler to write a Simon-pure demonstration in the first place?

     Or was the scent of your prey just too strong in your nostrils?

> I was busy to prepare my new Seed7 release. [...]
> If you are interested, you can download Seed7
> and check it.

     Ah, so this is Yet Another Seed Spam.  What a surprise.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#8473

On 19 Jul., 02:51, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 7/17/2011 5:08 PM, tm wrote:
>
> > [...]
> > Eric Sosman wrote:
> >> No matter: Neither is your program.  Once you invoke undefined
> >> behavior, the implementation is not obliged to live up to anything
> >> the C Standard promises.
>
> > With -Wall gcc complains a little bit:
> > Control reaches the end of the non-void function 'main'
> > and the function 'get_ident' expects ‘unsigned char *’
> > but the argument is of type ‘char *’.
>
> > This two things have no influence on the compiler bug.
>
>      By my count, that makes two issues you've dismissed as "has no
> influence" and "does not make any difference."  You may be right (I
> will even go so far as to say you are probably right), but one has
> to ask: What evidence supports your claims?

Jacob Navia seems to support my claims (see this thread):
----- cite -----
I would like (again) to thank you for your bug report. Contrary
to the anonymous "bug" trolls before I know you are real and
also that the bug is real.

I have a corrected version of the software now. It is a very difficult
to reprodue bug, and thanks to your test program I have been able
to identify the culprit and correct the optimization bug.
----- end cite -----

> Would it not have been
> simpler to write a Simon-pure demonstration in the first place?

I discovered the bug in an approx. 100000 line program.
In two days of work I distilled this size down to the
program I posted.

[snip]


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#8488

tm <thomas.mertes@gmx.at> writes:
> On 19 Jul., 02:51, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> On 7/17/2011 5:08 PM, tm wrote:
>>
>> > [...]
>> > Eric Sosman wrote:
>> >> No matter: Neither is your program.  Once you invoke undefined
>> >> behavior, the implementation is not obliged to live up to anything
>> >> the C Standard promises.
>>
>> > With -Wall gcc complains a little bit:
>> > Control reaches the end of the non-void function 'main'
>> > and the function 'get_ident' expects ‘unsigned char *’
>> > but the argument is of type ‘char *’.
>>
>> > This two things have no influence on the compiler bug.
>>
>>      By my count, that makes two issues you've dismissed as "has no
>> influence" and "does not make any difference."  You may be right (I
>> will even go so far as to say you are probably right), but one has
>> to ask: What evidence supports your claims?
>
> Jacob Navia seems to support my claims (see this thread):
> ----- cite -----
> I would like (again) to thank you for your bug report. Contrary
> to the anonymous "bug" trolls before I know you are real and
> also that the bug is real.
>
> I have a corrected version of the software now. It is a very difficult
> to reprodue bug, and thanks to your test program I have been able
> to identify the culprit and correct the optimization bug.
> ----- end cite -----
>
>> Would it not have been
>> simpler to write a Simon-pure demonstration in the first place?
>
> I discovered the bug in an approx. 100000 line program.
> In two days of work I distilled this size down to the
> program I posted.

I applaud the work you did to help track down this bug, and I'm
glad that it led to a solution.

I'm just a bit confused about why you didn't (a) take another 5
minutes to correct some obvious remaining errors in your test case,
and (b) send the bug report to a more appropriate place (probably
jacob's e-mail) rather than to a language discussion group.

You've spent more time defending
    #include "stdio.h"
than you would have spent changing it to
    #include <stdio.h>

Nobody is claiming that the use of "" rather than <> was actually
relevant to the problem.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8387

Hi Thomas

Thank you for your bug report.

I am unable to fix it right now because I am in holidays at the beach in
Grière plage, Vandée. (Atlantic coast of France)

It is nice here, wind, sea, sun, kids, ice-cream, swimming pool, no
internet connection, I have to go to some cyber cafe to get one...

Will fix it later.

jacob

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

#8388

On 17 Jul., 21:04, jacob navia <ja...@spamsink.net> wrote:
> Hi Thomas
>
> Thank you for your bug report.
>
> I am unable to fix it right now because I am in holidays at the beach in
> Gri re plage, Vand e. (Atlantic coast of France)

Enjoy your holidays.

> It is nice here, wind, sea, sun, kids, ice-cream, swimming pool, no
> internet connection, I have to go to some cyber cafe to get one...
>
> Will fix it later.

No problem. I hope that my testprogram is helpful.
I examined the problem for two days and almost gave up...


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#8391

On 07/17/2011 12:46 PM, tm wrote:
> On 17 Jul., 14:39, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 07/17/2011 05:58 AM, tm wrote:
>>
>>> Hello,
>>
>>> I discovered a compiler bug in lcc-win32 under Windows XP.
>>
>> Why are you posting this here, instead of contacting the vendor
>> directly?
> 
> Because jacob navia often discusses in this group.

Yes, and so do a few people who regularly post bug reports against lcc,
not too dissimilar from yours, for the sole apparent purpose of baiting
jacob into an intemperate response. A hallmark of those reports is that
the "bug" usually depends in some subtle fashion upon some
well-documented extension to C supported by lcc-win32. I don't know
lcc-win32's extensions well-enough to be sure that your code has not run
afoul of one of them.

>> While I did not examine your code closely, I did notice one minor issue:
>> ...
>>
>>> #include "stdio.h"
>>
>> That should be <stdio.h>; it can make a difference which one you use.
> 
> For the purpose of showing this bug, this does not make
> any difference.

Until you know what caused the bug, you can't be sure. An incompatible
file named stdio.h in a location that is searched when you use "", but
is not searched when you use <>, could in principle be the reason why
printf() doesn't print the value you expected it to print. I consider
this extremely unlikely, which is why I labeled it a "minor issue", but
I still recommend correcting it.

>> You haven't chosen the correct options to put gcc
>> into a fully conforming mode - you need to use at least -ansi -pedantic.
> 
> No, The expression
> 
> op_char(name[0]) || char_class(name[0])==LEFTPARENCHAR
> 
> where name[0] is '$' and op_char('$') is 1, should
> always return 1, independend of K&R, ANSI C89, ANSI C99
> and probably also for a future version. The expression

But in their default modes, like most other compilers, neither of those
compilers implements any of the languages you listed, so even if you're
right about those four languages, that doesn't guarantee that you're
right about the default lcc-win32 or gnu versions of C. Keep in mind,
also, that the problem could be in some entirely different part of the
code. It might not be the implementation of || that is producing
unexpected results, but a problem elsewhere in your code that manifests
itself in this location.

> 1 || anyting
> 
> should always evaluate to 1, independend of C version
> or compiler. Otherwise it is not C.

That depends upon how you define "C"; jacob's definition is more
flexible than mine, but I doubt that lcc-win32 deliberately implements
|| in a way significantly incompatible with the requirements of the C
standard. However, it's quite possible that some other aspect of your
program is causing these symptoms.
-- 
James Kuyper

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web