RWBoolean : unexpected result

RWBoolean : unexpected result

Post by Alex Vinoku » Wed, 15 Sep 1999 04:00:00



Hi,

I think, there is a problem
  while using the RWBoolean type in RogueWave.

Let val1 and val2 be the RWBoolean variables.
Result of (val1 & val2) is sometimes unexpected.

Using this result seems to be dangerous.

        Alex.

//#########################################################
//------------------- C++ code : BEGIN -------------------
#include <iostream.h>
#include <rw/rwstring.h>

//====================================================
int main ()
{
RWBoolean val1 = 1;             // TRUE
RWBoolean val2 = 2;             // TRUE
RWBoolean val3 = (val1 & val2); // it must be TRUE, but it is FALSE

        cout << "val1 = " << val1 << endl;
        cout << "val2 = " << val2 << endl;
        cout << "val3 = " << val3 << endl;

        return 0;

Quote:}

//------------------- C++ code : END ----------------------

//#########################################################
//------------------- Running Results : BEGIN -------------

val1 = 1
val2 = 2        // maybe 1 or true (?!)
val3 = 0        // must be 1 or true

//------------------- Running Results : END ---------------

//#########################################################
//------------------- Compiler & System  ------------------

SUN CC     : CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2

Tools.h++  : 7.0

uname -sr  : SunOS 5.6

//---------------------------------------------------------

//#########################################################

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

RWBoolean : unexpected result

Post by Alex Vinoku » Wed, 15 Sep 1999 04:00:00




Quote:

> Hi,

> I think, there is a problem
>   while using the RWBoolean type in RogueWave.

> Let val1 and val2 be the RWBoolean variables.
> Result of (val1 & val2) is sometimes unexpected.

> Using this result seems to be dangerous.

>         Alex.

> //#########################################################
> //------------------- C++ code : BEGIN -------------------
> #include <iostream.h>
> #include <rw/rwstring.h>

> //====================================================
> int main ()
> {
> RWBoolean val1 = 1;             // TRUE
> RWBoolean val2 = 2;             // TRUE
> RWBoolean val3 = (val1 & val2); // it must be TRUE, but it is FALSE

  Using RWBoolean val4 = (val && val2)
  we have got a valid result (TRUE).

  If the 1 (as TRUE) value was always used,
  we would have the valid result for (val1 & val2) as well.

- Show quoted text -

Quote:

>         cout << "val1 = " << val1 << endl;
>         cout << "val2 = " << val2 << endl;
>         cout << "val3 = " << val3 << endl;

>         return 0;
> }

> //------------------- C++ code : END ----------------------

> //#########################################################
> //------------------- Running Results : BEGIN -------------

> val1 = 1
> val2 = 2        // maybe 1 or true (?!)
> val3 = 0        // must be 1 or true

> //------------------- Running Results : END ---------------

> //#########################################################
> //------------------- Compiler & System  ------------------

> SUN CC     : CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2

> Tools.h++  : 7.0

> uname -sr  : SunOS 5.6

> //---------------------------------------------------------

> //#########################################################

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

RWBoolean : unexpected result

Post by Volker Borche » Wed, 15 Sep 1999 04:00:00


|> I think, there is a problem
|>   while using the RWBoolean type in RogueWave.
|>
|> Let val1 and val2 be the RWBoolean variables.
|> Result of (val1 & val2) is sometimes unexpected.

Tried ``&&''?

--



 
 
 

RWBoolean : unexpected result

Post by Paul Blac » Wed, 15 Sep 1999 04:00:00



> Hi,

> I think, there is a problem
>   while using the RWBoolean type in RogueWave.

> Let val1 and val2 be the RWBoolean variables.
> Result of (val1 & val2) is sometimes unexpected.

Did you mean (val1 && val2)? Consider the difference between
"1 & 2" and "1 && 2".

Paul

 
 
 

RWBoolean : unexpected result

