Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <1892558292.1124460193381.JavaMail.jira@ajax.apache.org>
Date: Fri, 19 Aug 2005 16:03:13 +0200 (CEST)
From: "Adrian Dick (JIRA)" <axis-c-dev@ws.apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Commented: (AXISCPP-788) AXIS C++ allows to set positive
 values to XSD_negativeInteger  type
In-Reply-To: <1500367216.1123498054993.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

    [ http://issues.apache.org/jira/browse/AXISCPP-788?page=3Dcomments#acti=
on_12319381 ]=20

Adrian Dick commented on AXISCPP-788:
-------------------------------------

There seems to be some misunderstanding on what goes on with negativeIntege=
r and nonPositiveInteger.

Within AxisUserAPI.hpp these two types are declared as unsigned LONGLONG  (=
64bit integer), so it isn't possible to provide a signed negative value as =
you will get an unexpectedly large unsigned value( as seen  in case 2. of t=
he original description).  Also, as a result of this, the recently introduc=
ed code in the constructors, below, will fail for all values except 0 (if c=
ompiler treats as signed) or all values over 18446744073709551615  (is comp=
iler treats as unsigned) :
   if(valueToCheck > -1)
       throw AxisSoapException(CLIENT_SOAP_SOAP_CONTENT_ERROR, "PositiveInt=
eger value must be minus one or less");

As I see it, there are two possible fixes:
1)  Improve the API documentation within AxisUserAPI.hpp to make it clear t=
hat xsd__negativeInteger is an unsigned value that is implicitly negative.
2)  Modify xsd__negativeInteger to be a signed LONGLONG, and make some mino=
r modifications to the checks for Max/Min Inclusive/Exclusive (which curren=
tly assume negative unsigned integer).

In either case, the recently introduced checks within the constructor are n=
ot required because this is already carried out within the serialize method=
 (which is invoked as part of the object constructor)
For the second case, we will loose 1/2 our potential value space -- but oth=
ers may not see this as a big issue.

Adrian

> AXIS C++ allows to set positive values to XSD_negativeInteger  type
> -------------------------------------------------------------------
>
>          Key: AXISCPP-788
>          URL: http://issues.apache.org/jira/browse/AXISCPP-788
>      Project: Axis-C++
>         Type: Bug
>     Reporter: Manohar
>     Assignee: Samisa Abeysinghe
>      Fix For: 1.6 Alpha

>
> Axis C++ allows to set positive values for  XSD_negativeInteger dataype. =
As per the XML schema specification, the =C2=B7value space=C2=B7 of negativ=
eInteger is the infinite set {...,-2,-1}  and it's maxInclusive is -1. This=
 means, only negagtive integer values should be allowed and no positive val=
ues. But, I see that positive values can also be set for this datatype. As =
per my observation,
> 1. negativeInteger and nonPositiveInteger types accept positive values   =
( e.g.  +1 is accepted and same value is displayed after serialze/deseriali=
zed)
> 2. positiveInteger and nonNegativeInteger types accept negative values ( =
e.g.  -1 is accepted and 18446744073709551615 value is displayed after=20
>      serialze/deserialized)
> I think this is not the correct behaviour. Though these XML datatypes are=
 mapped to different datatypes of client programming languages (C/C++ in ou=
r case), this should not be allowed while serializing/deserializing in the =
client product and some exception should be reported indicating the error. =
I see the whole purpose of a datatype is lost when  a +ve value is set for =
a negativeInteger type and vice versa.
> Testcases written for these types ( XSD_negativeIntegerClient.cpp, XSD_no=
nPositiveIntegerClient.cpp, XSD_positiveIntegerClient.cpp and XSD_nonNegati=
veIntegerClient.cpp)  show this problem.=20
> Regards
> Manohar.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira