1  |   Order by index

Oct 16, 2002, 8:25pm

This has just driven me nuts for an hour or so. I don't know if people are
aware of this, but these two little buggers actually return an error code if
something goes wrong which makes a nonsense of their function. I appreciate
that if all is well then there isn't a problem, but when an aw_int returns a
number you expect it to be the value of attribute you specified, but when it
returns an error code, the developer is none the wiser.

aw_bool is worse (in my opinion) as any error code will basically equate to
a TRUE ... although this depends on how you check the value. For example,
consider the following ...

If x = aw_bool returns a, say, 445 then "if (x == TRUE)" is false and "if
(if x == FALSE)" is also false.

Basically, I really do wish this didn't happen. At least have a default of
0/FALSE for an error ... TRUE is the worst thing to return on a BOOL value.
So please ... no error codes on aw_int and aw_bool calls. Not sure what
aw_float/aw_string/aw_data return, but same goes for them too. Default
values please.

Grims

Oct 16, 2002, 11:58pm

No offense, but you code wrong :)

A comparison with a boolean value is always a design bug that
shows that you do not really understand the meaning of "BOOL".

Instead of writing

if (x == TRUE)
write
if (x)


and replace

if (x == FALSE)
with
if (! x)

this is the correct way to test the value of a BOOLEAN and will
solve your value problem.


[View Quote]

Oct 17, 2002, 12:55am

I understand your point, and appreciate that what you quote is the method of
handling a boolean value based on an integer. However, the inherent meaning
of a boolean value is true or false, no matter how its implemented in a
language. 445 is not boolean value as it cannot be discerned from 1
(TRUE), -1, 444, or any other non-zero value. Mapping this value to a
language that does have a typed boolean is therefore impossible

Any non-zero value returning a true is an idiosyncrasy of C and as far as I
am concerned, the AW SDK makes the abstraction between an integer and a
boolean value by providing the aw_int and aw_bool methods. As such only a
value of TRUE or FALSE should be returned by aw_bool (otherwise its an int).

The point stands that if x=445 then its value is NOT a boolean TRUE and in
fact cannot be mapped against either of the two values that it theoretically
supports. Sadly, it doesn't solve my problem because when an aw_bool result
equates to a TRUE because its actually returning a reason code its wrong.

Grims.

[View Quote]

Oct 17, 2002, 1:50am

> As such only a value of TRUE or FALSE should be returned by aw_bool

What you want as a return value, this "boolean TRUE", is
something that does not exist at all. If you find such a TRUE
definition in your compiler, like in windef.h "#define TRUE 1",
you can blame microsoft for this wrong setting. It is not part
of the C language. Correct would have been "#define WIN_TRUE 1"
to indicate what they use as a TRUE value.


The mapping of a boolean to an integer is done by all languages
that do not have symbolic class constants, and even those map
them to integers (internally), there is no CPU value "true" /
"false" except you would use a string for that (performance loss).
OK, PHP does that, but it is an interpreter anyway - and it accepts
0 as false and any other value as true as well.


The way to see a 0 as false representation is absolutely logical,
if there's nothing something is false. And - opposite case - if
there is anything, then at least something isn't false, so it must
be true (the only option).

That's why correct definition of the constants true and false in C
can never be "true 1" and "false 0" but has to be "false 0" and
"true (!false)", this would at least respect compiler- and CPU
specifica (portability).

The K&R guide to C describes this concept and the redundancy of
using comparison operators on boolean values. As the AW SDK is
written in C, it's only logical that it follows this rule.

Any definition of TRUE (as a primitive) beeing a specific value
can only be wrong, as it depends on the CPU how it handles it.
One bit set or all bits set - jnz, bne or whatever asm token you
use will accept one or all bits set as TRUE jump condition.


And as booleans are integers in C, what should they return if
not a non-zero integer value? What is TRUE? Is it 1, 255, 65535
or 4294967295 ? It just does not matter as long as it is not FALSE.
Booleans are 2-state variables.
Our programs run on digital processors and program developers have
to live with their limitations, not to know anything but numbers.


From the C compilers view, comparing a boolean (= integer) variable
with an "equals" operator requires a test for the accurate value,
whereas a test for zero or not zero requires just testing a register
flag that has already been set when the value has been loaded
(for most common CPUs, starting with 8080/6502/6800), so using the
test instead of the comparison method even increases performance,
saves some CPU cycles.


Something that helps making the source code readable is giving
boolean variables names that explain what they stand for, e.g.:

HasError = foo();
if (HasError)
...

or

IsNegative = (x < 0);
if (IsNegative)
...


and soon using a comparison operator isn't required anymore.

Even if you use those variables only to transport the value one
step, it will not create overhead (runtime/space) in your program,
as all modern compilers will recognize this and optimize the binary.


