*p++ = tolower(*p));

[Gunvant Patil]

*p++ = tolower(*p));

is this behaviour defined in standards?

Suppose p points to "ABCD"

On BSD after executing above statement
*(p-1) is "a" means tolower is passed with non incremented value of p

On linux it is "b" means tolower is passed with incremented value of
p ??


-Cheers,
Gunvant
~~~~~~~~~~~~~~
No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.

 

[Richard Heathfield]

Gunvant Patil said:

*p++ = tolower(*p));

is this behaviour defined in standards?

I took one look at it and immediately knew the answer. "No... er, hmm,
sequence points, so yes... er, hang on, er, what if..., hmm..." which
is always a good hint that it's better to re-write it to reflect what
you actually mean (which isn't clear from the code).

 

[Chris Dollin]

*p++ = tolower(*p));

is this behaviour defined in standards?

It's defined to be undefined. So don't do it.

Suppose p points to "ABCD"

On BSD after executing above statement
*(p-1) is "a" means tolower is passed with non incremented value of p

On linux it is "b" means tolower is passed with incremented value of
p ??

On either system it means "do what you like, whatever's convenient, I
don't care.". The result will probably be whatever the compiler-writer
found convenient. If you're astonishingly lucky, the compiler might
notice in some cases that you're being undefined and say so; but in
general it can't tell. If you're astonishingly unlucky, the compiler
will notice and plant code to run Rogue when you execute the statement.
If you're routinely unlucky, everything will work as you like until the
day you upgrade the compiler / change the optimisation level / change
an apparently unrelated compiler option / run the code on a different
processor in the same family / port the code to a different implementation /
give a demonstration in front of a valued client.

Always a BOOM tomorrow.

 

[santosh]

*p++ = tolower(*p));

is this behaviour defined in standards?

No, it's a case of undefined behaviour. You might or might not get
sensible results depending, among others, on the compiler and the host
system.

 

[Gunvant Patil]

No, it's a case of undefined behaviour. You might or might not get
sensible results depending, among others, on the compiler and the host
system.

Thanks for the information guys. Inference is better i will rewrite my
code.

-Cheers,
Gunvant
~~~~~~~~~~~~~~
No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.

 

[christian.bau]

*p++ = tolower(*p));

is this behaviour defined in standards?

If it is defined, then you should be able to write down exactly what
it will do. If you can't do that, then you shouldn't use code like
that. Since you have to ask, you better change your code. The fact
that two compilers produce different results is another hint that you
should change your code.

 

[Dave Vandervies]

Gunvant Patil said:


I took one look at it and immediately knew the answer. "No... er, hmm,
sequence points, so yes... er, hang on, er, what if..., hmm..." which
is always a good hint that it's better to re-write it to reflect what
you actually mean (which isn't clear from the code).

tolower is explicitly permitted to be, and typically is, implemented as
a macro that masks the function definition, isn't it?

That would mean that there are no guaranteed sequence points here anyways,
according to footnote 145 of n869 (in 7.1.4#1), so it's undefined even if
having a sequence point when tolower executes would make it well-defined
(which I'm quite sure it wouldn't[1]).


dave

[1] I don't think the sequence point in a function call is enough to keep
the compiler from evaluating the left side of the assignment to decide
where to put the result either, so putting a sequence point at the
tolower call doesn't guarantee that that happens between evaluating
*p and *p++.

 

[Richard Heathfield]

Dave Vandervies said:

tolower is explicitly permitted to be, and typically is, implemented
as a macro that masks the function definition, isn't it?

Such considerations were certainly a factor in my "hang on, er, what
if". But if the choice is between, on the one hand, spending an hour
proving it from the Standard and, on the other, spending a few seconds
saying "don't be silly" and using the rest of the time to cut code,
then it's simply no contest.

 

[Dave Vandervies]

Such considerations were certainly a factor in my "hang on, er, what
if". But if the choice is between, on the one hand, spending an hour
proving it from the Standard and, on the other, spending a few seconds
saying "don't be silly" and using the rest of the time to cut code,
then it's simply no contest.

True. But if the choice is between spending an hour language lawyering or
finding a different way to waste that hour on usenet, language lawyering
wins just as easily as it loses in your scenario.


dave

 

[Old Wolf]

*p++ = tolower(*p));

is this behaviour defined in standards?

The behaviour is undefined because 'p' is modified
and read without an intervening sequence point, and
the read is not for the purpose of determining the
new value of p (in fact, the read is for determining
what to ultimately store at *p).

The sequence points with the function call (if any)
do not necessarily occur between the above 2 events.

 

[Keith Thompson]

True. But if the choice is between spending an hour language lawyering or
finding a different way to waste that hour on usenet, language lawyering
wins just as easily as it loses in your scenario.

For that matter, an hour determining whether you need to make a change
in a large application (with all the overhead an inconvenience that
entails), or determining whether you can reasonably submit a bug
report to a compiler vendor, is likely to be time well spent.

Not that it should take an hour in this case.