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
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 p...@planetgis.co.za:
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?
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?
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?
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?
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?
2010/1/31 Paul van Helden p...@planetgis.co.za: 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
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?
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?
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?
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?
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?
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?
[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. 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?
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 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?
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 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?
[] 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?
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?
--- 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?
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?
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
