Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2004-12

compiler bug?

30 messages · 9 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Jesus Reyes

I have doubts about this so I made a small test, what I want to know is if a true boolean value be internally be represented by any value different from 0.

program problem;
var
  B: boolean;
begin
  FillChar(B, SizeOf(B), 255);
  case b of
    true: WriteLn(True);
    false: WriteLn(False);
    else WriteLn('OTHER');
  end;
end.

I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for i386 under linux.

the program output: OTHER, it's a compiler bug?

_________________________________________________________ Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Reply by email

Jesus Reyes
to Jesus Reyes

update: the following program output:
TRUE
OTHER

program problem;
var
        B: boolean;
begin
        FillChar(B, SizeOf(B), 255);
        if b then WriteLn(TRUE)
        else WriteLn(FALSE);
        case b of
                true: WriteLn(True);
                false: WriteLn(False);
                else WriteLn('OTHER');
        end;
end.

this one tested with: Free Pascal Compiler version 1.0.10 [2003/09/01] for i386 and Free Pascal Compiler version 1.9.5 [2004/12/29] for i386

--- Jesus Reyes wrote 33 lines
I have doubts about this so I made a small test, what I want to know is if a true boolean value be internally be represented by any value different from 0. program problem; var B: boolean; begin FillChar(B, SizeOf(B), 255); case b of true: WriteLn(True); false: WriteLn(False); else WriteLn('OTHER'); end; end. I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for i386 under linux. the program output: OTHER, it's a compiler bug? _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

_________________________________________________________ Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Reply by email

Jesus Reyes
to Jesus Reyes

Never mind, I friend of mine confirmed that delphi does the same output.

regards.

--- Jesus Reyes wrote 67 lines
update: the following program output: TRUE OTHER program problem; var B: boolean; begin FillChar(B, SizeOf(B), 255); if b then WriteLn(TRUE) else WriteLn(FALSE); case b of true: WriteLn(True); false: WriteLn(False); else WriteLn('OTHER'); end; end. this one tested with: Free Pascal Compiler version 1.0.10 [2003/09/01] for i386 and Free Pascal Compiler version 1.9.5 [2004/12/29] for i386 --- Jesus Reyes escribió: > I have doubts about this so I made a small test, what I want to > know > is if a true boolean value be internally be represented by any > value > different from 0. > > program problem; > var > B: boolean; > begin > FillChar(B, SizeOf(B), 255); > case b of > true: WriteLn(True); > false: WriteLn(False); > else WriteLn('OTHER'); > end; > end. > > I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for > i386 > under linux. > > the program output: OTHER, it's a compiler bug? > > _________________________________________________________ > Do You Yahoo!? > La mejor conexión a internet y 25MB extra a tu correo por $100 al > mes. http://net.yahoo.com.mx > > _______________________________________________ > fpc-devel maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

_________________________________________________________ Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Reply by email

peter green
to Jesus Reyes: I have doubts about this so I made a small test, what I want to know is if a true boolean…

you are forciblly putting an out of range value in a variable what do you expect to happen?

Show quoted text 37 lines
-----Original Message----- From: Behalf Of Jesus Reyes Sent: 30 December 2004 19:37 To: lista de fpc-devel Subject: [fpc-devel] compiler bug? I have doubts about this so I made a small test, what I want to know is if a true boolean value be internally be represented by any value different from 0. program problem; var B: boolean; begin FillChar(B, SizeOf(B), 255); case b of true: WriteLn(True); false: WriteLn(False); else WriteLn('OTHER'); end; end. I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for i386 under linux. the program output: OTHER, it's a compiler bug? _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Nico Aragón
to peter green

El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:

you are forciblly putting an out of range value in a variable what do you expect to happen?

I think it's slightly subtler. I guess that this code:

  if not b then
     WriteLn('False')
  else if b then
     WriteLn('True')
  else
     WriteLn('Other');

...could throw a different result.

IIRC, any non-zero value is evaluated as "True" for a Boolean variable. The problem with the case statement is that Jesús is asking the compiler which specific value it chooses for assignements... and getting surprised because it's not what he expected. I guess the compiler uses 1 instead of 255. But it's surely documented anyway.

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Jesus Reyes
to peter green: you are forciblly putting an out of range value in a variable what do you expect to…
--- peter green wrote 6 lines
you are forciblly putting an out of range value in a variable what do you expect to happen?

