I think stroi is a typo.

Heh, yes, so it is. I meant atoi().

[off topic]
Do you have a link detailing how you uv unwrapped that rigged blender model?
It is always something I've been meaning to do but never got round to it. Or did you use a python script?

Are you talking about that Billy model in "Action Constraints Made Easy" or Waffler's pink girl?
I don't think I did anything particularly amazing in either one... (or maybe you are thinking of someone else?)

Hmm... I did spend some time on Billy's shoes...
There is a tutorial (in the tutorials section) that helped me a lot about properly unwrapping a face and head. The real trick is to select only the faces that define the shape first, LSCM, adjust, pin, select more faces, repeat...

/me goes to figure out what I did

Ah you rigged waffler's pink girl too?

Yeah I was talking bout the billy model. But yeah what's good video tutorials?

Alas, I've never had much patience for video tutorials. The ones at ibiblio are usually okay but I haven't spent much time looking through them.

If you really thing a tut is a good idea I can cobble one together sometime within the next week or so, or at least link to some good ones I can find that do what I did.

I don't know if you remember or not, but Waffler did his "Pink Girl" 2D sketch and I thought it would be fun to model and rig. So we both (and I think one other) did a bunch of pink girls. I tried to get everything to look as cartooney as the original, but cipix and a few others modified my facial textures to be more pen-and-ink-ish. But I think my pink girl was the only one that was ever fully rigged. She's only slightly more complex than Billy though... The arms and legs are wobbly tubes (rigged with IK chains) in both.

Both the files can be downloaded and you can look at the UV mapping in them.

>I never said memcpy() wasn't standard.
The implication was there. Just think of it as adding to your answer rather than correcting you.

>If not, you may very well be playing with fire to try reading
>(or writing) past the end of memory you have not allocated.
I don't even know what you're trying to say anymore. Perhaps if you gave some examples that show your point more clearly. It seems like you're trying to make strncpy somehow better than memcpy because the count represents an "at most" count rather than a hard count.

In that case, owning the source is irrelevant provided you use a sane value for the count argument. For example, the count would be acquired by calling strlen on the source and then verifying that the destination is big enough to handle it. Whether you're using memcpy or strncpy (or strcpy for that matter), it's wise to get your destination size right, which typically means learning the size of the source.

>However, it stops reading the source when it hits the end of the string
Yes, that's typical of the str* functions, whereas the mem* functions take a count rather than assuming a null terminated string for the source.

>The strtol() has the same validation problems as stroi().
No, it doesn't. It has completely defined and predictable behavior if there's a conversion error, the location and type of which you can pinpoint and recover from with ease. atoi isn't even close to strtol in robustness.

>Just because it returns something different...
And sets errno, and sets a pointer to where the conversion failed, and the return value tells you what kind of overflow (if any) occurred without invoking undefined behavior. The error detection potential of strtol is quite good.

> The implication was there.
No, it wasn't. However, I can see how it could have been read as such. I will try to be more explicit in the future.

> Perhaps if you gave some examples that show your point more clearly.
The argv array is prepared by the startup code. You did not allocate it. Therefore, you cannot make assumptions on what data you are allowed to read near it.
[memory you are allowed to read][memory you are not allowed to read]
The quick brown fox...\0........READ.AND.CRASH......................

When you say
memcpy( mybuf, argv[ n ], 50 );
you run the very real possibility that you will will try to read something that the processor will disallow, causing your program to fail. Granted, I don't know any PC where that will happen, but the point is that you are assuming something about implementation dependent architecture.

You should instead stick to reading only that which you are given:
strncat( mybuf, argv[ n ], 50 );
This (or my previously proffered strncpy()) guarantees that you are not going to violate any memory restrictions, wrap segments, or do anything else that your particular processor may spring on you, because you know that you are not reading memory that does not belong to you. Just because you've been able to get away with it on a PC for years doesn't mean that you will be able to get away with it on some other computer, or even some future PC.

I agree completely with having a sane count. The prerequisite is of course knowing the size of your source (as you have already pointed out).

As for strtol(), I've already conceded that it is superior to atoi() because "...you can pinpoint and recover from with ease" any conversion errors. However, I will now concede that it is in every way a superior choice than atoi(). (My concern was only in what you must code to recover from the error "properly" --which depends on your program goals. If you use atoi() you must find the information that strtol() gives you for free. Actual interpretation of that data is otherwise much the same.)


Alas, for new programmers I usually try not to get too deep into this junk. Only to point out when something may not be safe. Using memcpy() to read past the end of he source buffer is always unsafe. So either have a sane count (obtained by first checking the length of the source buffer) or when using strings use something that will properly terminate for you when the null is encountered, such as strncpy() or strncat().
That's all.

>you are assuming something about implementation dependent architecture
No, you're assuming that 50 is meaningful in telling you the length of the source string. The two examples are not equivalent because you're just using an arbitrary number all willy-nilly with memcpy, but taking advantage of the fact that strncat will stop at a null character while memcpy uses the count unconditionally. The equivalent memcpy to
is
It looks like your point is resting completely on memcpy being called incorrectly and strncat (or strncpy) being called correctly. Of course, using memcpy with strings when one of the str* functions is better suited strikes me as a poor design decision to begin with. Since it's clearly harder to get memcpy right in this case, I agree with you in principle, just not in the details.

Yes, yes, exactly. Thank you.

I've nothing against memcpy(). Just using it improperly.