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

[bd]

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++)
Every time you go through the loop, you get the length of the string again.
Since it's not going to change, this is a huge waste of time (turns an O(n)
algorithm into an O(n^2) !). Save strlen(s) to a local variable once, then
use that instead.
*(r+i) = *(s+strlen(s)-1-i);
return r;
}

[Thomas Stegen]

Default User wrote:

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.

A standard compliant strlen is not allowed to change the string.
If a function can do whatever it wants as long as the standard
does not specify that it cannot then it is impossible to write a
strictly conforming program that uses any standard functions.

In fact the standard only specifies what operators do, not what
they cannot do! It would in fact be impossible to write any strictly
conforming program at all with the possible exception of

int main(void)
{
return 0;
}

But then again, the standard does not specify completely what return
cannot do.

Relating to the point above. The compiler can optimise out calls to
strlen because it knows the implementation. In general it cannot do this
with functions unless it can deduce that no side effects are taking
place and that is impossible by just looking at the prototype. It is
possible (sometimes) if the compiler has access to the implementation of
a function.
--
Thomas.

[Ravi Uday]

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******** *************** ***********@uni x49.andrew.cmu. edu...

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.)

Ok.. so if i want to use my own 'strlen' (my_strlen) instead of standard
one(or any function defined by standard )can I not do that ?

Something like
#ifdef strlen
#undef strlen
#define strlen my_strlen

Cant afford to change all the places where i have called strlen !

- Ravi


-Arthur

[Nils O. Selåsdal]

Thomas Stegen wrote:

Relating to the point above. The compiler can optimise out calls to
strlen because it knows the implementation. In general it cannot do this
with functions unless it can deduce that no side effects are taking
place and that is impossible by just looking at the prototype. It is
possible (sometimes) if the compiler has access to the implementation of
a function.

It would also have to perform a bit heuristic to determin that calls
to strlen could be done fewer times than actual started. This can
quickly become nontrivial.

[pete]

Ravi Uday wrote:

Ok.. so if i want to use my own 'strlen'
(my_strlen) instead of standard
one(or any function defined by standard )can I not do that ?

Something like
#ifdef strlen
#undef strlen
#define strlen my_strlen

Cant afford to change all the places where i have called strlen !

That doesn't do anything if strlen isn't implemented as a macro.
It doesn't have to be and I think that strlen usually isn't.

I don't know if redefining standard macros yields undefined behavior.
It seems like a bad idea.

--
pete

[Michael Mair]

Hiho,

pete wrote:

Ravi Uday wrote:

Ok.. so if i want to use my own 'strlen'
(my_strlen) instead of standard
one(or any function defined by standard )can I not do that ?

Something like
#ifdef strlen
#undef strlen
#define strlen my_strlen

Cant afford to change all the places where i have called strlen !

Umh, the standard says strlen is a function so you cannot do this.
Apart from that: If you "hide" this nice trick of yours in a
general header file and other people are not aware of that then
they expect strlen (read: my_strlen) to behave like strlen (read:
strlen). If you really want to do something along these lines,
use a macro with a name like STRLEN or even a function pointer
called, for example, StrLenPtr. Thus, your intent becomes clearer.
Do not use names starting with str as these are reserved for
future library extensions.

That doesn't do anything if strlen isn't implemented as a macro.
Unfortunately, if you do it "right", it does:

#include <string.h>

#ifdef strlen
#undef strlen
#endif
#define strlen(STR) my_strlen(STR)

size_t my_strlen(const char *s)
{
return 0;
}

int main (void)
{
strlen("test");

return 0;
}

compiles and a look at the preprocessor output shows that
strlen("test");
becomes
my_strlen("test ");

You can have very funny effects if you use my_strlen() in very
rare cases as wrapper for strlen() but #define strlen before
you define my_strlen(). Then, everything works most of the time
but in some cases you have either recursive calls to my_strlen
without end or seemingly arbitrary results or whatever.
Nice trap.

It doesn't have to be and I think that strlen usually isn't.
Yep.
I don't know if redefining standard macros yields undefined behavior.
It seems like a bad idea.

Definitely! I'd even go as far and declare it a Bad Idea...
Cheers
Michael

[pete]

Michael Mair wrote:

Hiho,

pete wrote:

Ravi Uday wrote:

Something like
#ifdef strlen
#undef strlen
#define strlen my_strlen

That doesn't do anything if strlen isn't implemented as a macro.

Unfortunately, if you do it "right", it does:

Thank you.

--
pete

[Michael Wojcik]

In article <I5********@new s.boeing.com>, "Default User" <fi********@boe ing.com.invalid > writes:

Robert Harris wrote:

Default User wrote:

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.

The special case of standard functions aside, and the case of casting
away constness aside, this still isn't sufficient to optimize away
the call to a function. The function could have side effects besides
altering its parameters.

The *only* reason why an implementation might be able to optimize
away calls to standard functions is because it knows exactly what
they do. That's the only sufficient guarantee. (Note that this
also requires the restriction against redefining them.)

Of course, an implementation could introduce an extension - such as
a pragma - to denote "pure" functions which have no side effects and
make no use of external state and so could be similarly optimized
away when called repeatedly with the same parameters.[1] However,
standard C has no such facility.
1. Note that a function with no side effects must be a function only
of its input. Maintaining any kind of state between calls would be
a side effect. The restriction against using external state is
necessary to exclude things like clock(), which has no side effects
(except indirectly the one of taking non-zero execution time) but
should not be optimized away, as its return value changes over time.

--
Michael Wojcik mi************@ microfocus.com

The surface of the word "profession " is hard and rough, the inside mixed with
poison. It's this that prevents me crossing over. And what is there on the
other side? Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)

[Randy Howard]

In article <I5********@new s.boeing.com>, fi********@boei ng.com.invalid says...

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?

Not any of the majors, including gcc, lcc-win32 and MSVC. See a recent
thread on loop invariants in comp.programmin g for empirical data based
upon this same question.

--
Randy Howard (2reply remove FOOBAR)

[Randy Howard]

In article <MP************ ************@ne ws.verizon.net> ,
ra*********@FOO verizonBAR.net says...

In article <I5********@new s.boeing.com>, fi********@boei ng.com.invalid says...

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?

Not any of the majors, including gcc, lcc-win32 and MSVC. See a recent
thread on loop invariants in comp.programmin g for empirical data based
upon this same question.

Correction, I didn't mean to imply that lcc is a "major" compiler, it
just happened to come up near the end of the thread and I included it
as a result.

--
Randy Howard (2reply remove FOOBAR)