Post by Erik Max Franci » Wed, 15 Sep 1999 04:00:00



> RWBoolean val1 = 1;             // TRUE
> RWBoolean val2 = 2;             // TRUE
> RWBoolean val3 = (val1 & val2); // it must be TRUE, but it is FALSE

That's bitwise and you're using there.  1 & 2 is indeed 0.  You meant
&&.

--

 Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
    San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
             USA | Tue 1999 Sep 14 (14%/949) | &tSftDotIotE
 __
/  \ Give me chastity, but not yet.
\__/ St. Augustine

 
 
 

RWBoolean : unexpected result

Post by Alex Vinoku » Thu, 16 Sep 1999 04:00:00





> > Hi,

> > I think, there is a problem
> >   while using the RWBoolean type in RogueWave.

> > Let val1 and val2 be the RWBoolean variables.
> > Result of (val1 & val2) is sometimes unexpected.

> Did you mean (val1 && val2)? Consider the difference between
> "1 & 2" and "1 && 2".

> Paul

Using &&, we have got a valid result.

        ===> Part#1 : operator== and RWBoolean

Here is a result of comparing two RWBoolean variables.
Is this result expected (valid)?

//#########################################################
//------------------- C++ code : BEGIN -------------------

#include <iostream.h>
#include <rw/rwstring.h>

//====================================================
int main ()
{
RWBoolean val1 = 1;             // TRUE
RWBoolean val2 = 2;             // TRUE

        if (val1 == val2)
        {
                cout << "OK" << endl;
        }
        else
        {
                cout << "FAILURE" << endl;
        }

        return 0;

Quote:}

//------------------- C++ code : END ----------------------

//#########################################################
//------------------- Running Results : BEGIN -------------

FAILURE         // ???

//------------------- Running Results : END ---------------

//#########################################################
//------------------- Compiler & System  ------------------

SUN CC     : CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2
Tools.h++  : 7.0
uname -sr  : SunOS 5.6

//---------------------------------------------------------

//#########################################################

        ===> Part#2 : bool (GNU and aCC) and RWBoolean (RogueWave)

Behavior of bool type in the GNU and aCC compilers on the one hand
          and RWBoolean type in RogueWave on the other hand
          are different.
Using the operator&&, we have got the same results.
Using the operator& (bitwise), we have got the different results.

//#########################################################
//------------------- C++ code : BEGIN -------------------
#include <iostream.h>

#define COUT(t) cout << #t << " = " << t << endl
int main ()
{
bool    val1 = 1;
bool    val2 = 2;
bool    val3 = (val1 & val2);
bool    val4 = (val1 && val2);

        COUT (val1);
        COUT (val2);
        COUT (val3);
        COUT (val4);

        return 0;

Quote:}

//------------------- C++ code : END ----------------------

//#########################################################
//------------------- Running Results : BEGIN -------------

val1 = 1
val2 = 1
val3 = 1
val4 = 1

//------------------- Running Results : END ---------------

//#########################################################
//------------------- Compilers & Systems  ----------------

---------- GNU compiler -------------
g++ -v     : gcc version egcs-2.91.57
uname -sr  : SunOS 5.6

---------- aCC compiler -------------
what /bin/aCC : HP aC++ B3910B A.01.06
                HP aC++ B3910B A.01.01 Support Library
uname -sr     : HP-UX B.10.20

//---------------------------------------------------------

//#########################################################

        Alex

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

RWBoolean : unexpected result

Post by Thomas W. Brow » Thu, 16 Sep 1999 04:00:00



> > //------------------- C++ code : BEGIN -------------------
> > #include <iostream.h>
> > #include <rw/rwstring.h>

