IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This removes tons of warnings
warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
for me. Lots of that kind left though :-)
(This used to be commit ba29219ea243cc217ab3522b036a82ff8dfeedc8)
The memory allocation of embedded "ref" pointers needs to be the
same as for all other embedded pointers.
metze
(This used to be commit 6b3817c2250b94307ffcbd9f8eeb9a593eb7a82d)
Only the first level gets the pointer type from the
pointer property, the others get them from
the pointer_default() interface property
see http://msdn2.microsoft.com/en-us/library/aa378984(VS.85).aspx
(Here they talk about the rightmost pointer, but testing shows
they mean the leftmost pointer.)
metze
(This used to be commit aa8518521b2a6a7110c84c4981c53acce7389ee9)
When we have "*r->out.ous"
(char ***ous, a pointer to a pointer to an array of pointers).
we need to use "(*r->out.ous)[3]" to access the 3rd
element of the array "*r->out.ous[3]" was generated before,
but that's the same as "*(r->out.ous[3])" which would mean
the array would apply to a different level.
This patch prepares support for:
[out,ref,size_is(,num)] [string,charset(UTF16)] uint16 ***names;
It means a [ref] pointer to a [unique] pointer to an array
of [unique] pointers which point to an UTF16 string.
metze
(This used to be commit ec0ee2aa5f4bef32f09a426d91c28c985f843038)
uint32 num;
nstring strings[num];
this should use 'r->strings' instead of
'*r->strings' as the pointer to the array.
metze
(This used to be commit 7c7acae817cd00ab5c915742338b019af79e9193)
8ebf16c0741085fa769fcc2929f275ab49b1ea5d Works!!!...pidl/Samba4::NDR::Parser: fix support for embedded "ref" pointers
6fcf2456d0e81898b5779ef1650f38b4c5363a80 WORKS!!!...pidl/NDR: fix handling of multilevel pointers in function elements
0569139ca2960ec5478829c3e66f7ff69bdb55cd LOOKS OK... pidl: get the pointer types correct when an element has multiple pointe
rs
13afc89a87716063180723f0e9cb4f76daca837e CHECKED... pidl/Samba4::NDR::Parser: correctly get the name of an array element
29c104944bcad30c6a2a3fa70d527bf0ee8969de CHECKED... TODO:MSG pidl/Samba4::NDR::Parser: fix ...
3369015f5d8c425e1a9f9d861471028f03f163bb CHECKED... pidl/Samba4::NDR::Parser: move logic for extra get_pointer_of() into a f
unction
metze
(This used to be commit 0bcc8e53d1470ba9dfe93e5d6925b8f4c20c7c66)
The memory allocation of embedded "ref" pointers needs to be the
same as for all other embedded pointers.
metze
(This used to be commit 8ebf16c0741085fa769fcc2929f275ab49b1ea5d)
Only the first level gets the pointer type from the
pointer property, the others get them from
the pointer_default() interface property
see http://msdn2.microsoft.com/en-us/library/aa378984(VS.85).aspx
(Here they talk about the rightmost pointer, but testing shows
they mean the leftmost pointer.)
metze
(This used to be commit 0569139ca2960ec5478829c3e66f7ff69bdb55cd)
When we have "*r->out.ous"
(char ***ous, a pointer to a pointer to an array).
we need to use "(*r->out.ous)[3]" to access the 3rd
element of the array "*r->out.ous[3]" was generated before,
but that's the same as "*(r->out.ous[3])".
metze
(This used to be commit 13afc89a87716063180723f0e9cb4f76daca837e)
