Getting a pointer to a variant's data in C

[martijnj]

Hi all,

For my HDF5 bindings project (http://h5labview.sf.net) I'd really like to be able to pass variants in and out of C code and be able to inspect their data for a generic read/write interface. CLNs do accept variants as an "Adapt to Type", which then provides a pointer to the Variant object in C. Since this is an opaque object with no documented interface (that I'm aware of!) there is no clear way to get a pointer to the data it contains.

 

This particularly helpful post states the memory layout of the Variant class, and based on that I can easily extract a pointer to the data I desire. However, since it's only used internally, this layout may change in the future. Since it seems OK for us to know about the internal structure of Variants, wouldn't it be better if we were able to use the functions LvVariantGetDataPtr and LvVariantGetType instead for improved reliability? (if indeed they do what I assume they do). Does anyone have any ideas about this?

 

I should point out I do have working code based on taking "the right offset" in memory, but using such magic numbers make me uneasy.

 

Cheers,

Martijn

[martijnj]

Apparently I was too hasty with my post. Playing around with calling LvVariantGetDataPtr a bit more it seems to work with

uintptr_t LvVariantGetDataPtr(const LvVariant& var);

That is to say, the variant's handle must be dereferenced once before passing the pointer in to the function call. I'll leave this here for future reference in case it's useful or someone wants to point out I'm wrong.

[Rolf Kalbermatter]

Hi all,

I should point out I do have working code based on taking "the right offset" in memory, but using such magic numbers make me uneasy.

 

And it should definitely do make you feel uneasy! Doing that is a guaranteed recipe for disaster somewhere down the road. Even using the undocumented LvVariantGetDataPtr() function and friends is only slightly better for anything that you intend to have used by other people.

 

Since it is undocumented, NI is free to change its prototype, semantics, or discontinue it altogether whenever they decide so. Yes they would have to review several other internal projects to adapt to the new interface which is a hassle and therefore they will think three times about doing that, but it is possible and manageable as they have all the control over every piece that makes legitimate use of this function. Once the function is publicly documented, it is carved in stone for eternity and no changes in any way are really possible anymore.

 

You may understand the implications of using such a function in your code, but if you ever distribute your library to other people they will most likely have no clue at all about the entire C code interface in general and the use of an undocumented LabVIEW API in special and with a new LabVIEW version everything may fall to pieces for them.

 

The proper way to handle this would be to get someone from NI give you a (semi)-official document that does document these functions. If you can manage to get that, then you can be somewhat confident that the LabVIEW team feels fairly safe about this API to be a standard for many versions of LabVIEW to come. It still can break for many reasons in the future, such as modifications to the LabVIEW source code to support new hardware architectures or such, but at least you have some assurance that someone in the knowing believes this is a permanent API.