Re: [fpc-devel] Compiler bug in macro handling?
No,
if you put a semicolon in there, you will get wrong syntax,
no matter what the datatype is.
Example:
{$MACRO ON}
{$define Fifteen:=15;}
{$define Twelve:=12;}
...
if HDCOUNT0 >= COUNT0 then X := Fifteen
else X := Twelve;
will generate this Pascal statement:
if HDCOUNT0 >= COUNT0 then X := 15;
else X := 12;
and the semicolon before the else is wrong in Pascal syntax.
Remember: $define (macro processing) is stupid text replacement ...
HTH,
Bernd
Am 12.04.2017 um 20:11 schrieb Giuliano Colla:
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto:
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Without semicolon it works!
Thanks a lot.
BTW, do you think that this holds true only for the define of boolean
values?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Il 12/04/2017 19:54, Bernd Oppolzer ha scritto:
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
You are right, I was misled by some examples in the docs, but reading
more carefully, actually it states that the syntax is
{$define ident:=expr}
so that my semicolon is part of the define, and not a termination as I
had understood.
Thanks a lot.
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto:
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Without semicolon it works!
Thanks a lot.
BTW, do you think that this holds true only for the define of boolean
values?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Hi Guiliano,
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
HTH,
kind regards
Bernd
Am 12.04.2017 um 19:39 schrieb Giuliano Colla:
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 := Negativa;
gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.
But if I change the code into:
if HDCOUNT0 >= COUNT0 then V_PIU0 := False
else V_PIU0 := True;
(which IMHO should be identical) it compiles without complaining.
Am I doing something wrong or it is a bug?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
On Wed, 12 Apr 2017, Giuliano Colla wrote:
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 := Negativa;
gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.
But if I change the code into:
if HDCOUNT0 >= COUNT0 then V_PIU0 := False
else V_PIU0 := True;
(which IMHO should be identical) it compiles without complaining.
Am I doing something wrong or it is a bug?
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Compiler bug in macro handling?
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 := Negativa;
gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.
But if I change the code into:
if HDCOUNT0 >= COUNT0 then V_PIU0 := False
else V_PIU0 := True;
(which IMHO should be identical) it compiles without complaining.
Am I doing something wrong or it is a bug?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] compiler bug with structs within nested classes
I heavily use nested classes in general and I've come across a problem where I cannot make explicit references data structures from another unit while embedded within classes. //Developer/Source/Builds/SCS/Linux/64/Output/uRTSPd.o:(.data+0x52f): undefined reference to `RTTI_DBMRTSP_DEF112' The linking error will change as I tried referencing different structs contained in dbmRTSP.pas unit. I can create classes/structs (that reference said structs) within the dbmRTSP unit that link, but when I reference the same structs from outside this unit I get the linking error above (which again changes with respect to the struct) http://bugs.freepascal.org/view.php?id=19534 Anyone familiar with nested classes look into this for me? Thanks a lot! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
Paul van Helden wrote: > > And to regain my productivity: to figure out how to debug with Lazarus > the way I'm used to in Delphi... I miss this too, though recently there was a lot of improvements to debugging support. All I can say is, be thankful you didn't start 5 years ago with FPC where debugging was much worse. I now got so used to using log files for debugging, I actually forgot how easy and reliable it was to debug in Delphi 7 and Kylix 3 IDE's. Oh well, FPC brings many other features to the table which still makes it far better than using Delphi and Kylix. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
In our previous episode, Paul van Helden said: > I have never used the function name instead of "Result", but of course > you can. Using () after a function to me seems so C-like and > un-Pascallish but it works. > > But it is things like this that trip up people coming from Delphi, I > guess. Isn't this a potential improvement to the compiler though: scan > for overloaded functions before assuming that it is the result value > (like Delphi does)? (Or warn about overloaded functions without > parameters, similar to mode objfpc disallowing parameter names that are > the same as methods?) For what Delphi does, there is $mode delphi. Mode objfpc has a significant part of the combined FPC/Lazarus dialect written in it, which might actually use the function result TP style. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
On 2010/01/31 10:30 AM, Daniël Mantione wrote:
This behaviour is intentional to allow you to read instead of just
write the function result. The incompatibility just affects recursive
procedures without parameters, which seldomly occurs, because normally
the parameters determine the behaviour of the function, and a
recursive function without parameters would prevent you writing a
mechanism that makes the recursive function terminate.
Only if the behaviour of the recursive function is controller by
global variables, then you can actually write a recursive function
without parameters. Because this is so seldom, and the desire to read
from the function result is extremely common, there is a strong case
for this behaviour.
OK, thanks. Also to Cobines for pointing out $mode delphi works as (I)
expected. I'm deliberately writing new units to compile with $mode
objfpc so I still have lots to learn. I do think a compiler hint would
be nice, either at the method declaration ("Hint: Overloaded function
without parameters may conflict with function result value.") or when
using the function name as the result in code ("Hint: Ambiguous use of
function name; use () if you wanted to call the overloaded function
instead"). Or perhaps I must get used to using() for functions without
parameters, and even better: give me another $mode where (like C++)
MethodName; is equivalent to @MethodName, so I'd be forced to use (). :-)
Indeed Borland did invent "result" as a method to read from the
function result, so FPC had to support that too.
I must say I prefer Result. It reads much easier, so I'd say it is more
to the spirit of Pascal than to have to use () to disambiguate things.
(So Borland /did/ actually invent some useful stuff)
Being able to read the result is +1 Pascal, -1 C. If only I can have
"var I, J: Integer;" anywhere between a begin and end and (inline)
method implementations inside class definitions... sigh :-)
And to regain my productivity: to figure out how to debug with Lazarus
the way I'm used to in Delphi...
Regards,
Paul.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
Op Sun, 31 Jan 2010, schreef Paul van Helden: Of course Thanks Cobines! I have never used the function name instead of "Result", but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential improvement to the compiler though: scan for overloaded functions before assuming that it is the result value (like Delphi does)? (Or warn about overloaded functions without parameters, similar to mode objfpc disallowing parameter names that are the same as methods?) This behaviour is intentional to allow you to read instead of just write the function result. The incompatibility just affects recursive procedures without parameters, which seldomly occurs, because normally the parameters determine the behaviour of the function, and a recursive function without parameters would prevent you writing a mechanism that makes the recursive function terminate. Only if the behaviour of the recursive function is controller by global variables, then you can actually write a recursive function without parameters. Because this is so seldom, and the desire to read from the function result is extremely common, there is a strong case for this behaviour. Indeed Borland did invent "result" as a method to read from the function result, so FPC had to support that too. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
2010/1/31 Paul van Helden :
> But it is things like this that trip up people coming from Delphi, I guess.
> Isn't this a potential improvement to the compiler though: scan for
> overloaded functions before assuming that it is the result value (like
> Delphi does)? (Or warn about overloaded functions without parameters,
> similar to mode objfpc disallowing parameter names that are the same as
> methods?)
Just checked that if you use {$mode delphi} instead of {$mode objfpc}
then using:
Result:=GetValue_overloaded;
is correct.
--
cobines
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
Of course Thanks Cobines! I have never used the function name instead of "Result", but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential improvement to the compiler though: scan for overloaded functions before assuming that it is the result value (like Delphi does)? (Or warn about overloaded functions without parameters, similar to mode objfpc disallowing parameter names that are the same as methods?) On 2010/01/31 09:46 AM, cobines wrote: Isn't the "GetValue_overloaded" in 1: Result:=GetValue_overloaded the return value of the function? Maybe you should call it this way: Result:= GetValue_overloaded() That's why I think you get the warning. The reason you might be getting random results is that the return value has not been initialized. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
2010/1/31 Paul van Helden : > function TMyClass.GetValue_overloaded(SomeValue: Integer): Integer; > begin > case SomeValue of > 1: Result:=GetValue_overloaded; // compiler warning: "Function result > variable does not seem to be initialized" (!) > 2: Result:=GetValue_not_overloaded; > else > Result:=3; > end; > end; Isn't the "GetValue_overloaded" in 1: Result:=GetValue_overloaded the return value of the function? Maybe you should call it this way: Result:= GetValue_overloaded() That's why I think you get the warning. The reason you might be getting random results is that the return value has not been initialized. -- cobines ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Compiler bug?
Hi All,
I hope I'm doing something really dumb, but I have to say it is stuff
like this that is really disheartening to me. I've been using
FPC/Lazarus for a year now and I have to report that my rate of
development (compared to Delphi) has slowed down significantly...
The following simple program shows that calling an overloaded method
from its "twin" returns garbage:
program project1;
{$mode objfpc}{$H+}
type
TMyClass = class
public
function GetValue_not_overloaded: Integer;
function GetValue_overloaded: Integer; //overload; -- nice feature
not having to specify "overload"!
function GetValue_overloaded(SomeValue: Integer): Integer; //overload;
end;
function TMyClass.GetValue_not_overloaded: Integer;
begin
Result:=1;
end;
function TMyClass.GetValue_overloaded: Integer;
begin
Result:=2;
end;
function TMyClass.GetValue_overloaded(SomeValue: Integer): Integer;
begin
case SomeValue of
1: Result:=GetValue_overloaded; // compiler warning: "Function
result variable does not seem to be initialized" (!)
2: Result:=GetValue_not_overloaded;
else
Result:=3;
end;
end;
var
C: TMyClass;
R: Integer;
begin
C:=TMyClass.Create;
R:=C.GetValue_overloaded; // direct call works
WriteLn('Correct value: ', R);
R:=C.GetValue_overloaded(2); // overloaded function calls non
overloaded function, works
WriteLn('Correct value: ', R);
R:=C.GetValue_overloaded(1); // should return 2, I'm getting random
numbers starting with 422...
WriteLn('Random value: ', R);
ReadLn;
end.
I have tested this with Lazarus 0.9.28.2 (release) and its FPC 2.2.4, a
fresh build of Lazarus from SVN and FPC 2.4.1 as well as FPC 2.5.1 from
SVN. The only difference is the actual incorrect value returned! The
value isn't really random, it is the same each time a specific binary is
run and always start with 422...
FPC 2.2.4: 4221677
FPC 2.4.1: 4223590
FPC 2.5.1: 4220774
Now (assuming I'm not doing something dumb) if this had been a bug in
FPC trunk I can understand, but how can such a (common?) use case not
have been spotted over all these versions?
Perhaps it is bad form to use overloaded functions in such a way, and
perhaps I'm just frustrated because I'm using an old version of Delphi
to debug my code, then when I compile it in Lazarus my app implodes. I
like the latest debugger improvements but I still cannot inspect an
array element. (If there is a way, please let me know).
Regards,
Paul.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Domingo, 2 de Enero de 2005 17:01, Jose Manuel escribiste: > > 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/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
> 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.
> 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.
>
> --
> 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!'
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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
[EMAIL PROTECTED]
http://espira.net/nico/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
[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: > 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/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Nico Aragón wrote: > ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-) (Eierkopf? ;-) > ¡Feliz año, torpedo! :-) (Blindgänger? ;-) Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein Gutes Neues Jahr allerseits! DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
> 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
[] > > 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 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 > > -- > saludos, > > Nico Aragón > http://espira.net/nico/ > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Viernes, 31 de Diciembre de 2004 18:40, Jose Manuel escribiste:
> > > > 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/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
>
> > > 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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Viernes, 31 de Diciembre de 2004 17:18, Florian Klaempfl escribiste: > > That's great! But why do you tell it *to me*? > > I only cross read the thread and wanted to clarify things :) Oh, I see. Happy new year! :-) -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Nico Aragón wrote: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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 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/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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 :)
else
WriteLn('Other');
This better should read:
WriteLn('corrupt data space!!!'); Panic;
Much more useful :->
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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?
> > else
> > WriteLn('Other');
>
> This better should read:
> WriteLn('corrupt data space!!!'); Panic;
Much more useful :->
--
saludos,
Nico Aragón
http://espira.net/nico/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
peter green wrote: > > I think the old saying goes garbage in garbage out. 100% > range checking should probablly catch this sort of stuff but that has a high > performance penalty and is therefore usually disabled. IIRC range checking occurs on assignments, not on using the values, just to reduce the runtime checks. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
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. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes > Sent: 30 December 2004 21:49 > To: FPC developers' list > Subject: RE: [fpc-devel] compiler bug? > > > --- peter green <[EMAIL PROTECTED]> 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 - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Jueves, 30 de Diciembre de 2004 22:48, Jesus Reyes escribiste: > procedure doAorB(value: boolean); > begin > case value of > true: doA; > false: doB; > end; > end; if Value then DoA else BoB; -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
--- peter green <[EMAIL PROTECTED]> 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
you are forciblly putting an out of range value in a variable what do you
expect to happen?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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 - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Never mind, I friend of mine confirmed that delphi does the same
output.
regards.
--- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> 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 <[EMAIL PROTECTED]> 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 - fpc-devel@lists.freepascal.org
> > 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 - fpc-devel@lists.freepascal.org
> 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 - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
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 <[EMAIL PROTECTED]> 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 - fpc-devel@lists.freepascal.org
> 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 - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[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 - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
