On 07/18/2011 04:20 PM, Jack wrote:
....
The key thing that I don't think you fully comprehend is just how
short-sighted your non-fix was. It's not going to wait until next year
to come back and bite you - it's the kind of thing that is likely to
come back next week, or next month at the latest. Is your boss really so
short-sighted that he doesn't even care about next month?
The fact that your fix "worked", even in the very limited short-sighted
sense that you're using, implies that something that shouldn't be, is
writing to memory inside of *fp. That's why, by restoring that memory to
its original form, you got fread() to work correctly. However, computer
programs seldom write to memory unless they intend to read from it at
some later time. When the other parts of your program try to read the
values that were written in the wrong location, there's two main
possibilities:
1. They will read it from the correct location.
2. They will read it from the same wrong location that the data was
originally written to, which means that they will read the replacement
data you overwrote it with.
Either way, they will NOT be reading the values that were originally
written to the wrong location. Few programs are likely to work correctly
when the value read from a non-volatile memory location differs from
what was supposed to be written there.
If you were running into this problem during an fclose() call that
happened to be the very last thing your program does, then those issues
wouldn't matter very much. However, a call to fread() is almost always
followed, sooner or later, by more data processing, and something you
haven't even noticed yet is probably already going wrong.
[Political ranting and raving snipped].
When my boss says he wants customer faults patched up as quickly as
possible and damn the long term effects, I'm going to do exactly what he
says and hope to God it's enough to keep me on the books.
Your boss is, ultimately, responsible for such decisions. However, be
very careful how far you go in using that as an excuse for sloppy job
performance. I learned the hard way that just because your boss says
"it's more important to get this out by the deadline, than to get it
correct", doesn't mean that you won't be in trouble if it behaves
incorrectly. I was lucky - my boss at least eventually admitted,
publicly, that he might have forgotten that he gave me such
instructions, and afterwards he was much more cautious about giving me
similar instructions. I don't think you can count on your boss being so
honest about it.
At the very least, get such instructions in writing from your boss. If
he won't commit them to writing, write down what he's said yourself and
send it to him, asking for confirmation in writing. If he refuses, you
can reasonably assume that what he's afraid to leave documentary
evidence that he gave you such orders, which is generally a very bad
sign. He'll almost certainly blame the resulting problems on you when it
comes time to pay the piper. That means that you'll be the first out the
door when the next round of layoffs come.
Even if you get it in writing, that might not be enough to save your
job. Every time you take such a short-cut to save time now, someone will
pay for it in the future, even if your boss wants to deny the existence
of that future, and that someone might be you.
All you people going on with your ideal of programming to perfection -
yeah, I agree with that. But it's not possible for me where I am right
now and there's nothing I can do about that.
The idea that there's nothing you can do about this is a self-fulfilling
prophecy. I'd recommend that you start preparing immediately to search
for a new job. Even if you don't get blamed for the problems caused by
obeying your boss's instructions, if his attitudes are typical of the
management of your company, then it's likely to go out of business soon.
Since you'll need to start your job search soon, anyway, why not search
for a company with a better attitude towards product quality?
