That seems to be all that's needed - for any HANDLEs I've passed around, at least.

Yes. I've done that too. The problem that arose was that if I did anything to the value in Perl that caused perl to look at it as anything other than an unsigned integer, and by the time that value got back to the C code it could be corrupted.

From memory, the first time was a quick debug statement something like:

print 'Before call: '. $handle;

[download]

Notice the accidental '.' instead of ','. That caused the handle to be converted to the string representation of itself, and by the time it got back to the c code and was converted back from string to number, it was corrupted.

I forget the exact details -- it was a while ago -- but from memory, the (32-bit) unsigned value was greater 2**31-1, so the default string representation took on a minus sign. When converting back it went through a signed integer before being cast to an unsigned integer and that screwed it.

Another problem is portability. In 32-bit, void* is a 32-bit unsigned integer; On 64-bit, a 64-bit value.

And cross-platform, aren't unsigned long different sizes on 64-bit *nix and Windows? (Or is that the long long type.) See this from wikipedia:

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, OS X, BSD, and IBM z/OS native compilers). Microsoft's Visual C++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code, but code is often written with implicit assumptions about the widths of integer types.

And then there is the (somewhat cockeyed) reasoning MS use the "opaque" void * for things that are not pointers.

In general, I've found it best to (try to) keep values that originate from C/system libraries, well clear of anywhere Perl can try and manipulate them. Because whilst it works 99% of the time; tracking down the 1% is hell on earth :)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Re^5: Using Inline::C in a package by BrowserUk
in thread Using Inline::C in a package by rem45acp

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.