iansjack wrote:
That's not really the best solution. Ideally you would use types that specify their size and make no assumptions about the compiler.
Compare your code with that you copied.
Compare your code with that you copied.
I was thinking the exact same thing.
It is one thing getting your code to work, but it is another thing to have it well-written - by "well-written" code, I'm referring to code which will be stable (but you can add in other factors as well, such as documentation, manageability and the neatness of the source code). Sometimes it can mean re-doing all the previous work on the specific module from scratch (or worse - occasionally the entire project), but believe me, it really pays off in the end. Code which wasn't well-written can easily bite you in the bottom and ruin your day, week, month, or longer.
I can think of another really good reason as to why it is important to consider ensuring the code is as well-written as can be, instead of simply caring about whether it working or not.. That reason would be... *drum roll please*... Vulnerabilities! The better the design of the feature implementation, as well as the actual code to implement that designed feature, you may potentially end up with functionality which will be harder to exploit (and thus the feature would be potentially more secure). Security is generally a critical factor when it comes to designing and developing a feature for implementation, and without that security factor, it simply is not a good design/design implementation (in my personal opinion).
'Assumption is the mother of all failures' (as Slade Wilson from the DC Arrow series would say). Verify over assuming and your days are likely to become more enjoyable!
[EDIT: Apologies for bumping an old thread, but I thought introducing the security factor would be a good idea].