FiveTech Support Forums

Buenas a todos.
A ver si alguien sabe decirme como acceder a la estructura interna de HB_ITEM en Harbour (no en xHarbour).
Concrétamente quiero acceder a la dirección de:
myItem->item.asString.length // OJO, no al valor si no a la dirección.

Como ejemplo:
myItem->item.asString.value;

puedo acceder así:
char * miPuntero = myItem->item.asString.value;
o con la función:
char * miPuntero = hb_itemGetCPtr( myItem ); // Esta es la aconsejable

Pero para myItem->item.asString.length, cómo?
Hay alguna función que haga lo mismo que hb_itemGetCPtr( myIyem ) pero para myItem->item.asString.length?

Muchas gracias Daniel...
Quería evitar eso precisamente.

si existiera una función que devolviera la dirección sería lo ideal para mí:

...
return &miPuntero->item.asString.length;

Se te ocurre algo?

Ya Daniel, pero lo que quiero es evitar usar la estructura ITEM.
Lo que quiero es usar una función al estilo hb_itemGetCPtr( myItem ) pero para el puntero a myItem->item.asString.length ya así mo tener que ir en contra de las recomendaciones del equipo de Harbour.

Mira:
//--------------------------------------
HB_SIZE hb_itemGetCLen( PHB_ITEM pItem )
{
HB_TRACE( HB_TR_DEBUG, ( "hb_itemGetCLen(%p)", pItem ) );

if( pItem && HB_IS_STRING( pItem ) )
return pItem->item.asString.length;
else
return 0;
}

//--------------------------------------
Pues en vez de eso me gustaria que en las funciones del ITEM API hubiera una que devuelva el puntero y no el valor. Así no tendría que usar la directiva no recomendada HB_API_INTERNAL

long * hb_itemGetCPtrLen( PHB_ITEM pItem )
{
if( pItem && HB_IS_STRING( pItem ) )
return &pItem->item.asString.length;
else
return NULL;
}

//--------------------------------------

Olvidate Daniel.
Escribí a Przemek y me ha dado una amplia explicación de porqué no está ni estará

Manuel

por curiosidad cual es la explicacion que te dieron?

Jajaja te pica la curiosidad no?

Te la transcribo tal cual, ya sabes que Przemek se esplaya:

There are few serious problems with such function.
It operates on pointer to item body which may change if some
other code change the item value. In such case modifying the
value at pointer address will corrupt new item and maybe HVM
HVM expect that all strings are CHR(0) ended in many different
places. Strings without this condition may cause HVM crash.
But if you try to update string body then it may corrupt many
other string items two. String items are shared and copy on write
mechanism is used. If you change one string then you will also
change all other string items which share item value. You cannot
change string item body or string item length because it may
effect more then one item. In the worst case you will overwrite
one of internal buffers used for shared string values changing
all strings which may store such value even if they will be
created in the future, i.e. all one byte strings are pointers
to execatly the same memory area. Constant strings are pointers
to PCODE so if you change them then PCODE is changed too and
will give different results executed next time.
Additionally if you try to write to static readonly buffer on
systems with hardware readonly memory protection it will cuase
GPF. There are also any other bad side effects.
I cannot imagine where such function can be safely used without
risk of internal HVM corruption. IMHO you should rethink what
you are trying to do and how to avoid manipulations in HVM
intenral area.

best regards,
Przemek