Bug report with = (comparission)
Patrice
I came across a new bug (at least for me).
Sample program exibiting the behaviour.
my_var= "2"
if my_var= 2
? "TRUE"
else
? "FALSE"
endif
return
Result is FALSE, I was expecting an error in the comparission.
Patrice
Patrick Mast
This is not a bug but a feature. ;-)
You can also do :
IF HB_IsNumeric(my_var) .AND. my_var=2
...
Patrick
Patrice
Hello Patrick,
>This is not a bug but a feature. ;-)
Noooo, you kidding, fouls's day is in a month.
In case you are serious, how to switch off this amazing Microsoft alike
FEATURE ?
After checking, the feature do not appear in the xHarbour Language
Reference Guide, this why I call it a bug !
I found another unexpected amazing feature :-))
? max(1, "a"), min(1,"a")
displays 97 and 1
Starting to be affraid !
Patrice
Ella
Patrice,
>
> After checking, the feature do not appear in the xHarbour Language
> Reference Guide, this why I call it a bug !
Please check the xHarbour documentation for "assignment" or " = "
operator.
When doing
if myvalue = 123
you are testing the result of the assignment against the boolean TRUE
value.
>
> I found another unexpected amazing feature :-))
> ? max(1, "a"), min(1,"a")
> displays 97 and 1
Please check in the documentation the "comparison operators" and take
a look at the comparison of values having "character" data type.
It's a well-known feature of xHarbour, that character strings
consisting of a single character are handled as their integer ASCII
values, where the context requires a BYTE value in C - or a TINY
INTEGER in SQL
This behaviour is the same in the current, living main-stream
softwares.
>
> Starting to be affraid !
>
> Patrice
VFP is dead, because its core developers preferred to maintain
compatibility with a theoretical model, which was designed for a
deprecated hardware and OS.
Ella
Ella
>
> When doing
>
> if myvalue = 123
>
> you are testing the result of the assignment against the boolean TRUE
> value.
>
Oops, sorry, in thsi particular case:
myvar := "2"
if myvar = 2
the = operator behaves as a comparison operator, and the ASCII value
of "2" is compared with numeric value 2
Personally I use always == for comparisons.
Ella
dlzc
On Mar 2, 12:41 pm, Patrice <f...@home.fr> wrote:
> On Tue, 2 Mar 2010 14:27:18 +0100, Patrick Mast <patrickm...@me.com> wrote:
>
> >This is not a bug but a feature. ;-)
>
> Noooo, you kidding, fouls's day is in a
> month.
>
> In case you are serious, how to switch off
> this amazing Microsoft alike FEATURE ?
Returning three values (.T., .F., and Programmer Error) is not a
desirable feature.
> After checking, the feature do not appear
> in the xHarbour Language Reference Guide, this
> why I call it a bug !
A lot doesn't appear there yet (like many of the niceties). Ella has
your answer.
> I found another unexpected amazing feature :-))
> ? max(1, "a"), min(1,"a")
> displays 97 and 1
>
> Starting to be affraid !
xBase is not a strongly typed language. In this case, Hungarian
notation would have helped you.
If you fear your own typing abilities, I'm sure someone can strip you
of the freedom. Even take your money for it.
David A. Smith
Patrice
>the = operator behaves as a comparison operator, and the ASCII value
>of "2" is compared with numeric value 2
>
>Personally I use always == for comparisons.
Patrice
Patrice
>>
>> � � � � I found another unexpected amazing feature :-))
>> � � � � ? max(1, "a"), min(1,"a")
>> � � � � displays 97 and 1
>
>Please check in the documentation the "comparison operators" and take
>a look at the comparison of values having "character" data type.
"The values of <Expression1> and <Expression2> must have the same data type or
can be NIL, and are compared."
>
>It's a well-known feature of xHarbour, that character strings
>consisting of a single character are handled as their integer ASCII
>values, where the context requires a BYTE value in C - or a TINY
>INTEGER in SQL
compatible with Clipper in a language which is supposed to be 100% compatible
with Clipper !
A nice sentence, is n't it ?
>
>This behaviour is the same in the current, living main-stream
>softwares.
Patrice
Patrice
Hello David,
>>
>> >This is not a bug but a feature. ;-)
>>
>> � � � � Noooo, you kidding, fouls's day is in a
>> month.
>>
>> � � � � In case you are serious, how to switch off
>> this amazing Microsoft alike FEATURE ?
>
>Returning three values (.T., .F., and Programmer Error) is not a
>desirable feature.
This is just what Clipper does by throwing a very nice "argument error"
to my face.
>
>> � � � � After checking, the feature do not appear
>> in the xHarbour Language Reference Guide, this
>> why I call it a bug !
>
>A lot doesn't appear there yet (like many of the niceties). Ella has
>your answer.
>
>> � � � � I found another unexpected amazing feature :-))
>> � � � � ? max(1, "a"), min(1,"a")
>> � � � � displays 97 and 1
>>
>> � � � � Starting to be affraid !
>
>xBase is not a strongly typed language. In this case, Hungarian
>notation would have helped you.
>
>If you fear your own typing abilities, I'm sure someone can strip you
>of the freedom. Even take your money for it.
No, what I fear is an undocumented implicit type casting for a special
case in a certain data type.
Patrice
Ash
>
> - Show quoted text -
Harbour Version 2.0 produces the following error:
Error BASE/1071 Argument error: =
Ash
Ella
On 3 mar., 04:16, Patrice <f...@home.fr> wrote:
> >> I found another unexpected amazing feature :-))
> >> ? max(1, "a"), min(1,"a")
> >> displays 97 and 1
>
> >Please check in the documentation the "comparison operators" and take
> >a look at the comparison of values having "character" data type.
>
> The documentation starts with:
> "The values of <Expression1> and <Expression2> must have the same data type or
> can be NIL, and are compared."
...and continues with explaining that string comparisons are based on
the ASCII values of characters.
If I follow your logic, then Clipper has a bug when not throwing
runtime error in case of doing
if 0 == 0.0
>
> >It's a well-known feature of xHarbour, that character strings
> >consisting of a single character are handled as their integer ASCII
> >values, where the context requires a BYTE value in C - or a TINY
> >INTEGER in SQL
>
> So, we are speaking about well-known undocumented feature which is not
> compatible with Clipper in a language which is supposed to be 100% compatible
> with Clipper !
> A nice sentence, is n't it ?
100% compatibility in Error Handling? So I must not use TRY / CATCH to
keep my code easy to be read and maintained?
>
> >This behaviour is the same in the current, living main-stream
> >softwares.
>
> Which ones ?
>
> Patrice
Actually over 40% of web applications are written in PHP, and in my
scripting experience that language has many strange casting features,
and in general it's more difficult to be designed, coded and
maintained an application in it, than in xHarbour.
Ella
Patrice
On Wed, 3 Mar 2010 01:41:06 -0800 (PST), Ella <ella....@xharbour.com> wrote:
>Hello Patrice,
>
>
>On 3 mar., 04:16, Patrice <f...@home.fr> wrote:
>> >> I found another unexpected amazing feature :-))
>> >> ? max(1, "a"), min(1,"a")
>> >> displays 97 and 1
>>
>> >Please check in the documentation the "comparison operators" and take
>> >a look at the comparison of values having "character" data type.
>>
>> � � � � The documentation starts with:
>> "The values of <Expression1> and <Expression2> must have the same data type or
>> can be NIL, and are compared."
>
>
>...and continues with explaining that string comparisons are based on
>the ASCII values of characters.
This sentence is about comparing 2 strings, unless you consider "a" and
1 as being 2 strings, it does not apply there.
>
>If I follow your logic, then Clipper has a bug when not throwing
>runtime error in case of doing
>
>if 0 == 0.0
NO, my logic is that a character string and a numeric value are 2
different types of data. It is Clipper's logic and Harbour's logic too.
0 and 0.0 are numeric values in clipper, so no problem there.
>
>>
>> >It's a well-known feature of xHarbour, that character strings
>> >consisting of a single character are handled as their integer ASCII
>> >values, where the context requires a BYTE value in C - or a TINY
>> >INTEGER in SQL
>>
>> � � � � So, we are speaking about well-known undocumented feature which is not
>> compatible with Clipper in a language which is supposed to be 100% compatible
>> with Clipper !
>> � � � � A nice sentence, is n't it ?
>
>100% compatibility in Error Handling? So I must not use TRY / CATCH to
>keep my code easy to be read and maintained?
Feel free to TRY and CATCH as much as you want.
>
>>
>> >This behaviour is the same in the current, living main-stream
>> >softwares.
>>
>> � � � � Which ones ?
>>
>> � � � � Patrice
>
>Actually over 40% of web applications are written in PHP, and in my
>scripting experience that language has many strange casting features,
>and in general it's more difficult to be designed, coded and
>maintained an application in it, than in xHarbour.
PHP is known to do type casting and it is documented, so it is a matter
of reading the documentation and of being very carefull and may be lignhting a
candle or two :)
Clipper is known to not do casting.
Patrice
Patrice
Hi Ash,
>
>Harbour Version 2.0 produces the following error:
>
>Error BASE/1071 Argument error: =
Nice to see this, thanks for your support.
Patrice
Ella
>
> PHP is known to do type casting and it is documented, so it is a matter
> of reading the documentation and of being very carefull and may be lignhting a
> candle or two :)
...and JavaScript - core component for AJAX - also does many-may type
castings.
Castings are very necessary for coding many kinds of applications,
because of usability reasons.
Strict languages are a good choice for sophysticated softwares with
many thousands of users.
My client for the server-side script is in VxH :-)
I wish you happy Harbouring !
Ella
Ash
I do not remember ever having to deal with casting in Clipper. If you
assigned a string to a numeric variable, the variable type changed to
Character. Assigning a numeric value to a character field in a table
would end up in run time error, however.
How compatible is xHarbour with Clipper? This is what folk porting
applications to xHarbour need to know.
Ash.
Antonio Martinez
IMHO one character digit as numeric is a bad feature for a xbase language...
I do know this bad feature, but often to brain broken looking straight
problems relationship that bad feature.
Sorry my bad english
Patrice escribi� en mensaje <40spo51o5cvopjgms...@4ax.com>...
Ron Pinkas
> assigned a string to a numeric variable, the variable type changed to
> Character. Assigning a numeric value to a character field in a table
> would end up in run time error, however.
There's no need to deal with casing in xHarbour, and all you described above
is identical in xHarbour.
> How compatible is xHarbour with Clipper? This is what folk porting
> applications to xHarbour need to know.
xHarbour is 100% backward compatible with Clipper, meaning that any valid
Clipper code, which runs correctly with the native error handler of Clipper
will perform identically when compiled and linked with xHarbour. The reverse
is not correct because of the many xHarbour extensions. This means that
xHarbour is NOT ERROR COMPATIBLE with Clipper, since there are some
operations which will trigger the error handler in Clipper, but are
perfectly legal in xHarbour. This is the very nature of BACKWARD
compatibility.
Ron
Ron Pinkas
This is not a bug, but rather an intentional extension added to xHarbour
back in April 2002. Sadly it was not included in the xHarbour Reference
Guide. This will of course be corrected promptly.
On the CVS exists a file named:
xharbour\xdiff.txt
Also you may visit:
http://www.xharbour.org/index.asp?page=product/extensions
In both sources you will find:
String Index and all String of 1 character length, automatically carry a
secondary CHAR type, which means they are also compatible with numeric
operations.
Additionally you may review:
xharbour\tests\testchar.prg
Essentially this extension supports a C like "char" type, which is NUMERIC
COMPATIBLE. IOW, it's still a normal string which is 100% Clipper
compatible, with the one added benefit of being numeric compatible, but ONLY
IF it's used in a NUMERIC CONTEXT which would otherwise produce an ERROR.
Then instead of raising an error the ASCII value of the character will be
used, to allow the numeric context to be evaluated.
Ron