Perpetual motion controller

Per,

Excellent catch:

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

It was just an example, and the code review guys might have caught me on that one. The use of the '!=' versus the '==' operator is something I practice and/or is a habit. At least one in which I would like to impart to others.

My defines for TRUE and FALSE are not the simple 0 and 1, or 0 and !0. if it is #defined, it usually contains 'many bits' (like your example of 0x5A/0xA5... or like 0xAAC3/0x553A, but it will also depend upon the processor architecture, instruction-set, etc. It is in a separate 'logic.h' or 'logic.inc' file.

And sometimes it is also #define TRUE (!FALSE) where FALSE = 0. Which I find 'lame.' Most of the time FALSE should be zero though, while TRUE is not simply a simple 1 or all 1 value:

0x0000 - 1 = 0xFFFF
0xFFFF + 1 = 0x0000

So you're only one bit away from a state change. (I'm sure there are many articles about this somewhere in the www).

It is a better construct to use a typedef/enum for flags (Boolean states) like TRUE & FALSE (where it is also assigned a value in the enum, and then actually declare the data-store as that type for your code.

// you pick your favorite name and/or 0 versus !0 thing
typedef enum {FALSE = 0x00, TRUE = !FALSE } boolean_typedef_name;

// not 1 bit away from state change on a 16-bit system
typedef enum {FALSE = 0x0000, TRUE = 0xC3A5 } Flag_Type;

// an 8-bitter: 8051
typedef enum {FALSE = 0x00, TRUE = 0xCA } Flag_Type;

Flag_Type Add_New_Code_Monkey( u8 *name )
{
    Flag_Type hired;

    hired = Check_Name( name, "Per" )

    return( hired );
}

But my point is, that Per is keenly aware of the potential to 'prefer' one state versus the other. Unfortunately, most 'bosses' are unaware of the difference between catching that and the code-monkey who can't. Thus during your performance review, you'll get chided over how many Post-It notes are on your monitor while Curious George in the cube next to you gets the kudos for 'neatness.' [If you're working at a place where the boss is that clueless, leave as soon as you can].

As far as my Biafra Airlines (Biafra == a country that existed from May of 1967 to January of 1970) comment, and the whole thing about flying is that although 'we' know how things can go wrong on very complex systems, when I fly, I don't get freaked out over it.

My wife on the other hand is very nervous when flying. Yet I have more of a reason that her to be nervous as I know more about the plane than she does. (While in flight, various noises that 'freak' passengers out, but they don't bother me at all since I have a clue on what that 'noise' means... and my wife knows that I know: she hates it when I used to say "Oh my! What was that noise?" just to get a rise out of her---I stopped doing that a long time ago).

And yes, the thread name is so very apt for the topic of the pursuit of Safety Related Issues of the non-Nobel Prize winning type.

(Funny how 'Nobel Prize' came up, as a coworker here knows, personally, several people who have received them. But, I'm starting keep my eye on *that* person though; 'cuz I'm just not sure about this one's 'stability' yet: a "Change" type personality).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Per,

Excellent catch:

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

It was just an example, and the code review guys might have caught me on that one. The use of the '!=' versus the '==' operator is something I practice and/or is a habit. At least one in which I would like to impart to others.

My defines for TRUE and FALSE are not the simple 0 and 1, or 0 and !0. if it is #defined, it usually contains 'many bits' (like your example of 0x5A/0xA5... or like 0xAAC3/0x553A, but it will also depend upon the processor architecture, instruction-set, etc. It is in a separate 'logic.h' or 'logic.inc' file.

And sometimes it is also #define TRUE (!FALSE) where FALSE = 0. Which I find 'lame.' Most of the time FALSE should be zero though, while TRUE is not simply a simple 1 or all 1 value:

0x0000 - 1 = 0xFFFF
0xFFFF + 1 = 0x0000

So you're only one bit away from a state change. (I'm sure there are many articles about this somewhere in the www).

It is a better construct to use a typedef/enum for flags (Boolean states) like TRUE & FALSE (where it is also assigned a value in the enum, and then actually declare the data-store as that type for your code.

// you pick your favorite name and/or 0 versus !0 thing
typedef enum {FALSE = 0x00, TRUE = !FALSE } boolean_typedef_name;

// not 1 bit away from state change on a 16-bit system
typedef enum {FALSE = 0x0000, TRUE = 0xC3A5 } Flag_Type;

// an 8-bitter: 8051
typedef enum {FALSE = 0x00, TRUE = 0xCA } Flag_Type;

Flag_Type Add_New_Code_Monkey( u8 *name )
{
    Flag_Type hired;

    hired = Check_Name( name, "Per" )

    return( hired );
}

But my point is, that Per is keenly aware of the potential to 'prefer' one state versus the other. Unfortunately, most 'bosses' are unaware of the difference between catching that and the code-monkey who can't. Thus during your performance review, you'll get chided over how many Post-It notes are on your monitor while Curious George in the cube next to you gets the kudos for 'neatness.' [If you're working at a place where the boss is that clueless, leave as soon as you can].

As far as my Biafra Airlines (Biafra == a country that existed from May of 1967 to January of 1970) comment, and the whole thing about flying is that although 'we' know how things can go wrong on very complex systems, when I fly, I don't get freaked out over it.

My wife on the other hand is very nervous when flying. Yet I have more of a reason that her to be nervous as I know more about the plane than she does. (While in flight, various noises that 'freak' passengers out, but they don't bother me at all since I have a clue on what that 'noise' means... and my wife knows that I know: she hates it when I used to say "Oh my! What was that noise?" just to get a rise out of her---I stopped doing that a long time ago).

And yes, the thread name is so very apt for the topic of the pursuit of Safety Related Issues of the non-Nobel Prize winning type.

(Funny how 'Nobel Prize' came up, as a coworker here knows, personally, several people who have received them. But, I'm starting keep my eye on *that* person though; 'cuz I'm just not sure about this one's 'stability' yet: a "Change" type personality).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I used to think that I was a fairly competent programmer.

However ... after noticing some of the responses on this thread I'm starting to wonder if I've got sufficient experience to even attempt to read them. I won't even pretend to say I can understand what it's all about!