strlen in a for loop with malloc-ed char*

[apropo]

what is wrong with this code? someone told me there is a BAD practice with
that strlen in the for loop, but i don't get it exactly. Could anyone
explain me in plain english,please?

char *reverse(char *s)
{
int i;
char *r;
if(!s) return NULL;//ERROR
r=calloc(strlen (s)+1,sizeof(ch ar));
if(!r) return NULL;
for(i=0;i<strle n(s);i++)
*(r+i) = *(s+strlen(s)-1-i);
return r;
}

--
it's not right. it's not even wrong

[Nils O. Selåsdal]

On Tue, 19 Oct 2004 18:53:37 +0000, apropo wrote:

what is wrong with this code? someone told me there is a BAD practice with
that strlen in the for loop, but i don't get it exactly. Could anyone
explain me in plain english,please? You calculate the strlen() many times, which really isn't needed char *reverse(char *s)
{
int i;
char *r; size_t len; if(!s) return NULL;//ERROR len = strlen(s);
r=calloc(len+1, sizeof(char)); if(!r) return NULL; for(i=0;i<len;i ++)
*(r+i) = *(s+len-1-i); return r;
}

[David Resnick]

apropo wrote:

what is wrong with this code? someone told me there is a BAD practice with
that strlen in the for loop, but i don't get it exactly. Could anyone
explain me in plain english,please?

char *reverse(char *s)
{
int i;
char *r;
if(!s) return NULL;//ERROR
r=calloc(strlen (s)+1,sizeof(ch ar));
if(!r) return NULL;
for(i=0;i<strle n(s);i++)
*(r+i) = *(s+strlen(s)-1-i);
return r;
}

Computing something within a loop that is invarient is wasteful.
The length of "s" isn't changed by this function, so you might
consider taking it in as a const char * to reflect that. Anyway,
more normal would be to do:

size_t len = strlen(s);

And then use len where you are using strlen(s). It is possible
that the optimizer might fix this for you, but why ask for
trouble?

The code isn't "wrong", just burns CPU where it need not.
The calloc is also slightly wasteful, in that you are zeroing
out the memory you are about to fill in just to get the nul
termination, you could just have r[len] = '\0'; after mallocing it.
Whatever.

-David

[Malcolm]

"apropo" <fl***********@ yahoo.com> wrote

for(i=0;i<strle n(s);i++)
*(r+i) = *(s+strlen(s)-1-i);

Imagine that the string s is huge. Then remember how the computer will
implement strlen() (write the function yourself, if you are not sure).

Are you familiar with Big O notation for algorithms? This tells you how many
operations you need for a given size of input. For instance to multiply by
repeated adding is O(N); you need to add the numbers as often as the smaller
is large. To use the algorithm you were taught at primary school is O(log
N), since the numbers of operations you require goes up by the number of
digits. The adding algorithm is OK for numbers up to ten or so, but for
large numbers the primary school way is far superior.

Similarly, your code is OK for fairly short strings, but for long ones you
will slow things down considerably. Can you work out its Big O notation?

[Default User]

David Resnick wrote:

Computing something within a loop that is invarient is wasteful.
The length of "s" isn't changed by this function, so you might
consider taking it in as a const char * to reflect that.

Are some compilers sophisticated enough to be able to detect this
condition and optimize away that strlen() call?

Brian

[Robert Harris]

Default User wrote:

David Resnick wrote:

Computing something within a loop that is invarient is wasteful.
The length of "s" isn't changed by this function, so you might
consider taking it in as a const char * to reflect that.
Are some compilers sophisticated enough to be able to detect this
condition and optimize away that strlen() call?

The compiler doesn't necessarily know what your strlen() does; after all
you can write it yourself!

Robert
Brian

[Arthur J. O'Dwyer]

On Tue, 19 Oct 2004, Robert Harris wrote:

Default User wrote:

David Resnick wrote:

Computing something within a loop that is invarient is wasteful.
The length of "s" isn't changed by this function, so you might
consider taking it in as a const char * to reflect that.

Are some compilers sophisticated enough to be able to detect this
condition and optimize away that strlen() call?

The compiler doesn't necessarily know what your strlen() does; after
all you can write it yourself!

Not in standard C. IIRC, attempting to redefine a standard library
function invokes undefined behavior. (And AFAIK it's quite possible that
the above optimization is the /only/ reason such redefinitions were made
undefined.)

-Arthur

[Default User]

Robert Harris wrote:

Default User wrote:

David Resnick wrote:

Computing something within a loop that is invarient is wasteful.
The length of "s" isn't changed by this function, so you might
consider taking it in as a const char * to reflect that.

Are some compilers sophisticated enough to be able to detect this
condition and optimize away that strlen() call?

The compiler doesn't necessarily know what your strlen() does; after
all you can write it yourself!

What do you mean? It knows its signature:

size_t strlen(const char *s)

Therefore it knows that it doesn't change s. It also knows what
strlen() does (as it is a standard library function).

Brian

[Ben Pfaff]

"Default User" <fi********@boe ing.com.invalid > writes:

What do you mean? It knows its signature:

size_t strlen(const char *s)

Therefore it knows that it doesn't change s.

Not true. A function parameter's const-ness does not allowed the
compiler to assume that the function will not modify the
argument. It is perfectly valid for it to cast away the
const-ness and modify it anyway (as long as the object that it
refers to is not actually defined as const). `const' in function
parameters is a social contract between the caller and the
callee, not a constraint made by the standard.
--
Ben Pfaff
email: bl*@cs.stanford .edu
web: http://benpfaff.org

[Default User]

Ben Pfaff wrote:

"Default User" <fi********@boe ing.com.invalid > writes:

What do you mean? It knows its signature:

size_t strlen(const char *s)

Therefore it knows that it doesn't change s.

Not true. A function parameter's const-ness does not allowed the
compiler to assume that the function will not modify the
argument. It is perfectly valid for it to cast away the
const-ness and modify it anyway (as long as the object that it
refers to is not actually defined as const). `const' in function
parameters is a social contract between the caller and the
callee, not a constraint made by the standard.

Ok, good point. Looking at n689, it specifies what strlen() does, but
doesn't say that it is forbidden to change the string. It would be a
pretty perverse implementation with a poor QOS.

Brian