OSDev.org

Ugh...typed out a reply but I forgot to put in a name and it wasn't there when I hit the back button. Basic summary:

* I agree that any strcpy is going to be insecure, including the loop-counted one above. Didn't mean to give the impression that I thought otherwise.

* I'm not offended by any of this, so don't worry

* Although Pascal was my first language and that probably colors my style, I am much better versed in C++ than Pascal now, and I've seen enough of that kind of code that I can read it pretty easily, but it seems to require more thought to make sure it's doing what it appears to do. I also don't like (though I can't give strong justification other than a preference for simple statements):

Solar wrote:I really mean no offense. I myself don't have that much on-hand experience with C. But those redundant loop counters scream all kind of warnings at me not to trust a single line of the code because quite obviously the author is not used to writing C.

I was gonna let you guys duke it out, but I just *had* to comment on this one . Speaking from experience here, if you're writing production code that needs to be of the highest quality, and going to be maintained by others, you should definitely lean more towards this "pascal" style, as you call it. Assuming performance isn't an issue (and you'll just be guessing unless you profile it), readability and code clarity is most important.

Sure, for small functions that need to be performant, like strcpy, it's a different story.

Solar wrote:[*] come up with a strcpy() that is not prone to overflows (how do you determine the available size in [tt]dest[/tt]?);

Well, you just have to pass the size of the destination buffer into the function.

That's a strncpy...I think he meant a regular old "copy everything" strcpy.

strncpy is a little different than what I'm talking about.
strncpy says "copy n bytes from src, into dest".

What I'm talking about is, copy as much as src as possible into dest, but indicate dest is only n chars long, so don't copy more than that.
An example from the windows sdk would be StringCchCopy.
e.g.
MSDN reference to StringCchCopy

Of course, it is impossible to avoid overflows if you have to copy all of src into a fixed length buffer. Your only choice then is to allocate a buffer as long as the src, and copy into that.

[edit by candy]replaced long URL with descriptive text, better for people with <20" monitors.[/edit]

@ troflip:

Even your "strncpy() with size of dest given" is prone to error. What if the size of dest you passed to the function isn't the right one? You will probably say "just make sure it is", but then strncpy() should already suffice if you are careful.

troflip wrote: Speaking from experience here, if you're writing production code that needs to be of the highest quality, and going to be maintained by others, you should definitely lean more towards this "pascal" style, as you call it. Assuming performance isn't an issue (and you'll just be guessing unless you profile it), readability and code clarity is most important.

That is the very point I am trying to make, isn't it? I consider the C style to be more readable than the Pascal style because it is the style such things are being done in C. It is what I would expect, and I believe it is what most experienced C coders would expect.

But I think we're at the point now where we agree to disagree.

I think you all have good points here.

I personally consider Solar's method something for those who are more used to c-like programming stuff - and who have quite some experience under their belts so they know what that is when they look at it.

For trainees or less experienced c programmers, a more explicit version with loop counters and array indices is asked for, so they can learn what the code is doing by studying it in all its steps - despite the oe or other perf. tradeoff.

Learing is mostly done with explicit patterns one can play with. elegance comes later.

troflip wrote: strncpy is a little different than what I'm talking about.
strncpy says "copy n bytes from src, into dest".

Strncpy says: "Copy src to dest, but not more than n bytes."

What I'm talking about is, copy as much as src as possible into dest, but indicate dest is only n chars long, so don't copy more than that.
An example from the windows sdk would be StringCchCopy.
e.g.
MSDN reference to StringCchCopy

Which is then the exact same. strncpy doesn't copy beyond the null terminator, doesn't overrun the target buffer but always null-terminates the dest string. The Microsoft-function StringCchCopy copies the string up to the null terminator, doesn't overrun the target buffer and null-terminates the final string. The three differences are that the Microsoft one isn't supported outside of windows, the argument order is different and the language design is slightly different (IE, the C standard things use standard C types, while the Microsoft one uses types I've never heard of).

Of course, it is impossible to avoid overflows if you have to copy all of src into a fixed length buffer. Your only choice then is to allocate a buffer as long as the src, and copy into that.

Which would equate what all modern languages can do with a clone-like facility. That includes C++, C#, java and a bunch of others. With a minuscule bit of trouble you can do the same in C.

Pop quiz: what happens when you don't have the memory to copy it?

Candy wrote: Pop quiz: what happens when you don't have the memory to copy it?

A library function fails, which Should Not Happen (tm), especially since C doesn't have something like exceptions and signal handling isn't trivial.

Pop quiz: On a Unix system, does a non-null return value of malloc() mean you do have the memory required? (And if no, why not?)

erm ... something with virtual/physical memory and some cruel paging tricks? *chuckle*

I'd at least have those systems return No_deal if there ain't enuff physical memory to satisfy futher map-ins due to access of the allocated memory on the heap.

but that's just me, your average mileage might hopefully vary

(FYI, UNIX malloc() indeed doesn't map in a new page physically until first access. That means there might have been swap space left when you requested the memory, but not anymore when you first used it. Means, your malloc() returns a non-NULL value and still your app might SEGFAULT or whatever when accessing the memory. Most UNIX derivates behave very badly under low-mem conditions.)

Candy wrote:Which is then the exact same. strncpy doesn't copy beyond the null terminator, doesn't overrun the target buffer but always null-terminates the dest string.

They may seem exactly the same, but there is a subtle difference in behaviour: strncpy does not always null-terminate the string. As long as you take the extra step to do that, then yes, they are the same, and you can treat the count parameter of strncpy as being the destination buffer size.
(anyway, that's why I was making the distinction between "size of dest buffer" and "number of characters to copy" - while it may just seem like semantics, there is actually a real difference in behaviour)