[
https://issues.apache.org/jira/browse/AXIS2C-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565424#action_12565424
]
senakafdo edited comment on AXIS2C-919 at 2/4/08 9:31 AM:
----------------------------------------------------------------
Fixed Issue in util. Raised another issue, AXIS2C-964 for getting this done at
WSDL2C level. Thanks, Frank for the input.
Regards,
Senaka
was (Author: senakafdo):
Fixed Issue in util. Raised another issue, AXIS2C-964 for getting this done
at WSDL2C level.
> primitive types - long vs. int64_t
> ----------------------------------
>
> Key: AXIS2C-919
> URL: https://issues.apache.org/jira/browse/AXIS2C-919
> Project: Axis2-C
> Issue Type: Improvement
> Components: wsdl2c tool
> Affects Versions: Current (Nightly)
> Reporter: Frank Huebbers
> Assignee: Senaka Fernando
>
> I'm running into a problem with Axis2/C regarding the primitive types used in
> certain situations, especially when using Axis2/C cross platform and cross
> implementation. Specifically, I have several primitive types which are longs
> to represent values in excess of 2GB. This works fine on C# and Java (which
> we are using on our platforms). However, on C++ compiled on a WinXP 32-bit
> system, the long type is only 4 bytes long (as the int type) and thus not
> sufficient to represent large numbers.
> The way I have gotten around this problem while keeping cross-platform
> compatibility in mind are the following defines:
> #if defined(_WINDOWS)
> // Windows doesn't have any of the standard ANSI size invariant
> // Ansi types
> typedef unsigned __int8 uint8_t;
> typedef __int8 int8_t;
> typedef unsigned __int16 uint16_t;
> typedef __int16 int16_t;
> typedef unsigned __int32 uint32_t;
> typedef __int32 int32_t;
> typedef unsigned __int64 uint64_t;
> typedef __int64 int64_t;
> #else
> // Non Windows platforms should have this header file, which should
> // give access to the ansi types like uint8_t etc.
> #include <stdint.h>
> #endif // !_WINDOWS
> Is it possible to use these ansi types instead of types which will invariably
> truncate very large numbers, such as longs? I would consider this to be a
> very important improvement to the generated code.
> Any further comments are highly appreciated.
> Cheers,
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