Of course the program was made to do that evident, but what happen when you find a procedure, for example:

procedure doAorB(value: boolean);
begin
  case value of
    true: doA;
    false: doB;
  end;
end;

one might think either doA or doB will executed, but the reality is that sometimes neither doA or doB will do.

_________________________________________________________ Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Reply by email

Nico Aragón
to peter green: you are forciblly putting an out of range value in a variable what do you expect to…

El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:

you are forciblly putting an out of range value in a variable what do you expect to happen?

I think it's slightly subtler. I guess that this code:

  if not b then
     WriteLn('False')
  else if b then
     WriteLn('True')
  else
     WriteLn('Other');

...could throw a different result.

IIRC, any non-zero value is evaluated as "True" for a Boolean variable. The problem with the case statement is that Jesús is asking the compiler which specific value it chooses for assignements... and getting surprised because it's not what he expected. I guess the compiler uses 1 instead of 255. But it's surely documented anyway.

saludos, Nico Aragón http://espira.net/nico/

Reply by email

peter green
to Jesus Reyes: Of course the program was made to do that evident, but what happen when you find a…

I think the old saying goes garbage in garbage out.

range checking should probablly catch this sort of stuff but that has a high performance penalty and is therefore usually disabled.

At the end of the day if you force out of range data into your booleans then
its your problem.
Show quoted text 41 lines
-----Original Message----- From: Behalf Of Jesus Reyes Sent: 30 December 2004 21:49 To: FPC developers' list Subject: RE: [fpc-devel] compiler bug? --- peter green escribió: > you are forciblly putting an out of range value in a variable what > do you > expect to happen? > > > Of course the program was made to do that evident, but what happen when you find a procedure, for example: procedure doAorB(value: boolean); begin case value of true: doA; false: doB; end; end; one might think either doA or doB will executed, but the reality is that sometimes neither doA or doB will do. _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jeff Pohlmeyer

How about this one:

program problem;
begin
  Write('Test One: ');
  if ( boolean(255) ) then WriteLn(True) else WriteLn(False);
  Write('Test Two: ');
  WriteLn( boolean(255) );
end.

FPC 1.9.4 output:
Test One: FALSE
Test Two: TRUE

Kylix 1.0 output:
Test One: TRUE
Test Two: Segmentation fault

Looks like *somebody* has a compiler bug, anyway ;-)

__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

Reply by email

Peter Vreman
to Jeff Pohlmeyer
Show quoted text 24 lines
How about this one: program problem; begin Write('Test One: '); if ( boolean(255) ) then WriteLn(True) else WriteLn(False); Write('Test Two: '); WriteLn( boolean(255) ); end. FPC 1.9.4 output: Test One: FALSE Test Two: TRUE Kylix 1.0 output: Test One: TRUE Test Two: Segmentation fault Looks like *somebody* has a compiler bug, anyway ;-)

We know this issue. There is even a comment in the RTL what can go wrong:

{ Can't use array[boolean] because b can be >0 ! }

  if b then
    Write_Str(Len,t,'TRUE')
  else
    Write_Str(Len,t,'FALSE');

Reply by email

DrDiettrich
to Nico Aragón: El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste: I think it's slightly…
Nico Aragón wrote
IIRC, any non-zero value is evaluated as "True" for a Boolean variable.

You should not guess about any implementation. Forcing out-of-range values into strictly typed variables is a user bug, at the full risk of (and shame on) that user.

Who's to blame when somebody applies FillChar on a pointer variable, and the program consequently crashes?

else WriteLn('Other');
This better should read:
	WriteLn('corrupt data space!!!'); Panic;

DoDi

Reply by email

Nico Aragón
to DrDiettrich

El Viernes, 31 de Diciembre de 2004 13:13, DrDiettrich escribiste:

Nico Aragón wrote: > IIRC, any non-zero value is evaluated as "True" for a Boolean variable. You should not guess about any implementation.

I don't. Do I?

Show quoted text 5 lines
> else > WriteLn('Other'); This better should read: WriteLn('corrupt data space!!!'); Panic;

Much more useful :->

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Florian Klaempfl
to Nico Aragón

Nico Aragón wrote:

type boolean = (false,true);
is how boolean is defined/declared

so assigning anything else than true or false to a boolean might cause problems :)

