3 ms·
I'm not disagreeing that strncpy is safer than strcpy - I've explicitly said so elsewhere. > And thinking that strncpy will enforce a null at the end actually
by dllthomas 10y ago
I'm not disagreeing that strncpy is safer than strcpy - I've explicitly said so elsewhere.
> And thinking that strncpy will enforce a null at the end actually seems nonsensical to me.
That's bizarre, seeing as there are similar functions that do exactly that. I certainly understand having internalized that strncpy doesn't happen to, but I don't see how you can call it nonsensical.
- taeric 10y agoSo we are at large violently agreeing. :) It is nonsensical because I know it doesn't. I grant that that is a learned thing. I do question how folks thought that it could do this. If you pass it n bytes with no null, how should it pick where to start putting the nulls? Last byte is somewhat intuitive, but then the behaviour will lead to string corruption pretty quickly.
- dllthomas 10y ago> It is nonsensical because I know it doesn't. You seem to be missing a distinction I would draw between "counterfactual" and "nonsensical". The assumption that a function prefaced with "str" makes a well-formed str seems reasonable (if, it happens, misguided). When given too long a string, the function will truncate - there's not really anything else it could do. The question is only where it truncates. > the behaviour will lead to string corruption pretty quickly. It will lead immediately to string truncation - whether that's acceptable depends on context, and can be checked for. Is there something you're worried about that I'm missing?
- taeric 10y agoI'm not sure of the distinction. I can certainly appreciate opposing views, though. So, don't assume I'm fighting tooth and nail for c, here. My sibling comment of treating this like knives is ultimately my view. Strncpy is a very sharp tool. This makes it safer than strcpy. It is by no means safe, though. Just like sharper knives are safer, but still only safe with training and proper user. So, that a function prefixed with str has some special treatment for strings makes sense. Otherwise just use memcpy. :) The question is natural for how it truncates. It so happens the answer is by stopping. You imply it should do so by altering the string. I can see arguments either way. For the rest, Truncation is a form of corruption. So I'm not sure where you are taking that line. Was it just my rhetoric? (I'm mainly typing on my phone, so using loose and likely mistyped phrases.)
- dllthomas 10y agoSharps knives are only safer when in use. At rest in a drawer, or tub of soapy water, dull knives are safer. I don't see how that's applicable, though :-P > The question is natural for how it truncates. It so happens the answer is by stopping. You imply it should do so by altering the string. I can see arguments either way. So can I, and I think that's the distinction I draw. Something is nonsensical if I really can't see any arguments for it. It's counterfactual if things could reasonably have gone that way but didn't. > For the rest, Truncation is a form of corruption. So I'm not sure where you are taking that line. Was it just my rhetoric? Truncation is, indeed, a form of corruption. It is perhaps acceptable in more circumstances than other forms of corruption. It wasn't exactly that I thought, from your rhetoric, that you were referring to something else. But on the off chance you were, I definitely wanted to know about it.