Highly efficient string reversal code

[dominantubergeek]

Hello, I'm a highly experienced expert C programmer and I've written
this code to reverse a string in place. I think you could all learn
something from it!

int reverse(char* reverseme){
int retval=-1;
if(retval!=NULL ){
int len=strlen(retv al){
if(len>0){
int half=len>>1;
for(;retval<hal f;retval++){
reverseme[retval]^=reverseme[len-(retval+1)];
reverseme[len-(retval+1)]=reverseme[retval];
reverseme[retval]^=reverseme[len-(retval+1)];
}
}
}
return retval;
}

-Phil/CERisE

[Ben Bacarisse]

Antoninus Twink <no****@nospam. invalidwrites:

On 28 Sep 2008 at 21:23, Ben Bacarisse wrote:

>I presume you share Richard's preference for interactive debugging?

Hmm? Apart from the fact that a | has wrongly become a & in this line...

>> if(((unsigned long) s & len & 0x11)==0) {

...(and as a result of the correction extra parentheses are needed), I
don't see any obvious bug.

Nothing happens when len == 4.

--
Ben.

[Antoninus Twink]

On 28 Sep 2008 at 22:17, Ben Bacarisse wrote:

Nothing happens when len == 4.

Oops, yes, thanks.

I did the usual amount of debugging before posting to Usenet (i.e.
zero)...

[Tim Rentsch]

Barry Schwarz <sc******@dqel. comwrites:

On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cb********@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.

I believe you're wrong. Types such as unsigned char that don't
have trap representations only have unspecified values if
accessed, not undefined behavior. Please support your claim
with a section citation.

[Barry Schwarz]

On 09 Oct 2008 00:12:21 -0700, Tim Rentsch <tx*@alumnus.ca ltech.edu>
wrote:

>Barry Schwarz <sc******@dqel. comwrites:

>On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cb********@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
representati on (or otherwise invalid) but whether it is indeterminate
or not. Evaluating an indeterminate value invokes undefined behavior.

I believe you're wrong. Types such as unsigned char that don't
have trap representations only have unspecified values if
accessed, not undefined behavior. Please support your claim
with a section citation.

The fact that char (all three types) does not have traps is covered in
6.2.6.1-5 and again in the 11th clause of J.2. That is completely
separate from the issue of indeterminate values which is covered in
the 10th clause of J.2 with references to 6.2.4, 6.7.8, and 6.8.
Unfortunately, those sections only state that the value is
indeterminate. And I could not find anything n1336 that improves the
situation.

--
Remove del for email

[Tim Rentsch]

Barry Schwarz <sc******@dqel. comwrites:

On 09 Oct 2008 00:12:21 -0700, Tim Rentsch <tx*@alumnus.ca ltech.edu>
wrote:

Barry Schwarz <sc******@dqel. comwrites:

On Fri, 26 Sep 2008 21:20:11 -0400, CBFalconer <cb********@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.

I believe you're wrong. Types such as unsigned char that don't
have trap representations only have unspecified values if
accessed, not undefined behavior. Please support your claim
with a section citation.

The fact that char (all three types) does not have traps is covered in
6.2.6.1-5 and again in the 11th clause of J.2. That is completely
separate from the issue of indeterminate values which is covered in
the 10th clause of J.2 with references to 6.2.4, 6.7.8, and 6.8.
Unfortunately, those sections only state that the value is
indeterminate. And I could not find anything n1336 that improves the
situation.

6.8 p 3 says "(including storing an indeterminate value in
objects without an initializer)". Since (unsigned char) doesn't
have any trap representations , storing an indeterminate value
means storing an unspecified value. The comment in J.2 item 10
is a non-normative simplification.

On implementations where other types (e.g., unsigned int) don't
have trap representations , leaving such variables uninitialized
also produces only unspecified values, not undefined behavior.

Incidentally, I think it's generally agreed that (char) and
(signed char) can have trap representations , even though
(unsigned char) cannot.