Highly efficient string reversal code

[lovecreatesbeauty@gmail.com]

Re: Highly efficient string reversal code

On Sep 26, 4:56 pm, "Rosario" <x...@y.zwrot e:

>
unsigned my_strrev(char *s)
{unsigned h;
char *e, t;
if(s==0) return 0;
h=strlen(s);
if((int)h<=0) return 0;
e=s+h-1;
for( ;e>s ;--e,++s)
{t=*s; *s=*e; *e=t;}
return h;
>
}
>
not tested
don't know if "if((int)h< =0) return 0;" is right
>

The length of a string won't be a negative. The cast also isn't
required. The rest of it seems fine :)

[CBFalconer]

Re: Highly efficient string reversal code

pete wrote:

Rosario wrote:
>

.... snip ...

>

>char *reverse(char *p) {
> char *p1, *p2, ch;
>>
> for (p1 = p; *(p1 + 1); p1++) ;

>
*(p1 + 1) is undefined for a zero length string.

Nit picking time.

No it isn't. It is if that string is stored in a char array
smaller than array of two chars.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[vippstar@gmail.com]

Re: Highly efficient string reversal code

On Sep 26, 5:20 pm, CBFalconer <cbfalco...@yah oo.comwrote:

pete wrote:

Rosario wrote:

>
... snip ...
>

char *reverse(char *p) {
char *p1, *p2, ch;

>

for (p1 = p; *(p1 + 1); p1++) ;

>

*(p1 + 1) is undefined for a zero length string.

>
Nit picking time.
>
No it isn't. It is if that string is stored in a char array
smaller than array of two chars.

Nit picking time :-)
Yes it is,

char foo[2];
foo[0] = 0;
reverse(foo);

[Barry Schwarz]

Re: Highly efficient string reversal code

On Fri, 26 Sep 2008 08:04:29 -0700 (PDT), vippstar@gmail. com wrote:

>On Sep 26, 5:20 pm, CBFalconer <cbfalco...@yah oo.comwrote:

>pete wrote:

Rosario wrote:

>>
>... snip ...
>>

>char *reverse(char *p) {
> char *p1, *p2, ch;

>>

> for (p1 = p; *(p1 + 1); p1++) ;

>>

*(p1 + 1) is undefined for a zero length string.

>>
>Nit picking time.
>>
>No it isn't. It is if that string is stored in a char array
>smaller than array of two chars.

>
>Nit picking time :-)
>Yes it is,
>
>char foo[2];

Which array do you think is smaller than two characters?

>foo[0] = 0;

Since the value in foo[1] is indeterminate, *(p1+1) still invokes
undefined behavior.

>reverse(foo) ;

--
Remove del for email

[CBFalconer]

Re: Highly efficient string reversal code

Barry Schwarz wrote:

vippstar@gmail. com wrote:

>CBFalconer <cbfalco...@yah oo.comwrote:

>>pete wrote:
>>>Rosario wrote:
>>>
>>... snip ...
>>>
>>>>char *reverse(char *p) {
>>>> char *p1, *p2, ch;
>>>>>
>>>> for (p1 = p; *(p1 + 1); p1++) ;
>>>>
>>>*(p1 + 1) is undefined for a zero length string.
>>>
>>Nit picking time.
>>>
>>No it isn't. It is if that string is stored in a char array
>>smaller than array of two chars.

>>
>Nit picking time :-) Yes it is,
>>
>char foo[2];

>
Which array do you think is smaller than two characters?
>

>foo[0] = 0;

>
Since the value in foo[1] is indeterminate, *(p1+1) still
invokes undefined behavior.

No it doesn't. foo is a char array. foo[1] is a char. By
definition, a char cannot have unused bits. Therefore *(p1 + 1)
is a valid char even though uninitialized.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Barry Schwarz]

Re: Highly efficient string reversal code

On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cbfalconer@yah oo.com>
wrote:

>Barry Schwarz wrote:

>vippstar@gmail. com wrote:

