Talk:Strlen

message: There appear to be no html markup tags available that allow inclusion of literally any character.  Repeated ' characters accomplish some of this, but this article is still technically incorrect.
jim mcnamara Aug 17 16:18 MDT
* Point to ponder: Should each programming language function have its own article? Deryck C. 18:17, 27 January 2006 (UTC)
thread_title: Untitled

message: This is invalid, correct?  In standard C it will cause undefined behavior, instead of returning 0?
Yes. "4.1.6 Use of library functions. Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow.  If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined."
Note that "undefined" may return 0 in your particular C implementation. Or it may return 42. Or it may terminate the program. The only thing "undefined" is prevented from doing is anything worse than program termination (such as physically damaging the computer) unless the manufacturer documents that behaviour. 150.101.30.44 (talk) 03:43, 31 July 2008 (UTC)
replies: text: "Undefined behaviour" exists not so that you can draw conclusions, but so that you can't and shouldn't attempt to draw conclusions. It is not necessary for an implementation to define undefined behaviour. It would seem you're confusing the concept with "implementation defined behaviour", for which the definition is required to be documented by compliant implementations. The C99 standard draft (n1256.pdf) states my point perfectly at section 3.4.3 where it defines "undefined behavior" as "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements". Plebbeh (talk) 03:07, 4 July 2011 (UTC)
thread_title:  strlen( NULL ) 

message: Can we please delete the "Multi-Byte approach" section?
Instead we can simply note that it is possible to implement strlen() by working with
the architecture's natural word size.
The explanation is confused. The interesting problems (i.e. taking care of unalignment)
are left as TODO. It's not clear that this is faster than a naive char-by-char strlen.
The article claims the code or algorithm is from HAKMEM, but doesn't give any specific
entry, and I was unable to find it there.
I've seen the general technique well implemented and correct, in (I think) OpenBSD's memcpy().
JöG (talk) 07:07, 4 January 2009 (UTC)
replies: text: You're right. Converting a pointer to char to a pointer to short, int, long, etc may be undefined behaviour as those types may have alignment requirements that can't be guaranteed when working with strings. The only pointers that you can guarantee have suitable alignment are those returned by malloc and friends, or those implicitly converted from arrays. It should be noted that, whether copying word-by-word is faster or not, "This approach is not required to work on every C implementation, and there are implementations in existence which will crash if the memory is not suitably aligned." Plebbeh (talk) 02:18, 4 July 2011 (UTC)
thread_title:  Skip "Multi-Byte approach" 

message: The current description about strlen() always being O(n) is wrong, unless one assumes that strings are all stored in bare C string format.  Other string storage formats SHOULD be mentioned and the performance impact should be kept as well.  I believe that my version which gets reverted have provided better vision in this topic and should be put back.  —Preceding unsigned comment added by Delphij (talk • contribs) 21:49, 21 April 2010 (UTC)
replies: text: Such an idea would make strlen(p+10) (where p is a char* pointer) not work, since the passed pointer is not pointing at the length. You would have to implement a memory model where p+10 produces an object from which the original p and the offset of 10 can be recovered in O(1) time. Certainly not impossible, but I suspect most implementations of such changes to standard C behavior also ditch nul-terminated strings. It may be that some C interpreters can do this, however.Spitzak (talk) 01:02, 28 June 2011 (UTC)
replies: text: The point I was trying to make is that saying strlen is O(n) constant time is invalid, because it is possible for it to be incorrect. Consider an implementation that sleeps for SIZE_MAX - n before returning from strlen; There's another example of O(1) constant time. It would be silly, but it's perfectly compliant by the C standard. I think an implementation that is optimal enough to make the formerly suggested optimisations would also be smart enough to keep track of pointer arithmetic on strings. You may be right; They may ditch the '\0', but the implementation would still be required to evaluate "hello"[strlen("hello")] to '\0'.Plebbeh (talk) 05:38, 1 July 2011 (UTC)
replies: text:  Actually we should not mention the complexity of the algorithm at all, since it is not defined by the standard. As we do mention the complexity, we are talking about implementations and not the Standard already. Please point out any implementation or algorithm that can compute strlen faster than O(n), given that C string can be any array or subarray of characters ending with a NUL character. Saying that one exists without a reference is WP:OR. Alleged slower implementations should not be mentioned also, except if you can prove that one exists, because of WP:N.1exec1 (talk) 12:09, 7 July 2011 (UTC)

text: Yes there are other ways to store strings. NONE of them have a function called "strlen" that takes a C pointer to a char. They are DIFFERENT functions and the whole point of the sentence "storing the length of the strings is the recommended fix" is to say that these DIFFERENT systems should be used. It is *not* an "optimization" because it is a DIFFERENT function that takes something other than a C pointer to char as input.Spitzak (talk) 19:11, 5 July 2011 (UTC)
thread_title:  strlen vs O(1) 

message: Hello. You might find  this discussion relevant. Thanks!1exec1 (talk) 09:06, 4 October 2011 (UTC)
thread_title:  Pages for each function and [[WP:NOTMANUAL]]