> This is the code that gives us the classic buffer overflow vulnerability all because checking for a length isn't elegant.
The few characters it would take to check length didn't effect this API, it was just part of the decision to use null terminated strings instead of storing lengths.
>Also, how does this code work if what one of those pointers points to are declared volatile? What if both pointers point to volatile things?
I can't imagine any way in which volatile would cause problems. What are you pondering? strcpy doesn't take volatile pointers anyway.
> What happens if one of those pointers crosses through 0 because it rolled over from max?
That's just a very specific type of buffer overflow. strcpy is the wrong function to use in such a scenario.
> Thanks. I doubt you could have provided a better example of the precise problem.
strcpy is for very specific situations. Writing it in a simple way isn't the problem. It's not like it's even theoretically possible for strpy to avoid overflowing. It doesn't have enough information, only two pointers.
In short, this is a bad API, it is not a bad implementation.
So your conclusion is that the original code is more logical with regard to volatile pointers, even though calling it with one would mean casting away the volatile and basically inviting disaster?
No coding style is immune to problems caused by changing the number of reads to a variable. Volatile is an exceptional thing that must be treated with care and heavy documentation. It has no relevance to the quality of a normal-code strcpy.
The few characters it would take to check length didn't effect this API, it was just part of the decision to use null terminated strings instead of storing lengths.
>Also, how does this code work if what one of those pointers points to are declared volatile? What if both pointers point to volatile things?
I can't imagine any way in which volatile would cause problems. What are you pondering? strcpy doesn't take volatile pointers anyway.
> What happens if one of those pointers crosses through 0 because it rolled over from max?
That's just a very specific type of buffer overflow. strcpy is the wrong function to use in such a scenario.
> Thanks. I doubt you could have provided a better example of the precise problem.
strcpy is for very specific situations. Writing it in a simple way isn't the problem. It's not like it's even theoretically possible for strpy to avoid overflowing. It doesn't have enough information, only two pointers.
In short, this is a bad API, it is not a bad implementation.