>>CBFalconer <cbfalco...@yah oo.comwrote:
>>>pete wrote:
>>>>Rosario wrote:
>>>>
>>>... snip ...
>>>>
>>>>>char *reverse(char *p) {
>>>>> char *p1, *p2, ch;
>>>>>>
>>>>> for (p1 = p; *(p1 + 1); p1++) ;
>>>>>
>>>>*(p1 + 1) is undefined for a zero length string.
>>>>
>>>Nit picking time.
>>>>
>>>No it isn't. It is if that string is stored in a char array
>>>smaller than array of two chars.
>>>
>>Nit picking time :-) Yes it is,
>>>
>>char foo[2];

>>
>Which array do you think is smaller than two characters?
>>

>>foo[0] = 0;

>>
>Since the value in foo[1] is indeterminate, *(p1+1) still
>invokes undefined behavior.

>
>No it doesn't. foo is a char array. foo[1] is a char. By
>definition, a char cannot have unused bits. Therefore *(p1 + 1)
>is a valid char even though uninitialized.

The issue is not whether foo[1] could possibly be a trap
representation (or otherwise invalid) but whether it is indeterminate
or not. Evaluating an indeterminate value invokes undefined behavior.

--
Remove del for email

[blargg]

Re: Highly efficient string reversal code

In article
<abb6ffb8-3b12-4277-87c9-fb0dc17d93b5@v1 6g2000prc.googl egroups.com>,
"lovecreatesbea uty@gmail.com" <lovecreatesbea uty@gmail.comwr ote:

On Sep 26, 4:56 pm, "Rosario" <x...@y.zwrot e:

unsigned my_strrev(char *s)
{unsigned h;
char *e, t;
if(s==0) return 0;
h=strlen(s);
if((int)h<=0) return 0;
e=s+h-1;
for( ;e>s ;--e,++s)
{t=*s; *s=*e; *e=t;}
return h;

}

not tested
don't know if "if((int)h< =0) return 0;" is right

>
The length of a string won't be a negative. The cast also isn't
required.

The cast in fact causes it to fail for strings of length INT_MAX,
since it casts a value greater than INT_MAX to an int, yielding
implementation-defined behavior (which on most machines, means you get a
negative value that causes the code to return 0).

Also, strlen returns size_t, which might be larger than unsigned, so it
could also fail on a 64-bit machine when given a string longer than
UINT_MAX.

[blargg]

Re: Highly efficient string reversal code

My somewhat late entry (two actually), and to keep with the implicit
tradition, untested except mentally. I don't think they invoke any UB,
for any valid string length (that is, 0 to (size_t) -1).

/* Minimal version, no frills, s must not be NULL */
void strrev1(char *s)
{
char* e = s;
while ( *e )
++e;

while ( e s )
{
char t = *s;
*s++ = *--e;
*e = t;
}
}

/* returns length (0 if s is NULL) */
size_t strrev2(char *s)
{
size_t len = 0;
if ( s != NULL )
{
len = strlen( s );
char* e = s + len;
while ( e s+1 ) /* s+1 eliminates extra iter */
{
char t = *s;
*s++ = *--e;
*e = t;
}
}
return len;
}

[vippstar@gmail.com]

Re: Highly efficient string reversal code

On Sep 27, 3:32 am, Barry Schwarz <schwa...@dqel. comwrote:

On Fri, 26 Sep 2008 08:04:29 -0700 (PDT), vipps...@gmail. com wrote:

On Sep 26, 5:20 pm, CBFalconer <cbfalco...@yah oo.comwrote:

pete wrote:
Rosario wrote:

>

... snip ...

>

char *reverse(char *p) {
char *p1, *p2, ch;

>

for (p1 = p; *(p1 + 1); p1++) ;

>

*(p1 + 1) is undefined for a zero length string.

>

Nit picking time.

>

No it isn't. It is if that string is stored in a char array
smaller than array of two chars.

>

Nit picking time :-)
Yes it is,

>

char foo[2];

>
Which array do you think is smaller than two characters?

Hmm... ?
CBFalconer claimed this:

No it isn't [undefined behavior, unless] It is if that string is stored
in a char array smaller than array of two chars.

Which means he claims with arrays equal or greater than two chars it
won't invoke undefined behavior.
char [2] is such array, but my code does invoke undefined behavior.

