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
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')
el
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/
___
--- 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);
be
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
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
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);
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);
el
On Thu, 30 Dec 2004, Marco van de Voort wrote:
> > Just don't use anything conflicting with other prefixes: lib, z, db, im,
> > sys.
> >
> > If we can agree on an implementation for archive handling that can be
> > considered a standard implementation for FPC (i.e. distributed with the
> > F
> > Talking about TList slowness:
> > In the last years TList and TStringList became slower and slower.
> > Are there any alternatives in classes.pp? A simple TList providing only
> > the very basics, less checks, no notifications, less virtuals, reordered
> > IFs ... ?
>
> TList has almost no virt
> Just don't use anything conflicting with other prefixes: lib, z, db, im, sys.
>
> If we can agree on an implementation for archive handling that can be
> considered a standard implementation for FPC (i.e. distributed with the
> FCL), 'fp' can (and should) be used.
>
> Naming a unit with 'u' s
On Thu, 30 Dec 2004, DrDiettrich wrote:
I split up my answers to your mail, because the topics are a bit different.
> Now you should have gotten the big picture of my intended activities.
> Many more questions will arise when I proceed with my work. I already
> decided to replace my own "stdc"
On Thu, 30 Dec 2004, DrDiettrich wrote:
> Hi there,
>
> I'm new to this list and want to introduce myself and my intended
> contributions to FreePascal.
>
> My name is Dr. Hans-Peter Diettrich, and I live in Flensburg (Germany).
> For brevity I use to sign my messages as DoDi. My main interest
> I'm new to this list and want to introduce myself and my intended
> contributions to FreePascal.
You are not new to everybody:-)
> archive files (cpio, tar...). I've already update or implemented some
> of these modules, now I want to define a common interface and API for
> compressed and arc
14 matches
Mail list logo