:1,$s/[typos]/[corrections]/s




[View Quote]

Oct 17, 2002, 4:40am

This is silly and totally irrelevant to the point.

Of course boolean values exist, regardless of their implementation in a
given language. A boolean is a valid mathmatical term which, by definition,
can only have two possible values - representing true/false, on/off, yes/no,
whatever. Just because C and its derivatives fail to implement a boolean
data type securely either by syntax or convention, you can't say a "boolean
TRUE" doesn't exist. Other languages manage to enforce such a data type and
how they implemented it is as irrelevant as how C fails to, except for the
fact that these languages stipulate an explicit TRUE value and an explicit
FALSE as the only valid values for a boolean within the language definition.
I don't understand the need to be so bloody-minded about it, so I'll simply
restate my point.

When retrieving a boolean value with aw_bool from the SDK, a reason code of
445 (for example) being returned is non-zero and so, as you say, represents
a value "true" in C ... which is wrong because the attribute's value is NOT
true. The same goes for aw_int ... if it returns a 445 reason code, that
attribute's value is NOT 445. If you can't retrieve a value, its value is
nothing (i.e. zero, FALSE, null string, etc.). A reason code for such
methods is totally useless since, with the interface to the SDK as it
stands, there can be no way to identify what the value represents and so the
assumption has to be that it is the value of the attribute, as requested.

As for aw_bool/aw_bool_set, the AW SDK makes a distinction between numeric
values and boolean values when setting/retrieving attributes. If a value is
boolean, then it can only have two values ... the equivalents of TRUE and
FALSE ... and so "bool" attributes must be restricted to these two valid
values, ensuring that they are all that can be accepted or returned. These
values can be 7494 and 984 or "willy" and "wonker" for all I care ... as
long as its documented and complied to. Its not rocket science and doesn't
need to be turned into rocket science. The attributes are documented as
boolean ... but they're not, they're integers.

Even regardless of this, no-one can condone a method call, who's sole
purpose is to return a value from a store, returning a completely different
value without at least indicating what the substitute value means or even
that its not the value you requested.

Grims.

Oct 17, 2002, 9:19am

Just a funny idea : could it be that we do not talk about
the same thing? I talked about the C DLLs and you seem to
talk about the VB library. C has no attributes that could
be true or false. If I defend the DLL implementation and
you referred to the VC implementation it's quite clear that
we will not find the common point.


If so - and if VB has an abstract boolean type, you're right
of course, the mapping in the VB library should respect that.
Doesn't affect the DLL though.


If not - which numerical(!) true representation do you expect
the DLL function aw_bool() to return? The value of 1, as stated
in the SDK docs, is definitely wrong for 2 reasons. First, as
you say, it isn't fact that it returns 1 for true, and second
"true" is "not false" (in C) but no defined discrete value.

Oct 17, 2002, 12:03pm

Its not VB, but language doesn't matter. If a reason code of 445 is returned
from an aw_bool(), then the data is garbage! Its not "false", its not
"not-false", its garbage and there is no way of telling this. Also, if a
reason code of 445 is returned from an aw_int(), then the data is garbage,
but if it returns a value of 445 (i.e. the contents if the numeric
attribute) then its valid. There is no way to discern the two, so I would
like to see this fixed ... defaults that make sense and no more
unidentifiable garbage (reason codes) being returned in from the SDK in
these methods.

By way of an example, one last time ... for demonstration purposes only ...
so don't comment on the code ... or the use of the SDK ... its tiresome ...
bool value set to false, returned as true (or not-false, whatever) because
of the error code - unacceptable.

aw_init(AW_BUILD);
aw_bool_set(AW_ENTER_GLOBAL, FALSE);

// Returns 445 - No Instance ... (Garbage).
int nGlobal = aw_bool(AW_ENTER_GLOBAL);

if (nGlobal)
{
//Enters here.
// Treat as Global Mode
}
else
{
// Treat as non-Global Mode
}

It was only a simple request ... on a whishlist ... dealing with a bulls**t
loophole in the SDK, *sigh*. I'm not going to try to find another way to
put it. Restating the original point ... reason codes don't belong as
return values for methods that don't explicitly return reason codes. On an
internal failure, methods like aw_bool, aw_string, aw_int, etc. should
return their equivalent of "no value"... zero, null string, whatever.



[View Quote]

Oct 17, 2002, 2:12pm

Well, of course 445 isn't FALSE, it is a TRUE value, so you're
right about the bug in the AW SDK. The original post was about
445 not beeing a valid "boolean" value - or at least I understood
it like that - that's why I jumped in.


[View Quote]

Oct 17, 2002, 4:44pm

What I really don't understand is why AW have a "bool" attribute type if its
not enforced and basically means nothing different to the "int" type.

[View Quote]

1  |   Order by index