HP/UX Itanium C comiler & std C

[Sion Roberts]

While porting our application to HP/UX 11.23 Itanium, I came across
this situation where the compiler acts differently to any other UNIX
C/C++ compiler that I have come across in the last 10 years (including
other HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

On Itanium it displays:

Answer is AB

There are a few HPUX compilers to choose from on this platform, but
they all behave in the same way. Compiler switches don't make any
difference. I am now using GCC, which works as I expect.

aCC on HPUX 11 PA-RISC also displays "AB".

Has anyone come across this before or confirm that the results I've
seen are invalid for ANSI C?

Sion.

[Mark A. Odell]

sr******@transoft.com (Sion Roberts) wrote in
news:ae**************************@posting.google.c om:

While porting our application to HP/UX 11.23 Itanium, I came across
this situation where the compiler acts differently to any other UNIX
C/C++ compiler that I have come across in the last 10 years (including
other HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B
No, not unless you used %c instead of %s.
On Itanium it displays:

Answer is AB

This is correct. Strings are null terminated. The char 'B' is not '\0'
thus it gets printed along with 'A'.

--
- Mark ->
--

[Kenny McCormack]

In article <Xn********************************@130.133.1.4> ,
Mark A. Odell <od*******@hotmail.com> wrote:

sr******@transoft.com (Sion Roberts) wrote in
news:ae**************************@posting.google. com:

While porting our application to HP/UX 11.23 Itanium, I came across
this situation where the compiler acts differently to any other UNIX
C/C++ compiler that I have come across in the last 10 years (including
other HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

No, not unless you used %c instead of %s.

Um, %c would print the lowest 8 bits of the pointer value stored in "ans",
as an ASCII character (on most machines - obviously O/T, of course...)

On Itanium it displays:

Answer is AB

This is correct. Strings are null terminated. The char 'B' is not '\0'
thus it gets printed along with 'A'.

The idea of the above is that in:

ans = (*ptr++) ? ptr : "";

"ptr" is "supposed" to be incremented after it is tested but before its
value is fetched and assigned to "ans". The pedants in this group will
probably point out that this behavior is not required by "the standard".

[Lawrence Kirby]

On Mon, 15 Nov 2004 05:16:00 -0800, Sion Roberts wrote:

While porting our application to HP/UX 11.23 Itanium, I came across this
situation where the compiler acts differently to any other UNIX C/C++
compiler that I have come across in the last 10 years (including other
HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B
Correct, the ?: operator defines a sequence point after its first operand
is evaluated. Therefore the side-effect of incrementing ptr must be
complete before the value of ptr is read for the second operand (which it
is because *ptr++ is 'A' which is not null). So a pointer to the 2nd
character in the string should be assigned to ans.
On Itanium it displays:

Answer is AB

Looks like you've found a bona fide compiler bug.

Lawrence

[pete]

Mark A. Odell wrote:

sr******@transoft.com (Sion Roberts) wrote in
news:ae**************************@posting.google.c om:

While porting our application to HP/UX 11.23 Itanium, I came across
this situation where the compiler acts differently to any other UNIX
C/C++ compiler that I have come across in the last 10 years (including
other HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

No, not unless you used %c instead of %s.

Answer is B.
ans points to a string regardless of whether it points
to the first or second element of "AB".

--
pete

[Bjørn Augestad]

Lawrence Kirby wrote:

On Mon, 15 Nov 2004 05:16:00 -0800, Sion Roberts wrote:

While porting our application to HP/UX 11.23 Itanium, I came across this
situation where the compiler acts differently to any other UNIX C/C++
compiler that I have come across in the last 10 years (including other
HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

Correct, the ?: operator defines a sequence point after its first operand
is evaluated. Therefore the side-effect of incrementing ptr must be
complete before the value of ptr is read for the second operand (which it
is because *ptr++ is 'A' which is not null). So a pointer to the 2nd
character in the string should be assigned to ans.

Can someone please clarify what is meant by this text, from C99 §6.5.15
Conditional operator, #4.

"If an attempt is made to modify the result of a conditional operator or
to access it after the next sequence point, the behavior is undefined".

Does the "access it" part apply to the OP's code or am I just
misinterpreting the standard?

TIA
Bjørn

[snip]

[pete]

Bjørn Augestad wrote:

Lawrence Kirby wrote:

On Mon, 15 Nov 2004 05:16:00 -0800, Sion Roberts wrote:

While porting our application to HP/UX 11.23 Itanium, I came across this
situation where the compiler acts differently to any other UNIX C/C++
compiler that I have come across in the last 10 years (including other
HP-UX platforms).

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

Correct, the ?: operator defines a sequence point after its first operand
is evaluated. Therefore the side-effect of incrementing ptr must be
complete before the value of ptr is read for the second operand (which it
is because *ptr++ is 'A' which is not null). So a pointer to the 2nd
character in the string should be assigned to ans.

Can someone please clarify what is meant by this text, from C99 §6.5.15
Conditional operator, #4.

"If an attempt is made to modify the result of a conditional
operator

I think it means that (a ? b : c) is an rvalue
and that you can't do something like this: ((a ? b : c)++)
or to access it after the next sequence point,
the behavior is undefined".
Does the "access it" part apply to the OP's code or am I just
misinterpreting the standard?

I don't know what that means.

--
pete

[Richard Tobin]

In article <cn**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

The idea of the above is that in:

ans = (*ptr++) ? ptr : "";

"ptr" is "supposed" to be incremented after it is tested but before its
value is fetched and assigned to "ans". The pedants in this group will
probably point out that this behavior is not required by "the standard".

No. The standard says there is a sequence point after the first operand
of the ? operator.

-- Richard

[Lawrence Kirby]

On Mon, 15 Nov 2004 14:41:45 +0000, pete wrote:

Bjørn Augestad wrote:

Lawrence Kirby wrote:

> On Mon, 15 Nov 2004 05:16:00 -0800, Sion Roberts wrote:
>
>
>>While porting our application to HP/UX 11.23 Itanium, I came across this
>>situation where the compiler acts differently to any other UNIX C/C++
>>compiler that I have come across in the last 10 years (including other
>>HP-UX platforms).
>>
>>Consider the following code:
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>> char *ptr = "AB";
>> char *ans;
>>
>> ans = (*ptr++) ? ptr : "";
>>
>> printf ("Answer is %s\n", ans);
>>
>> return 0;
>> }
>>
>>When running this, I would usually expect to see:
>>
>> Answer is B
>
>
> Correct, the ?: operator defines a sequence point after its first operand
> is evaluated. Therefore the side-effect of incrementing ptr must be
> complete before the value of ptr is read for the second operand (which it
> is because *ptr++ is 'A' which is not null). So a pointer to the 2nd
> character in the string should be assigned to ans.

Can someone please clarify what is meant by this text, from C99 §6.5.15
Conditional operator, #4.

(rearranged to bring the standard text together)
"If an attempt is made to modify the result of a conditional
operator or to access it after the next sequence point,
the behavior is undefined".

I think it means that (a ? b : c) is an rvalue
and that you can't do something like this: ((a ? b : c)++)

That is true but I don't think it is what the text is for, because that is
caught by a constraint violation for ++ i.e. its operand must be a
modifiable lvalue. A constraint violation is the more significant error,
if you have a CV then further undefined behaviour is not an issue.

I'm wondering if this has something to do with "rvalue" structures e.g.

struct foo { int bar; } s1 = { 1 }, s2 = { 2 };

(expr ? s1 : s2).bar

but I haven't come up with an example that triggers undefined behaviour
from 6.5.15p4 and doesn't trip up elsewhere in the standard. That sentence
is an addition from C90, so either they spotted a case that hadn't been
spotted at the time of C90 or this has something to do with new C99
features.

Does the "access it" part apply to the OP's code or am I just
misinterpreting the standard?

I don't know what that means.

The standard talks about modifying the RESULT of the conditional
operator or accessing after the next sequence point, which the OPs code
does not do.

Lawrence

[Mark A. Odell]

"Mark A. Odell" <od*******@hotmail.com> wrote in
news:Xn********************************@130.133.1. 4:

Consider the following code:

#include <stdio.h>

int main()
{
char *ptr = "AB";
char *ans;

ans = (*ptr++) ? ptr : "";

printf ("Answer is %s\n", ans);

return 0;
}

When running this, I would usually expect to see:

Answer is B

No, not unless you used %c instead of %s.

Ignore me. I missed the increment on 'ptr' and the lack of dereference on
'ans'.

--
- Mark ->
--

[Dennis Handly]

Richard Tobin (ri*****@cogsci.ed.ac.uk) wrote:
: In article <cn**********@yin.interaccess.com>,
: Kenny McCormack <ga*****@interaccess.com> wrote:
: >The idea of the above is that in:
: > ans = (*ptr++) ? ptr : "";
: >
: >"ptr" is "supposed" to be incremented after it is tested but before its
: >value is fetched and assigned to "ans". The pedants in this group will
: >probably point out that this behavior is not required by "the standard".

: No. The standard says there is a sequence point after the first operand
: of the ? operator.
: -- Richard

Right, we finally saw that too. This is CR JAGae79312:
Incorrect order of evaluation for: (x++) ? x ...

This is fixed in A.05.57:
http://h21007.www2.hp.com/dspp/tech/...3,1743,00.html

[Christian Bau]

In article <cn**********@yin.interaccess.com>,
ga*****@yin.interaccess.com (Kenny McCormack) wrote:

The idea of the above is that in:

ans = (*ptr++) ? ptr : "";

"ptr" is "supposed" to be incremented after it is tested but before its
value is fetched and assigned to "ans". The pedants in this group will
probably point out that this behavior is not required by "the standard".

Only pedants who don't know C. Those who know C will replace "supposed"
with "required" and remove the quotes:

"ptr" is absolutely, one hundred percent required to be incremented
after it is tested but before its value is fetched and assigned to
"ans".

[Kenny McCormack]

In article <ch*********************************@slb-newsm1.svr.pol.co.uk>,
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

In article <cn**********@yin.interaccess.com>,
ga*****@yin.interaccess.com (Kenny McCormack) wrote:

The idea of the above is that in:

ans = (*ptr++) ? ptr : "";

"ptr" is "supposed" to be incremented after it is tested but before its
value is fetched and assigned to "ans". The pedants in this group will
probably point out that this behavior is not required by "the standard".

Only pedants who don't know C. Those who know C will replace "supposed"
with "required" and remove the quotes:

"ptr" is absolutely, one hundred percent required to be incremented
after it is tested but before its value is fetched and assigned to
"ans".

Well, that is good to know. Always nice to hear of instances where
sensible behavior is required by the standard.

[pete]

Lawrence Kirby wrote:

>>Consider the following code:
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>> char *ptr = "AB";
>> char *ans;
>>
>> ans = (*ptr++) ? ptr : "";
>>
>> printf ("Answer is %s\n", ans);
>>
>> return 0;
>> } "If an attempt is made to modify the result of a conditional
operator or to access it after the next sequence point,
the behavior is undefined". Does the "access it" part apply to the OP's code or am I just
misinterpreting the standard?

I don't know what that means.

The standard talks about modifying the RESULT of the conditional
operator or accessing after the next sequence point,
which the OPs code does not do.

I still don't understand.
Would you please change the code in the above program to something
which does attempt to access the result of the conditional
operator after the next sequence point,
to better illustrate what you and the standard are talking about?

--
pete

[pete]

Christian Bau wrote:

ans = (*ptr++) ? ptr : "";

"ptr" is absolutely, one hundred percent required to be incremented
after it is tested but before its value is fetched and assigned to
"ans".

I don't see ptr being tested.
*ptr++ is tested.
ptr may be incremented before the test instead of after.
It is the result of the postfix increment operation
which is the operand of the indirection operator. *(ptr++)

--
pete

[Christian Bau]

In article <41***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

Lawrence Kirby wrote:

> >>Consider the following code:
> >>
> >> #include <stdio.h>
> >>
> >> int main()
> >> {
> >> char *ptr = "AB";
> >> char *ans;
> >>
> >> ans = (*ptr++) ? ptr : "";
> >>
> >> printf ("Answer is %s\n", ans);
> >>
> >> return 0;
> >> } "If an attempt is made to modify the result of a conditional
> operator or to access it after the next sequence point,
> the behavior is undefined". Does the "access it" part apply to the OP's code or am I just
> misinterpreting the standard?

I don't know what that means.

The standard talks about modifying the RESULT of the conditional
operator or accessing after the next sequence point,
which the OPs code does not do.

I still don't understand.
Would you please change the code in the above program to something
which does attempt to access the result of the conditional
operator after the next sequence point,
to better illustrate what you and the standard are talking about?

It is a very obscure thing, and difficult to write code that actually
creates the situation. Something like this:

typedef struct { int x; int a [2]; } mystruct;
static mystruct r, s;
static int i;

(i > 0 ? r : s).a [1] = 0;

The result of the ?: is some object, but not one of the objects r, s: It
is an unnamed object which contains either a copy of r or a copy of s.
Modifying that unnamed object invokes undefined behavior. You may have
to do some more work to make this compile.

[Sion Roberts]

dh*****@convex.hp.com (Dennis Handly) wrote in message news:<41********@usenet01.boi.hp.com>...

Richard Tobin (ri*****@cogsci.ed.ac.uk) wrote:
: In article <cn**********@yin.interaccess.com>,
: Kenny McCormack <ga*****@interaccess.com> wrote:
: >The idea of the above is that in:
: > ans = (*ptr++) ? ptr : "";
: >
: >"ptr" is "supposed" to be incremented after it is tested but before its
: >value is fetched and assigned to "ans". The pedants in this group will
: >probably point out that this behavior is not required by "the standard".

: No. The standard says there is a sequence point after the first operand
: of the ? operator.
: -- Richard

Right, we finally saw that too. This is CR JAGae79312:
Incorrect order of evaluation for: (x++) ? x ...

This is fixed in A.05.57:
http://h21007.www2.hp.com/dspp/tech/...3,1743,00.html

Dennis,

Thank you for this information. This is exactly what I wanted to know.

Sion.

[Lawrence Kirby]

On Tue, 16 Nov 2004 02:32:39 +0000, pete wrote:

Christian Bau wrote:

> ans = (*ptr++) ? ptr : "";

"ptr" is absolutely, one hundred percent required to be incremented
after it is tested but before its value is fetched and assigned to
"ans".

I don't see ptr being tested.

True, although its value is used in the text expression.
*ptr++ is tested.
True
ptr may be incremented before the test instead of after.
True
It is the result of the postfix increment operation
which is the operand of the indirection operator. *(ptr++)

True, and the result of that operation is the unincremented value of ptr.
But you are correct that this doesn't stop the ptr object having an
incremented value written to it first.

Lawrence

[Charlie Gordon]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

It is a very obscure thing, and difficult to write code that actually
creates the situation. Something like this:

typedef struct { int x; int a [2]; } mystruct;
static mystruct r, s;
static int i;

(i > 0 ? r : s).a [1] = 0;

The result of the ?: is some object, but not one of the objects r, s: It
is an unnamed object which contains either a copy of r or a copy of s.
Modifying that unnamed object invokes undefined behavior. You may have
to do some more work to make this compile.

I guess the "proper" way to achieve this would be :

(i > 0 ? &r : &s)->a[1] = 0;

Are we dealing with the same issue in the code :

(ignore_case ? strcasecmp : strcmp) (s1, s2);

assuming proper declaration of strcasecmp.

How should it be written then ?

Chqrlie.

PS: I put emphasis around proper to express that standard compliant does not
necessarily mean readable and advisable.

[pete]

Christian Bau wrote:

In article <41***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

Lawrence Kirby wrote:

>> >>Consider the following code:
>> >>
>> >> #include <stdio.h>
>> >>
>> >> int main()
>> >> {
>> >> char *ptr = "AB";
>> >> char *ans;
>> >>
>> >> ans = (*ptr++) ? ptr : "";
>> >>
>> >> printf ("Answer is %s\n", ans);
>> >>
>> >> return 0;
>> >> }

>> "If an attempt is made to modify the result of a conditional
>> operator or to access it after the next sequence point,
>> the behavior is undefined".

>> Does the "access it" part apply to the OP's code or am I just
>> misinterpreting the standard?
>
> I don't know what that means.

The standard talks about modifying the RESULT of the conditional
operator or accessing after the next sequence point,
which the OPs code does not do.

I still don't understand.
Would you please change the code in the above program to something
which does attempt to access the result of the conditional
operator after the next sequence point,
to better illustrate what you and the standard are talking about?

It is a very obscure thing, and difficult to write code that actually
creates the situation. Something like this:

typedef struct { int x; int a [2]; } mystruct;
static mystruct r, s;
static int i;

(i > 0 ? r : s).a [1] = 0;

The result of the ?: is some object,
but not one of the objects r, s: It
is an unnamed object which contains either a copy of r or a copy of s.
Modifying that unnamed object invokes undefined behavior. You may have
to do some more work to make this compile.

Thank you.

--
pete

[Dan Pop]

In <cn**********@reader1.imaginet.fr> "Charlie Gordon" <ne**@chqrlie.org> writes:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

It is a very obscure thing, and difficult to write code that actually
creates the situation. Something like this:

typedef struct { int x; int a [2]; } mystruct;
static mystruct r, s;
static int i;

(i > 0 ? r : s).a [1] = 0;

The result of the ?: is some object, but not one of the objects r, s: It
is an unnamed object which contains either a copy of r or a copy of s.
Modifying that unnamed object invokes undefined behavior. You may have
to do some more work to make this compile.
I guess the "proper" way to achieve this would be :

(i > 0 ? &r : &s)->a[1] = 0;

Are we dealing with the same issue in the code :

(ignore_case ? strcasecmp : strcmp) (s1, s2);

assuming proper declaration of strcasecmp.

Nope. You're not attempting to modify the result of the conditional
operator.
How should it be written then ?

Apart from stylistic issues, your version is correct. In real code,
you may want to either use a function pointer (if ignore_case doesn't
change its value in "random" places during normal program execution)
or to hide the conditional operator behind a macro (if it does).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union