foo[0] = 0;

>
Since the value in foo[1] is indeterminate, *(p1+1) still invokes
undefined behavior.

That's what I wanted to demonstrate.

reverse(foo);

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: Highly efficient string reversal code

On Fri, 26 Sep 2008 22:52:53 -0700, Barry Schwarz wrote:

On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cbfalconer@yah oo.com>
wrote:

>>No it doesn't. foo is a char array. foo[1] is a char. By definition,
>>a char cannot have unused bits. Therefore *(p1 + 1) is a valid char
>>even though uninitialized.

>
The issue is not whether foo[1] could possibly be a trap representation
(or otherwise invalid) but whether it is indeterminate or not.
Evaluating an indeterminate value invokes undefined behavior.

Not in C99. In C99, if you read a trap representation, the behaviour is
undefined if the type is not a character type, and if you read an
indeterminate value, there is usually a possibility of reading a trap
representation. When that possibility does exist but the type is a
character type, the behaviour is not explicitly undefined, but may be
undefined by omission. When that possibility doesn't exist, the behaviour
is defined.

C90 didn't have the concept of trap representations , and reading
indeterminate values of any type was not allowed, and the next C standard
will apparently reintroduce undefined behaviour for reading uninitialised
values in certain situations, so relying on C99's requirements is probably
not a good idea here.

[vippstar@gmail.com]

Re: Highly efficient string reversal code

On Sep 27, 12:07 pm, Harald van D©¦k <true...@gmail. comwrote:

On Fri, 26 Sep 2008 22:52:53 -0700, Barry Schwarz wrote:

On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cbfalco...@yah oo.com>
wrote:

>No it doesn't. foo is a char array. foo[1] is a char. By definition,
>a char cannot have unused bits. Therefore *(p1 + 1) is a valid char
>even though uninitialized.

>

The issue is not whether foo[1] could possibly be a trap representation
(or otherwise invalid) but whether it is indeterminate or not.
Evaluating an indeterminate value invokes undefined behavior.

>
Not in C99. In C99, if you read a trap representation, the behaviour is
undefined if the type is not a character type, and if you read an
indeterminate value, there is usually a possibility of reading a trap
representation. When that possibility does exist but the type is a
character type, the behaviour is not explicitly undefined, but may be
undefined by omission. When that possibility doesn't exist, the behaviour
is defined.
>
C90 didn't have the concept of trap representations , and reading
indeterminate values of any type was not allowed, and the next C standard
will apparently reintroduce undefined behaviour for reading uninitialised
values in certain situations, so relying on C99's requirements is probably
not a good idea here.

It really doesn't matter whether it's C90 or C99, it both cases the
code invokes undefined behavior.
Here's what's snipped:

for (p1 = p; *(p1 + 1); p1++) ;

Here's what I claimed to invoke undefined behavior:

char foo[2];
foo[0] = 0;

/* p = foo */

Which is true, regardless of C90 or C99.

I think mr Schwarz agreed with what I said, in which case he's also
correct.

[CBFalconer]

Re: Highly efficient string reversal code

vippstar@gmail. com wrote:

Harald van D©¦k <true...@gmail. comwrote:

>Barry Schwarz wrote:

>>CBFalconer <cbfalco...@yah oo.comwrote:
>>>
>>>No it doesn't. foo is a char array. foo[1] is a char. By
>>>definition , a char cannot have unused bits. Therefore *(p1 + 1)
>>>is a valid char even though uninitialized.
>>>
>>The issue is not whether foo[1] could possibly be a trap
>>representatio n (or otherwise invalid) but whether it is
>>indetermina te or not. Evaluating an indeterminate value invokes
>>undefined behavior.

>>
>Not in C99. In C99, if you read a trap representation, the
>behaviour is undefined if the type is not a character type, and
>if you read an indeterminate value, there is usually a possibility
>of reading a trap representation. When that possibility does exist
>but the type is a character type, the behaviour is not explicitly
>undefined, but may be undefined by omission. When that possibility
>doesn't exist, the behaviour is defined.
>>
>C90 didn't have the concept of trap representations , and reading
>indeterminat e values of any type was not allowed, and the next C
>standard will apparently reintroduce undefined behaviour for
>reading uninitialised values in certain situations, so relying on
>C99's requirements is probably not a good idea here.

