[omniORB] Re: value type: Marshall error

[Андрей Пучин]

Duncan, explain me plz.

I guess, that 67 is a buffer size, however TAO expects here 68.
Why? TAO needs alignment by 4? Can i force align of that buffer?


47 49 4f 50 01 02 01 00  60 01 00 00 04 00 00 00   GIOP....`.......
03 00 00 00 00 00 00 00  1b 00 00 00 14 01 0f 00   ................
52 53 54 ee d2 3b 43 7e  56 03 00 00 00 00 00 01   RST..;C~V.......
00 00 00 01 00 00 00 74  07 00 00 00 73 65 61 72   .......t....sear
63 68 00 6d 01 00 00 00  01 00 00 00 0c 00 00 00   ch.m............
01 00 00 00 01 00 01 00  09 01 01 00 50 6f 6f 6c   ............Pool
01 00 00 00 00 00 00 00  01 00 00 00 1d 00 00 00   ................
c6 00 00 00 01 96 9e 00  20 00 00 00 49 44 4c 3a   ........ ...IDL:
56 61 6c 75 65 54 65 73  74 2f 51 75 65 72 79 44   ValueTest/QueryD
69 63 74 44 61 74 61 3a  31 2e 30 00 0e 00 00 00   ictData:1.0.....
51 75 65 72 79 44 69 63  74 44 61 74 61 00 00 00   QueryDictData...
00 00 00 00 01 00 00 00  0a 00 00 00 6f 70 65 72   ............oper
61 74 69 6f 6e 00 00 00  11 00 00 00 67 00 00 00   ation.......g...
                                    ^^^^
01 21 34 7c 21 00 00 00  49 44 4c 3a 56 61 6c 75   .!4|!...IDL:Valu
65 54 65 73 74 2f 4c 6f  67 69 63 4f 70 65 72 61   eTest/LogicOpera
74 69 6f 6e 3a 31 2e 30  00 00 00 00 0f 00 00 00   tion:1.0........
4c 6f 67 69 63 4f 70 65  72 61 74 69 6f 6e 00 00   LogicOperation..
03 00 00 00 06 00 00 00  4c 4f 5f 4f 52 00 00 00   ........LO_OR...
07 00 00 00 4c 4f 5f 41  4e 44 00 00 07 00 00 00   ....LO_AND......


Friday, September 30, 2005, 1:58:25 PM, you wrote:

> On Friday 30 September,
> =?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=CF=F3=F7=E8=ED?= wrote:

>> For example for IDL:
>>    typedef any QueryAttributeValue;
>> 
>>    enum LogicOperation {
>>        LO_OR
>>        , LO_AND
>>        , LO_NOT
>>    };
>> 
>>    valuetype QueryDictData {
>>        public LogicOperation operation;
>> 
>>    };
>> 
>>    interface SearchManager {
>>      long search (in QueryAttributeValue search_query);
>>    };
> [...]

> I'll explain the (partial) TypeCode...

>> 49 44 4c 3a 56 61 6c 75  65 54 65 73 74 2f 51 75   IDL:ValueTest/Qu
>> 65 72 79 44 69 63 74 44  61 74 61 3a 31 2e 30 00   eryDictData:1.0.

> This is the repository id. (You cut off the length field.)

>> 0e 00 00 00 51 75 65 72  79 44 69 63 74 44 61 74   ....QueryDictDat
>> 61 00

> This is the valuetype name, with terminating null

>>       00 00 00 00 00 00  01 00 00 00 0a 00 00 00   a...............

> Next comes the ValueModifier. It's a short, so the alignment is
> right without needing any padding. 00 00 is VM_NONE, meaning no value
> modifier.

> Next comes the concrete base TypeCode. The kind is 00 00 00 00,
> i.e. tk_null -- no concrete base.

> Next is count of members, 01 00 00 00 -- i.e. one member.

> Next is start of string for member name.

>> 6f 70 65 72 61 74 69 6f  6e 00 00 00 11 00 00 00   operation.......

> Member name, then pad, then tk_enum (and after that will be the rest of
> the enum TyepCode).

>> but tao client generates:
>> 
>> -->message part skipped
>> 
>> 49 44 4c 3a 56 61 6c 75  65 54 65 73 74 2f 51 75   IDL:ValueTest/Qu
>> 65 72 79 44 69 63 74 44  61 74 61 3a 31 2e 30 00   eryDictData:1.0.
>> 0e 00 00 00 51 75 65 72  79 44 69 63 74 44 61 74   ....QueryDictDat
>> 61 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00   a...............
>         ^^^^^ ^^^^^^^^^^^

> My guess is that TAO is treating the value modifier as a long, not a
> short. That means that the bits I've marked are first some padding, and
> then the modifier as a long.

>> Is this Tao or omni problem?

> I think it's a TAO problem. Have you asked the TAO developers?

> Cheers,

> Duncan.



-- 
Best regards,
 Андрей                            mailto:pouchin at gmail.com