There seems to be some confusion regarding weak/strong and static/dynamic typing.  Ruby is clearly dynamic-typed.  But it's also fairly strong-typed.

dlikhten:

morbiuswilters:

Would that possibly be because Ruby is a dynamically typed language and has no way of checking types at all?

Check the ruby site "for java developers" they say it themselves.

That site is trying to convince you to use Ruby.  They can say whatever they want, but that doesn't make it true.  Not that I'm arguing with the site, but just keep that in mind.

A dynamicly typed language is something like ActionScript. You can define properties of an object at run time. In ruby you cant do Object.valueX=1 unless valueX= is a function defined in that class.

  Sure you can.  It just passes the message to the class's method_missing.   From there you're welcome to add the method at runtime.  That's pretty freaking dynamic, no?

Strongly typed does not mean that type is declared at compile time. In ruby you don't need to define what type a variable is, but you absolutely know the type of the object at run time.

If by "you" you mean the programmer, then I'd say, not necessarily.  Yes, the RTE knows the types, but duck typing is based around the fact that I don't have to care.  Does it respond to the message "foo"?  Super, then I can do a.foo and b.foo, without knowing or caring what the types are.

morbiuswilters:

Spectre is incorrect, though, it is meant for copying null-terminated strings, that's why it halts on a null in the source string.  If your source isn't null-terminated and your size is larger than the source, you get read errors, so it's obviously meant for copying null-terminated strings.

I think the real purpose of strncpy is to copy fixed-width strings (there's a nice article CodeSimian linked to). The NUL-termination stuff comes from a) the need to terminate strings with something and b) speedier implementation (no need to copy everything past NUL).

 This is old news - see Overload December 05: Editorial: The "Safe C++ Standard Library"

Spectre:

I think the real purpose of strncpy is to copy fixed-width strings (there's a nice article CodeSimian linked to). The NUL-termination stuff comes from a) the need to terminate strings with something and b) speedier implementation (no need to copy everything past NUL).

If the strings were fixed-width you'd be better off doing a memcpy(), which will be much faster since it doesn't have to check any of the bytes being copied.  strncpy() is the same as strcpy() except it takes a maximum length to copy from the source and if it reaches a null in the source, it fills in the rest of destination with null bytes.  strncpy() is absolutely meant to copy null-terminated strings.  The additional benefit is if you are copying from a larger string into a smaller buffer, you can use the size limiter to move the "window" you are copying from along.  Otherwise, you'd have to implement this in a loop using pointer arithmetic. 

AlanGriffiths:

 This is old news - see Overload December 05: Editorial: The "Safe C++ Standard Library"

TRWTF is that site is serving up XHTML as text/html which makes Safari and FF show the literal HTML entities in the title bar... 

morbiuswilters:

Spectre:

I think the real purpose of strncpy is to copy fixed-width strings (there's a nice article CodeSimian linked to). The NUL-termination stuff comes from a) the need to terminate strings with something and b) speedier implementation (no need to copy everything past NUL).

If the strings were fixed-width you'd be better off doing a memcpy(), which will be much faster since it doesn't have to check any of the bytes being copied.  strncpy() is the same as strcpy() except it takes a maximum length to copy from the source and if it reaches a null in the source, it fills in the rest of destination with null bytes.  strncpy() is absolutely meant to copy null-terminated strings.  The additional benefit is if you are copying from a larger string into a smaller buffer, you can use the size limiter to move the "window" you are copying from along.  Otherwise, you'd have to implement this in a loop using pointer arithmetic. 

I think I used wrong words. Surely the source in strncpy can be an ordinary NUL-terminated string, but the destination isn't — it's a fixed-width, NUL-padded string. You can use a kludge to coerce it into a NUL-terminated string, but why even use a function that doesn't give you what you want, is slower than optimal (NUL-padding) and doesn't allow an easy way to check for truncation (it returns a pointer to destination)? This was my point.

Spectre:

I think I used wrong words. Surely the source in strncpy can be an ordinary NUL-terminated string, but the destination isn't — it's a fixed-width, NUL-padded string. You can use a kludge to coerce it into a NUL-terminated string, but why even use a function that doesn't give you what you want, is slower than optimal (NUL-padding) and doesn't allow an easy way to check for truncation (it returns a pointer to destination)? This was my point.

 

Is this what you mean by "fixed-width destination"? 

morbiuswilters:

The additional benefit is if you are copying from a larger string into a smaller buffer, you can use the size limiter to move the "window" you are copying from along.

 

The destination doesn't have to end in a null.  Obviously if it doesn't, you can't use it in normal string functions, but if you are using it as a buffer to write to something else, it's fine.  The point of strncpy() is to let you copy from a larger string to a small one without overflowing the smaller (assuming you pass the right size) and without reading past the end of the source string (which could be variable-length).  Once again, it has its place.  If you want safer strings, there are better functions, or even fully-managed languages.  If you want unicode, you will need to use something.  Still, strncpy() is fairly useful.

OK, seems we are arguing over nothing. Never mind then.