|
Jim McCarthy wrote: <><snip/><snip/> 1) Treat pointers as pointers and ints as ints let the compiler sort it out -- to the extent possible. 2) Make sure you have proper function prototypes for all functions. You get into problems when: * The same field in a data structure is used for ints and pointers at different times. * ints and pointers are passed on the stack and no (or incorect) function prototypes are used. * doing home-rolled variable argument lists instead of the va_arg stuff * having pointer values that pass thru ints because "they are the same thing". * doing bit-level manipulation of pointers. A great many evils are avoided by following the two rules stated above. Unfortunatly, some older programs from the days of restricted memory and K&R compilers break these rules and do all the bad things. Some newer ones do too. Rule 1 includes using NULL for null pointer values and not 0. It also includes using %p to format pointer values. There are probably some other things I should add. If you like, rule 2 can be thought of as a special, but easy to overlook, case of rule 1. It is arguably not necessary as long as the types of the arguments in all calls are exactly what the prototype calls for. Rule 2 makes it possible for the compiler to help you keep your arguments straight. Keep your nose clean and you won't have problems with new code you write. Its the old stuff that will give you fits. I survived the transition from it being 16 bits to int being 32 bits. That included a lengthy period when both were common. Sort of like today. |