Show quoted text 11 lines
>> else >> WriteLn('Other'); > >This better should read: > WriteLn('corrupt data space!!!'); Panic; Much more useful :->

Reply by email

Nico Aragón
to Florian Klaempfl

El Viernes, 31 de Diciembre de 2004 14:58, Florian Klaempfl escribiste:

Show quoted text 5 lines
type boolean = (false,true); is how boolean is defined/declared so assigning anything else than true or false to a boolean might cause problems :)

That's great! But why do you tell it *to me*?

I didn't start this thread and I've only tried to find an explanation why it doesn't work and refered Jesús to the documentation.

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Florian Klaempfl
to Nico Aragón
Nico Aragón wrote 10 lines
El Viernes, 31 de Diciembre de 2004 14:58, Florian Klaempfl escribiste: >type boolean = (false,true); >is how boolean is defined/declared > >so assigning anything else than true or false to a boolean might cause >problems :) That's great! But why do you tell it *to me*?

I only cross read the thread and wanted to clarify things :)

I didn't start this thread and I've only tried to find an explanation why it doesn't work and refered Jesús to the documentation.

Reply by email

Jose Manuel
to Nico Aragón: El Viernes, 31 de Diciembre de 2004 13:13, DrDiettrich escribiste: I don't. Do I? Much…
Show quoted text 8 lines
> > else > > WriteLn('Other'); > > This better should read: > WriteLn('corrupt data space!!!'); Panic; Much more useful :->

(AFAIK) you do.
You're programing, the C way.

You can't expect that -1 equals True, and any other value equals false, (I really dunno, but I think I could remember that) in Visual Basic is 1 instead of -1). As far as I can know Boolean type is in Pascal, that, a type. I think there's no specifation how the compiler (ANSI PASCAL, ANSI PASCAL 2) should implement that. (IMHO bad programming pratice)

If anyone goes on wild (and explicity) casting integer, enumerated, etc.. types into booleans, of course, many things may happen. But I reiterate, as far as I can know, that is compiler implementation dependent, and one can't depend on it.

Hower, should my opinion serve to anybody, I think that Kylix, Borland anf FPC (according to contionals Delphi, ObjFpc, etc) should share the same behoviour. As long as compatibility is broken between Delphy and Kylix, it's up to you.

But, and I beg everyone's pardon if I' too dork, This is Pacal, Not C. I can't really find out why I would need ro cast Boolean(Integer(255)= into a boolean, and I guess that if I knew, I would surely programming in C.

Reply by email

Nico Aragón
to Jose Manuel

El Viernes, 31 de Diciembre de 2004 18:40, Jose Manuel escribiste:

Show quoted text 9 lines
> > > else > > > WriteLn('Other'); > > > > This better should read: > > WriteLn('corrupt data space!!!'); Panic; > > Much more useful :-> (AFAIK) you do.

¡Serás melón! ¿A qué se supone que estás respondiendo ahí? X'D

You're programing, the C way. You can't expect that -1 equals True, and any other value equals false, (I

You can expect whatever it's documented "equals true" and sometimes you must know what's the internal representation of the data, i.e. when you're linking with code written in different languages or writing inline assembler.

¡Feliz año, torpedo! :-)

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Jose Manuel
to Nico Aragón

[]

> You're programing, the C way.

[]

Show quoted text 6 lines
> You can't expect that -1 equals True, and any other value equals false, (I You can expect whatever it's documented "equals true" and sometimes you must

That's right. I can expect whatever is documented. In C there's no boolean type. In Pascal (as in C++), boolean type is on its own. If you typecast an integer to a boolean you are on you own, Maybe I'm wrong but AFAIK there's no documented way how a Pascal Compiler ought to implement Boolean Types. (Not to say Windows 1,2,4 bytes Booleans)

