Agreed up to here. Freeing a buffer that is not NULL terminated is fine, you're right. The first example is 'just a bug'. The second one is a security risk and a bug. > I don't think this is a shabby way to copy a string. An > hipotetical char = 16 bits, not even your malloc is misused, > like your for is incoherent. Yes, the correct loop would be i > < SIZE. Ops can be reduced if your compiler could optmize it. > If you force an arch based optmization (like the one you > proposed), it is totally arch dependent. > It's not as arch specific as you think. Provided you are using 8 bit character strings, which is sort of implied as I read it, then it is pretty bad. Take a look at the implementation of strcpy in a good CRT, it should be much smarter than this loop. Yes good compilers can optimize this, but you can express that optimization in vanilla C, which prevents the compiler from having to; premature optimization may be the root of all evil, but immature optimization follows closely on it's heels. The for loop string copy is a good example of trying to be smarter than you really are; calling strncpy is often faster. Copying a string 32bits at a time rather than 8 is just better. Yes if we switch to wide-char strings on Windows, for example, it will break, but so will code that uses strncpy. But we digress into nit-picking and the sort of subjective coding debate that never ends... Cheers, ~ol
This archive was generated by hypermail 2b30 : Tue May 13 2003 - 15:21:04 PDT