>
It really doesn't matter whether it's C90 or C99, it both cases the
code invokes undefined behavior.
>
Here's what's snipped:
>
for (p1 = p; *(p1 + 1); p1++) ;
>
Here's what I claimed to invoke undefined behavior:
>
char foo[2];
foo[0] = 0;
>
/* p = foo */
>
Which is true, regardless of C90 or C99.
>
I think mr Schwarz agreed with what I said, in which case he's also
correct.

No, you are wrong. The behaviour is undefined because *(p + 1)
yields an undefined value, and program action depends on the
zeroness of that value. Repeat, VALUE. It is NOT undefined
because of accessing that value, because by definition all possible
values in that location represent real chars.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[pete]

Re: Highly efficient string reversal code

CBFalconer wrote:

pete wrote:

>Rosario wrote:
>>

... snip ...

>>char *reverse(char *p) {
>> char *p1, *p2, ch;
>>>
>> for (p1 = p; *(p1 + 1); p1++) ;

>*(p1 + 1) is undefined for a zero length string.

>
Nit picking time.
>
No it isn't. It is if that string is stored in a char array
smaller than array of two chars.

Thank you.

--
pete

[vippstar@gmail.com]

Re: Highly efficient string reversal code

On Sep 27, 11:27 pm, CBFalconer <cbfalco...@yah oo.comwrote:

vipps...@gmail. com wrote:

Harald van Djik <true...@gmail. comwrote:

Barry Schwarz wrote:
>CBFalconer <cbfalco...@yah oo.comwrote:

>

>>No it doesn't. foo is a char array. foo[1] is a char. By
>>definition, a char cannot have unused bits. Therefore *(p1 + 1)
>>is a valid char even though uninitialized.

>

>The issue is not whether foo[1] could possibly be a trap
>representati on (or otherwise invalid) but whether it is
>indeterminat e or not. Evaluating an indeterminate value invokes
>undefined behavior.

>

Not in C99. In C99, if you read a trap representation, the
behaviour is undefined if the type is not a character type, and
if you read an indeterminate value, there is usually a possibility
of reading a trap representation. When that possibility does exist
but the type is a character type, the behaviour is not explicitly
undefined, but may be undefined by omission. When that possibility
doesn't exist, the behaviour is defined.

>

C90 didn't have the concept of trap representations , and reading
indeterminate values of any type was not allowed, and the next C
standard will apparently reintroduce undefined behaviour for
reading uninitialised values in certain situations, so relying on
C99's requirements is probably not a good idea here.

>

It really doesn't matter whether it's C90 or C99, it both cases the
code invokes undefined behavior.

>

Here's what's snipped:

>

for (p1 = p; *(p1 + 1); p1++) ;

>

Here's what I claimed to invoke undefined behavior:

>

char foo[2];
foo[0] = 0;

>

/* p = foo */

>

Which is true, regardless of C90 or C99.

>

I think mr Schwarz agreed with what I said, in which case he's also
correct.

>
No, you are wrong. The behaviour is undefined because *(p + 1)
yields an undefined value, and program action depends on the
zeroness of that value. Repeat, VALUE. It is NOT undefined
because of accessing that value, because by definition all possible
values in that location represent real chars.

Where have I claimed that it's undefined because the program accesses
that value?

[CBFalconer]

Re: Highly efficient string reversal code

vippstar@gmail. com wrote:

CBFalconer <cbfalco...@yah oo.comwrote:
>

.... snip ...

>

>No, you are wrong. The behaviour is undefined because *(p + 1)
>yields an undefined value, and program action depends on the
>zeroness of that value. Repeat, VALUE. It is NOT undefined
>because of accessing that value, because by definition all
>possible values in that location represent real chars.

>
Where have I claimed that it's undefined because the program
accesses that value?

Maybe I read something you didn't say. At any rate, I just wanted
to clear the matter up.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.