know what's the internal representation of the data, i.e. when you're linking with code written in different languages or writing inline assembler.

¡Chapuzas!
You can't depend on the internal representation of any data. Maybe a quick and dirty fix, but no further
Pascal is Pascal. Clearity and type safe. Anyway Pascal allows that (explicit, it's gotta be explicit) conversion, try it in ADA. I'm afraid your a C(ecer).
And assembler ... Well! We all have to resort to assembler some time or later. But I see no relation.

¡Feliz año, torpedo! :-)

Posdepué d'aberhablaó contigo estoy un pelín disgustaó Recuerdo2 patiytuhijo

Show quoted text 11 lines
-- saludos, Nico Aragón http://espira.net/nico/ _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

peter green
to Jose Manuel

Different languages approach boolean operations in different ways.

1: the C way
false=0 true=anything else seperate logical and bitwise operators. 2: the BASIC way (also used by the access database) false=0 true=-1 logical and bitwise operations therefore equivilent (though it should be noted that vbs if statement accepts anything nonzero as true)
3: the PASCAL way
boolean is a totally seperate type from integer types so the compiler knows whether you mean logial or bitwise operations. I don't know if false and true having ordinal values of 0 and 1 is part of a standard or a borlandism but im pretty sure its what all pascal compilers anyone cares about do.

Reply by email

DrDiettrich
to Nico Aragón: El Viernes, 31 de Diciembre de 2004 13:13, DrDiettrich escribiste: I don't. Do I? Much…
Nico Aragón wrote 5 lines
> > IIRC, any non-zero value is evaluated as "True" for a Boolean variable. > > You should not guess about any implementation. I don't. Do I?

Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using typecasts may result in silent type conversion, returning something different from the really stored pattern.

The boolean data type is distinct from other data types, so that it's wild guessing that every compiler and compiler version will treat boolean values and variables in the same way, as observed when using a specific version of an specific compiler.

For completeness: Many people also consider ByteBool etc. as being "boolean". These types have been made compatible with boolean *intentionally*, with the documented behaviour that any non-zero value will evaluate to True, under circumstances. But you may test yourself what will happen when you compare such a variable with an non-boolean value - it's not perfectly specified when the nonzero=true evaluation will be effective. Try this with various compilers:

var b: ByteBool;
...
case b of
True: ...
False: ...
42: ...
else ...
end;

It's unspecified which compiler will accept the True and False constants here at all...

DoDi

Reply by email

Jose Manuel
to peter green: Different languages approach boolean operations in different ways. 1: the C way false=0…
3: the PASCAL way boolean is a totally seperate type from integer types so the compiler knows whether you mean logial or bitwise operations. I don't know if false

That's the point. :-)

and true having ordinal values of 0 and 1 is part of a standard or a borlandism but im pretty sure its what all pascal compilers anyone cares about do.

So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant).

JMR

Reply by email

Nico Aragón
to Jose Manuel

El Sábado, 1 de Enero de 2005 09:06, Jose Manuel escribiste:

So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of

As far as I know:

Ord(True) > Ord(False) = True
Succ(False) = True

...are not only legal but also mandatory in the standard. But that doesn't mean anything. You can implement Ord and Succ to return that values for booleans no matter how you implemented the type.

type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant).

It's possible to implement the boolean type as an enumeration and still implement the boolean evaluation as " 0". I'm pretty sure to have seen this in some specification, I just can't remember in which right now :-)

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Nico Aragón
to DrDiettrich: Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using…

[merged responses to two messages]

El Sábado, 1 de Enero de 2005 06:54, DrDiettrich escribiste:

> ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-)

http://hotel.jp-guide.net/job/point/melon.jpg

(Eierkopf? ;-)

My rudimentary... I meant my non-existent... whatever :-)

> ¡Feliz año, torpedo! :-) (Blindgänger? ;-)

It's the same in English.

Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein Gutes Neues Jahr allerseits!

All of that! :-)

*************

El Sábado, 1 de Enero de 2005 06:29, DrDiettrich escribiste:

