Roose said:
I'm aware of the pitfalls of assuming pointers are integers. However, I'd
say that when porting non-ANSI code from a platform to where they are
"equivalent" to one where they are not, that you'd simply do well to know
your hardware, and thus this fact would stick out like a sore thumb.
Point of writing conforming code is that you *don't* have "well to know
your hardware". Sane people prefer freedom from such details given to
them by standartized abstraction. That is not to say that they don't know
those details. Sane people prefer not to have sore thumbs sticked in
their eyes.
I'm not too familiar with wheel bits,
Thanks to God Almighty. Otherwise there would be another endless
"discussion" why it's good to use them, so later on "this fact would stick
out like a sore thumb", but that would be OK, because "then you will
incur the cost, and not a particularly great one". BTW, I've got no idea
what they (wheel bits) are, but AFAIK they are not mentioned in the
standard, and I'm not going to pretend that I'm "not *too* familiar" with
them, just in case

it's made-up term.
but I would suggest that this bug
could quickly found out by any rudimentary testing. Like the manager doing
a dry run before presenting to customers. It depends on the specifics of
course, but I think it is a stretch to think that such errors are likely to
produce rare bugs that could have only been avoided if the code were ANSI C
in the first place.
It's not a stretch This kind of bugs (as described above and creation of
whose you are advocating /*assume equivalence of pointer and integer*/)
*would* have been avoided by adherence to the standard. *That's* why
it is good thing to write ANSI C code (among other things).
As I said, I would prefer to incur the cost of portability when the feature
is needed.
No one is preventing you from doing it. However, you shouldn't try that
hard to convince newbies that the opposite "simply isn't necessary
engineering practice" and to change focus of this NG.
Not when writing the program for the first device. When porting
And I thought you are writing (C-like) programs *for* customers,
to make money for your company ("Thus, in the business world, it is
not considered good practice, since time = money", "ones that actually
generate money", "Do we have standard C code now that we ported it?
No.Do we need to? Not really, the products sold more than 1.5 million
copies and generated millions of dollars in profits").
to the second device, you will have specific hardware differences to
examine. And then you will incur the cost, and not a particularly great one
in my experience.
Would you incur such cost out of your pocket? Why not to avoid
associated cost (when possible)? Just because *company* will pay for
it? Ultimately, it's customers who are paying it.