> > //====================================================
> > int main ()
> > {
> > RWBoolean val1 = 1;             // TRUE
> > RWBoolean val2 = 2;             // TRUE
> > RWBoolean val3 = (val1 & val2); // it must be TRUE, but it is FALSE

>   Using RWBoolean val4 = (val && val2)
>   we have got a valid result (TRUE).

>   If the 1 (as TRUE) value was always used,
>   we would have the valid result for (val1 & val2) as well.

Clearly, unlike the builtin 'bool' type, RogueWave's RWBoolean is
probably just a char (or, if they were feeling inefficient, an int).

Note, if you used 'bool' you would (potentially) get a compiler warning
on the assignment of the const int value '2' to the 'bool'.

-- Thomas Brown

 
 
 

RWBoolean : unexpected result

Post by Erik Max Franci » Thu, 16 Sep 1999 04:00:00



> Here is a result of comparing two RWBoolean variables.
> Is this result expected (valid)?

        ... a great deal of code and output ...

The question arises:  Why are you experimenting with what works?  Why
don't you read the library documentation and find out for sure?

--

 Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
    San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
             USA | Wed 1999 Sep 15 (16%/949) | &tSftDotIotE
 __
/  \ Man is a hating rather than a loving animal.
\__/ Rebecca West

 
 
 

RWBoolean : unexpected result

Post by Alex Vinoku » Fri, 17 Sep 1999 04:00:00





> > Here is a result of comparing two RWBoolean variables.
> > Is this result expected (valid)?
>    ... a great deal of code and output ...

> The question arises:  Why are you experimenting with what works?  Why
> don't you read the library documentation and find out for sure?

[snip]

From the the library documentation (Appendix B: Typedefs and Macros):

#define FALSE 0           // RWBoolean value (defs.h)
#define TRUE  1           // RWBoolean value (defs.h)
typedef int   RWBoolean   // (defs.h) TRUE or FALSE

That may explain why (when RWBoolean val1 = 1, RWBoolean val2 = 2)
        -----------------------
        (val1 == val2) is FALSE.
        -----------------------
But I expect (val1 = val2) to be TRUE.
These are (must be) boolean variables.

By the way, in the GNU and aCC (HP) compilers
we have got (when bool val1 = 1, bool val2 = 2)
        -----------------------
        (val1 == val2) is true
        -----------------------

        Alex

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

RWBoolean : unexpected result

Post by Karl Heinz Buchegge » Fri, 17 Sep 1999 04:00:00



> From the the library documentation (Appendix B: Typedefs and Macros):

> #define FALSE 0           // RWBoolean value (defs.h)
> #define TRUE  1           // RWBoolean value (defs.h)
> typedef int   RWBoolean   // (defs.h) TRUE or FALSE

> That may explain why (when RWBoolean val1 = 1, RWBoolean val2 = 2)
>         -----------------------
>         (val1 == val2) is FALSE.
>         -----------------------
> But I expect (val1 = val2) to be TRUE.
> These are (must be) boolean variables.

> By the way, in the GNU and aCC (HP) compilers
> we have got (when bool val1 = 1, bool val2 = 2)
>         -----------------------
>         (val1 == val2) is true
>         -----------------------

Sure. These are bool variables. The compiler knows
about them and how to handle them. Note that a bool
cannot be 0, 1 or 2 ..., It can only be true or false!

RWBoolean is an int in reality, so the compiler applies
the rules for int in handling them. And he is perfectly
correct: 1 != 2. Why would you expect something different?
Just because somebody comes up with a different name for int?
No matter how you name it, it stays an int.

-----------------------------------------------------------
Karl Heinz Buchegger

 
 
 

RWBoolean : unexpected result

Post by Thomas W. Brow » Fri, 17 Sep 1999 04:00:00



> From the the library documentation (Appendix B: Typedefs and Macros):

> #define FALSE 0           // RWBoolean value (defs.h)
> #define TRUE  1           // RWBoolean value (defs.h)
> typedef int   RWBoolean   // (defs.h) TRUE or FALSE

> That may explain why (when RWBoolean val1 = 1, RWBoolean val2 = 2)
>         -----------------------
>         (val1 == val2) is FALSE.
>         -----------------------
> But I expect (val1 = val2) to be TRUE.
> These are (must be) boolean variables.

But they are not -- they are ints and acting like it.  Obviously
RogueWave started this whole RWBoolean business before 'bool' was
adopted into the standard (just like Microsoft's BOOL typedef).  As you
point out, RWBoolean is not functionally equivalent to the language's
"bool" datatype.

I suppose you could go into RogueWave's defs.h file and change the
typedef to be:

        typedef bool    RWBoolean;
        #define FALSE   false
        #define TRUE    true

-- Thomas Brown

 
 
 

RWBoolean : unexpected result

Post by Alfred Kellne » Sat, 18 Sep 1999 04:00:00




> > From the the library documentation (Appendix B: Typedefs and Macros):

> > #define FALSE 0           // RWBoolean value (defs.h)
> > #define TRUE  1           // RWBoolean value (defs.h)
> > typedef int   RWBoolean   // (defs.h) TRUE or FALSE

> > That may explain why (when RWBoolean val1 = 1, RWBoolean val2 = 2)
> >         -----------------------
> >         (val1 == val2) is FALSE.
> >         -----------------------
> > But I expect (val1 = val2) to be TRUE.
> > These are (must be) boolean variables.

> > By the way, in the GNU and aCC (HP) compilers
> > we have got (when bool val1 = 1, bool val2 = 2)
> >         -----------------------
> >         (val1 == val2) is true
> >         -----------------------

> Sure. These are bool variables. The compiler knows
> about them and how to handle them. Note that a bool
> cannot be 0, 1 or 2 ..., It can only be true or false!

> RWBoolean is an int in reality, so the compiler applies
> the rules for int in handling them. And he is perfectly
> correct: 1 != 2. Why would you expect something different?
> Just because somebody comes up with a different name for int?
> No matter how you name it, it stays an int.

Yeah.

          False and not False
                (revisited)
What a seasoned and injured (!false) programmer thinks.

If an integer type is misused as boolean value, one has to consider
what to do with those "out of range" values (42), an integer-boolean
may hold.
You accept the C-mapping from boolean to int:
        false ==> 0
        true  ==> 1
OK. Then you encounter the reverse mapping:
         0 ==> false
         1 ==> true
        42 ==> what ?? either an error or true

If you think 42 is true (as C does), you never ever shall test
that value against other than zero (=definitely false).
So. the code aforementioned should read (in case of non-bool boolean)

                ( !val1 == !val2 ) // true even when: !1 == !42

The next (bad) habit, I see, is:
        void foo( int flag )
        {       if ( flag == TRUE ) // is one
                //      ....
What's wrong with:
                if ( flag ) // is not zero

I remember a nice function (or macro), let's call it isprint(c)
returning 0x04. isprint() _not_ defined as returning true,
it is defined as returning "a nonzero value". Against which value,
do you think, do you have to compare the result to get the correct
answer ?
        assert(!!flag==flag);
have fun
--ALfred

 
 
 

RWBoolean : unexpected result

Post by William Boyl » Sun, 10 Oct 1999 04:00:00




> > Hi,

> > I think, there is a problem
> >   while using the RWBoolean type in RogueWave.

> > Let val1 and val2 be the RWBoolean variables.
> > Result of (val1 & val2) is sometimes unexpected.

> Did you mean (val1 && val2)? Consider the difference between
> "1 & 2" and "1 && 2".

> Paul

You are trying a bit-wise operation on boolean values, which is not
allowed. How a boolean is represented is up to the implementor, but the
only thing you can be assured of is that they evaluate to 0 or not 0.
IE: (val1 && val2) is a legal condition, but (val1 & val2) is not a
condition, it is a bit-wise operation. Also, the Rogue-Wave RWBoolean
value is typically a typedef'd integer value. If you have not properly
initialized them, then they can contain any legal integer value. Any
non-0 integer will evaluate to a boolean TRUE, no matter whether it is
positive or negative. So, in this case, you can perform a bit-wise
comparison on them (RWBoolean values), but the results on unitialized
values will not be determinable. (val1 & val2) MAY evaluate to either
FALSE (0) or !FALSE (!0), but they may never evaluate to TRUE (1). In
the final analysis, the following holds true:

void func()
{
  RWBoolean val1, val2; // Uninitialized - can be any integer value.
  if (val1 & val2) // bit-wise AND operator - result is an integer
        cout << "Both of these are non-0 and have at least 1 bit the same" <<
endl;
  if (val1 | val2) // bit-wise inclusive OR operator - result is an
integer
        cout << "Either of these is non-0" << endl;
  if ((val1 & val2) == FALSE) // bit-wise AND operation compared to an
integer 0.
        cout << "Both of these are 0" << endl;
  if ((val1 & val2) == TRUE) // bit-wise OR operation compared to an
integer 1.
        cout << "Either both are 1 or one is 0 and the other is 1" << endl;
  if (val1 && val2) // Logical (boolean) AND operator - result is a
boolean
        cout << "Both of these are non-0" << endl;
  if (val1 || val2) // Logical (boolean) OR operator - result is a
boolean
        cout << "At least one of these is non-0" << endl;

Quote:}

Anyway, the point is, don't just experiment until you get results that
seem to work. You need to understand WHY they work that way, otherwise
you are just shooting arrows into the air and hoping a duck gets in the
way...

-Bill Boyle

 
 
 

RWBoolean : unexpected result

Post by Paul Blac » Mon, 11 Oct 1999 04:00:00



>   if ((val1 & val2) == FALSE) // bit-wise AND operation compared to an
> integer 0.
>         cout << "Both of these are 0" << endl;

Wrong.

Quote:> Anyway, the point is, don't just experiment until you get results that
> seem to work. You need to understand WHY they work that way, otherwise
> you are just shooting arrows into the air and hoping a duck gets in the
> way...

Please don't:
a) email me news postings
b) teach me how to suck eggs.

Paul

 
 
 

1. unexpected fork()/ppid() results!

Hello!

I am trying to understand (maybe develope something later) how processes
-manipulation works. So I wrote this small progam yesterday which
immediately results in things I can't explain.

---- the program ----
#include <unistd.h>

void main(void)
{
  pid_t         pid;

  printf("%04d : uid=%d, gid=%d, euid=%d,
egid=%d\n",getpid(),getuid(),getgid(),geteuid(),getegid());

  pid = fork();
  if (pid == 0)
     printf("%04d : My Daddy is %d.\n",getpid(),getppid());
  else
     printf("%04d : Me Daddy of %d! (and son of
%d)\n",getpid(),pid,getppid());
---- end of program ----

It compiles cleanly but when I run it:

neptunus:/home/benc/sources# a.out
16499 : uid=0, gid=0, euid=0, egid=0
16499 : Me Daddy of 16500! (and son of 12893)
neptunus:/home/benc/sources# 16500 : My Daddy is 1.

Why does the child think it's ppid is 1 and not 16499 like I expected?
The 16499 seems to know it's
parent (a bash) using the same function call.

I hope someone can give me some answers. It doesn't have much sense
going on developing if I can't even explain this..

Thanks in advance,
Ben

2. fttp umask

3. csh script - unexpected results? (BSDI)

4. Syslogd failing to log to file.

5. CTRL-ALT-+ : unexpected results switching color depths

6. Solaris -> WinNT printing?

7. NFS newbie getting unexpected results [long]

8. vim/gvim - how to set lines and columns

9. Unexpected result from grep

10. CASE Statement - Weird and Unexpected Results

11. Newbie--ipchains unexpected results

12. Script run via cron yields unexpected results.

13. ipfwadm - unexpected results