Show quoted text 9 lines
Nico Aragón wrote: > > > IIRC, any non-zero value is evaluated as "True" for a Boolean > > > variable. > > > > You should not guess about any implementation. > > I don't. Do I? Yes, you do.

No, I don't. Maybe you're confusing me with Jesús? If you read my last answer to José Manuel, you'll see that I say exactly the opposite. So I can't agree more with the rest of your post.

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Jose Manuel
to Nico Aragón: El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste: I think it's slightly…
Show quoted text 13 lines
I think it's slightly subtler. I guess that this code: if not b then WriteLn('False') else if b then WriteLn('True') else WriteLn('Other'); ...could throw a different result. IIRC, any non-zero value is evaluated as "True" for a Boolean variable. The

No, and no. There your assuming some implementation of the type Boolean. I Peter stated, bitwise logic and Boolean logic are neatly separated in Pacal. You say you're not counting on how it's implemented and still insists in expressions as "True 0". No way.

Show quoted text 5 lines
problem with the case statement is that Jesús is asking the compiler which specific value it chooses for assignements... and getting surprised because it's not what he expected. I guess the compiler uses 1 instead of

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨

255. But

Dodi told you, Peter told you and I tell you now. Don't guess anything about how a compiler internally implementens a type. Peter could have said so louder but not clearer: if you cast a type into another type that can result in an overflow, it's programmer's fault, 'cause at least in Pascal (exceptions apart) those cast have to be done explicitly. And you can't trust wheter True is 255, 1, -1 or use simply another bit pattern or whathever, which is perfectly legal, Don't ya say you agree with everyone when you are clearly on the contrary.

I think this is goin' far behind this list is intended to. All I can say is that there should be some kind of compatibility for those who, as me (:-( guilty), sometimes recurre to Fix'n Dirty, I mean: FPC (at least in FPCOBJ or DELPHI compatibilty mode), Kilyx and Delphy should behave the same, but as long as Kylix and Delphi don't keep the same (sane?) behaviour, it's up to you, FPC developers to choose what you find more (efficient?, accurate to reality, compatible? I dunno, but surely you do).... Anyway, I think it's pointless to go on with this

it's surely documented anyway.

The internal implementation of a Boolean type, I guess it ain't? Surely for every compiler it is, but there's no standard way and I'm quite sure there's no standard how it should behave when typecasting.

Show quoted text 5 lines
-- saludos, Nico Aragón

Bye, Nico and everyone.

JMR BTW: I don't wish everyone "Happy Christmas" 'cause there are a lot of religions, and to too many of them, Christmas has no sense. Anyhow my best wishes to everyone For Dodi's Sake (What he asked Nico about his 'rudimentary spanish'), and to anyone who might be interested: a) ¡Hola, Torpedo! That's slang. You could translate it into 'Hi, Dork!' b) Feliz Año: In effect, it's the same as in English: It means merely: 'Happy new year!'

Reply by email

Nico Aragón
to Jose Manuel

El Domingo, 2 de Enero de 2005 17:01, Jose Manuel escribiste:

Show quoted text 7 lines
> IIRC, any non-zero value is evaluated as "True" for a Boolean > variable. The No, and no. There your assuming some implementation of the type Boolean. I Peter stated, bitwise logic and Boolean logic are neatly separated in Pacal. You say you're not counting on how it's implemented and still insists in expressions as "True 0". No way.

I don't insist in anything. This message was stalled because days ago I used another mail address that's not subscribed. (I hope that) you can see that's the very same message that was then resent and discussed.

Dodi told you, Peter told you and I tell you now. Don't guess anything about how a compiler internally implementens a type.

In the message you're answering to, I'm clearly saying that it's better to read the documentation than to make tests programs or making guesses. You're quoting selectively to suggest that I say the opposite.

That's childish. The original message is there for anyone that wants to read it. I can be wrong, but let me be wrong saying what I say, not anything else!!

saludos, Nico Aragón http://espira.net/nico/

Reply by email

Michael Van Canneyt
to Nico Aragón

No offence meant but,

Can this thread (see subject) please be stopped ?
It is no longer interesting for the rest of us,
and threatens to lead to a flame war.
I'm sure no-one is interested in that either.

Michael.

Reply by email