| |
Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • ShopThe Open Brand -- Problem Reporting and Interpretations System |
|
Problem Report 1793 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 1793.
Report 1793 Actions
Problem Report Number 1793 Submitter's Classification Test Suite problem State Resolved Resolution Test Suite Deficiency (TSD) Problem Resolution ID TSD.X.0870 Raised 1970-01-01 08:00 Updated 2003-03-13 08:00 Published 1998-07-27 08:00 Product Standard X Window System Applications Interface Certification Program The Open Brand certification program Test Suite VSW version 5.0.1 Test Identification Xlib7/XAllocNamedColor 4 Problem Summary TSD4W.00156 This test may fail because of an undefined behavior in ANSI C usage. Problem Text
A previous request for waiver on this same issue called: PG4W.00089
was refused by X/Open. We are appealing this refusal by issuing a
new request for waiver along with our reasons why the refusal was
a mis-interpretation of the ANSI C language specification.
This test case [file: tset/Xlib7/allcnmdclr/allcnmdclr.m]
initializes the character string 'goodname' with XT_GOOD_COLORNAME
from the configuration file. It copies 'goodname' to the character
array 'casename' and then it modifies the string in casename, so
that casename uses lower and upper case characters alternating. The
modification is done around line 322 of the file allcnmdclr.m:
casename = (char *) malloc( strlen(goodname) + 1);
strcpy(casename, goodname);
for(i=0, cp=casename; *cp; i++)
if(i&1)
*cp++ = tolower(*cp);
else
*cp++ = toupper(*cp);
Due to the ANSI standard X3.159-1989 for the C programming language,
chapter 3.3 "Expressions" the order of evaluation for the expressions
in the lines
*cp++ = tolower(*cp);
or
*cp++ = toupper(*cp);
is undefined. Therefore a ANSI C compliant C compiler is allowed
to generate code that modifies the color name "red" to the
string "Ed". This happens with our C compiler. Due to the fact that
a following XAllocNamedColor for the color name "Ed" fails, this test
case fails also. The test case passes if the code in the test case is
modified as follows:
casename = (char *) malloc( strlen(goodname) + 1);
strcpy(casename, goodname);
for(i=0, cp=casename; *cp; i++, cp++)
if(i&1)
*cp = tolower(*cp);
else
*cp = toupper(*cp);
We view this as non ANSI C conformant programming and therefore we
think that this is a problem of the test case.
In addition, if the argument is that this *is* ANSI C conforming
coding because of the below mis-interpretation of the C standard,
then see the below response to this mis-interpretation following what
we think is a mis-interpretation of the standard:
We think the following is a mis-intrepretation
==============================================
ANSI C states in section 6.3.16.1 in the Semantics section for =,
In simple assignment (=), the value of the right operand is
converted to the type of the assignment expression and
replaces the value stored in the object designated by the left
operand.
For the postfix ++ operator, the standard states in 6.3.2.4 in the
Semantics section,
The result of the postfix ++ operator is value of the operand.
After the result is obtained, the value of the operand is
incremented.
This says that the right operand is evaluated before the left
operand is evaluated, and the assignment is done on the old
location and used before it is incremented.
Our response to the above mis-interpretation of the C standard:
===============================================================
We have polled several C committee members about this issue and
have gotten all the same consenus. That is, the above mention C
construct produces undefined results.
Below are such quoted responses from a C committee members which
support our contention that the C contruct produces undefined
results.
Quote #1
========
X/Open is wrong: there is no requirement to evaluate the
left hand side of an assignment before the right hand side.
X/Open is reading between the lines to take words in the
Standard:
"In simple assignment (=), the value of the right operand
is converted to the type of the assignment expression and
replaces the value storedin the object designated by the
left operand."
as requiring that the right operand be evaluated before the left
operand. However, those words say nothing about the evaluation
order of the left and right operands or the timing of side
effects.
If X/Open's reading was legitimate, then the Standard also
requires the right operand of subtraction be evaluated before
the left operand:
"The result of the binary - operator is the difference
resulting from the subtraction of the second operand from
the first." (Paragraph 6 of 6.5.6)
A careful reading of 5.1.2.3 and 6.5 clearly shows that side
effects merely have to complete by the end of the sequence
point that contains them, and must not occur before the sequence
point that contains them.
Any program that relies on the ordering of side effects within a
sequence point is not strictly conforming.
Quote #2
========
X/Open seems to be assuming that since you must have evaluated
the RHS to assign anything into the LHS, you can't even look at
the LHS before you do everything on the RHS.
Quote #3
========
This has been a FAQ for a long time.
In fact, you might want to point them to the comp.lang.c FAQ at:
http://www.eskimo.com/~scs/C-faq/top.html -- Question 3.1
addresses exactly this point, although it has the increment on
the right hand side rather than the left.
Test Output
In addition to the test case: XAllocNamedColor #4 failure, there
are the following failures which fail the same way:
XLookupColor, test purpse #2, and XStoreNamedColor, test purpose #3.
The below output for XAllocNamedColor #4:
=========================================
TEST PURPOSE #4
Assertion XAllocNamedColor-4.(A)
Upper and lower case characters in the color_name argument refer to the same colour.
METH: For each supported visual type:
METH: Create a colomap with alloc set to AllocNone.
METH: Allocate a read/only cell with colour name XT_GOOD_COLORNAME
METH: in the colourmap with XAllocNamedColor.
METH: Allocate a read/only cell with colour name XT_GOOD_COLORNAME,
METH: with alternate characters in alternating case,
METH: in the colourmap with XAllocNamedColor.
METH: Verify that the function returned non-zero.
METH: Verify that the exact and closest supported rbg values from both calls
METH: are identical.
METH: Verify that the pixel value of the cell allocated by both calls
METH: is the same.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
REPORT: XAllocNamedColor failed to return non-zero with color Ed.
FAIL
The below output for XLookupColor #2:
=====================================
VSW5TESTSUITE PURPOSE 2
Assertion XLookupColor-2.(A)
Upper and lower case characters in the color_name argument refer to the same colour.
METH: For each supported visual type:
METH: Create a colomap with alloc set to AllocNone.
METH: Look up the rgb value of the colour name XT_GOOD_COLORNAME
METH: in the database with XLookupNamedColor.
METH: Look up the rbg value of the colour name XT_GOOD_COLORNAME,
METH: with alternating characters in alternating case,
METH: in the colourmap with XAllocNamedColor.
METH: Verify that the function returned non-zero.
METH: Verify that the exact and closest supported rbg values from both calls
METH: are identical.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
REPORT: XLookupColor failed to return non-zero with color Ed.
FAIL
The below output for XAllocNamedColor #3:
=========================================
VSW5TESTSUITE PURPOSE 3
Assertion XStoreNamedColor-3.(A)
If any of the visual classes DirectColor, PseudoColor or
GrayScale is supported: Upper and lower case characters in
the color argument refer to the same color.
METH: For each supported visual class:
METH: Create a colomap with alloc set to AllocAll.
METH: Store colour XT_GOOD_COLOR_NAME in the colourmap
with XStoreNamedColor.
METH: Obtain the stored rgb values with XQueryColor,
METH: Store colour XT_GOOD_COLOR_NAME with alternating characters in alternating case with XStoreNamedColor.
METH: Verify that the rgb values written by both calls was identical.
REPORT: Got BadName, Expecting Success
REPORT: Got BadName, Expecting Success
REPORT: Got BadName, Expecting Success
REPORT: Got BadName, Expecting Success
REPORT: Got BadName, Expecting Success
FAIL
Review Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
We agree this is a test suite deficiency in the test
suite version(s) listed.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Test Suite Deficiency (TSD) Review Conclusion
This is an agreed Test Suite Deficiency.
Problem Reporting System Options:
- View Report 1793
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority