Thread: Union vs. Mask

>Which way would be "better"?
If it works, don't break it?

That's funny:

Originally Posted by My Boss

Well it [the code] has worked for 20 years, so it must not be too bad

Originally Posted by me

Then why did we change it?

Originally Posted by My Boss

Hmmph.

Seriously, though. . . you'd have to see the code to understand why I want to change it. The original programmer didn't 1) follow any convention -- there was no standard. 2) document 3) use descriptive names 4) not use hard coded values after assigning the same values to variables. . .

I could continue, but I think you get the point.

EDIT: For example:

Originally Posted by header file

Code:

typedef struct GPD {    /* GPDBITS - output record for gas plasma display */
  unsigned home : 1,    /* Output port 0 - GPD control */
       cursoron : 1,    /* Prolog 7601A TTL I/O card */
          clear : 1,
          write : 1,
          spare : 4,
           data : 8;    /* Output port 1 - GPD data */
} GPDBITS;

Originally Posted by program file

Code:

void clearhome(void)
{
  int k;
  int gpdstat;

  do {                            /* Wait until gpd not busy */
    gpdstat = inp(GPDSTAT);
  } while (gpdstat & 0x0008);
  (void)outp(GPDCNTRL, 0xff);
  (void)outp(GPDCNTRL, 0xfb);
  for (k=0; k <25000; ++k)        /* Changed k from 2500  18 Jan 03  PSC */
    continue; 
  (void)outp(GPDCNTRL, 0xff);
}

I understand how you feel. However, legacy code is a tricky business because it's often written like a high school book report and has been running critical systems for multiple decades. More often than not, an innocent change will hose everything and you'll spend days trying to figure out why. Repeat ad infinitum and that's what updating legacy code is like. I can't in good conscience advise you to muck about in working code just to make it look prettier, but since you're going to do it anyway (and I probably would too), make no assumptions, okay?

Best to leave the bitfields for now though. Clean up the code and see if it works for you, then consider gutting the bit stuff.

an innocent change will hose everything and you'll spend days trying to figure out why

Even worse when the small change seems to be OK... Till it goes to the customer... And only then something stops working... that seems to be in no connection with changes done...

Does it have any bug reports against it?
What is the number of bugs per 1000 lines of code?
If it's >1 bug / 1000 lines, then perhaps you're in rewrite territory.

How many features are you expecting (or would like) to add?
If it's more than 20% of the existing feature count, then perhaps you're in rewrite territory.

As you've already experienced, even minor changes cause unforseen side effects. The worst of it is, this situation can only get worse as time goes on, as people who follow you have to guess at the things you were thinking of at the time. It will eventually reach the point where no further editing becomes possible as each bug removed adds one more bug somewhere else.

> and porting it from DOS to Linux
Expect lots of benign memory abuse on DOS (totally devoid of any memory protection) to bite you really hard when you move to Linux.

>This system will be end of life in 10 years. I will be the last person to code for this system.
Yea, we've all heard that one before.

> This is a G'ment system, so it cannot have changes without major in-depth testing.
You said you were rewriting the code, or did you just mean "rewriting" ?

Hell, if it's that close to end of life, why are you even bothering with a Linux port?
The only plausable reason is to extend it's life.

I think that's enough free consultancy...