http://qs1969.pair.com?node_id=1180092


in reply to Is this a sane/safe way to pass an aref into a C function?

I don't see anything particularly wrong with your approach, but I have a few thoughts:

  1. buf[i] = (int)SvNV(*elem);

    buf[] is define as unsigned char, but you're retrieving reals, and casting them to signed ints?

  2. If you are going to pass in an array of ints or reals, you should really check they will fit into an unsigned char or cast appropriately to ensure they will.

    Maybe that should be buf[i] = (unsigned char)SvNV(*elem); or even buf[i] = (unsigned char)SvUV(*elem);

  3. I'll be passing the char buffer and len to an external C function.

    Perl's string scalars can hold any unsigned char value, and carry their length, so why not just pass the pointer and length from a scalar argument?

    That way you cannot be passed out of range values so don't have to deal with them.


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". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Is this a sane/safe way to pass an aref into a C function?
by stevieb (Canon) on Jan 21, 2017 at 22:49 UTC

    Hey BrowserUK, thanks for responding.

    1) I was casting to int because it was what I had the first time it worked, and hadn't yet done further testing (disclaimer: I am literally learning C as I go through this process).

    2) Yep, I have full intention to ensure that each 'byte' will be < 256 && > -1 or so to speak (ie. a proper uint8_t). This is a piece of a much larger scenario, where I'll be tearing apart the bits and manipulating and in many cases ensuring each bit range is within proper bounds (ie.,eg: are bits 5-4 set correctly) and my lack of understanding of a few things likely had me leave out some items. There will be added checks for everything, but I tried to keep the sample small.

    3) See this node for the why. Again, I'm just coming into the C/XS/bitwise world, so I may not be explaining myself correctly. Essentially, that node shares that I'm working on something where I need a dynamic number of bytes incoming, without having to change the underlying C code, specifically because in some cases, I'll just want to pass the data straight through, other times, I'll need/want to perform bitwise operations on it.

    Really, I summarized this thread into a single problem, where maybe I should have explained it for what it was... looking for a solution to two separate issues while taking up as little time of others as possible ;)

      I need a dynamic number of bytes incoming, without having to change the underlying C code,

      I'm not quite sure why you think you cannot pass variable length strings in scalars?

      Also, whilst pack is one way to encode unsigned bytes into strings, it is not the only way:

      #! perl -slw use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => '_1180095', CLEAN_AFTER_BUILD =>0; int doStuff( SV *sv ) { STRLEN len, i; unsigned char *bytes = SvPVx( sv, len ); printf( "%d : ", len ); // print the hi & lo nybbles, of the unsigned bytes passed, in hex for( i=0; i < len; ++i ) { printf( "%01x %01x\t", ( bytes[ i ] & 0xf0 ) >> 4, bytes[ i ] +& 0x0f ); } printf( "\n" ); return 1; } END_C doStuff( "\x0f\xf0\xaa\x55\x01\x80" ); doStuff( join '', map chr, 0x00 .. 0xff ); doStuff( pack 'C*', 1 .. 10 );

      Output:

      C:\test>1180095.pl 6 : 0 f f 0 a a 5 5 0 1 8 0 256 : 0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 + 0 8 0 9 0 a 0 b 0 c 0 d 0 e 0 f 1 0 + 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 +1 9 1 a 1 b 1 c 1 d 1 e 1 f 2 0 2 1 + 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 2 +a 2 b 2 c 2 d 2 e 2 f 3 0 3 1 3 2 + 3 3 3 4 3 5 3 6 3 7 3 8 3 9 3 a 3 b + 3 c 3 d 3 e 3 f 4 0 4 1 4 2 4 3 4 + 4 4 5 4 6 4 7 4 8 4 9 4 a 4 b 4 c + 4 d 4 e 4 f 5 0 5 1 5 2 5 3 5 4 5 5 + 5 6 5 7 5 8 5 9 5 a 5 b 5 c 5 d +5 e 5 f 6 0 6 1 6 2 6 3 6 4 6 5 6 6 + 6 7 6 8 6 9 6 a 6 b 6 c 6 d 6 e 6 +f 7 0 7 1 7 2 7 3 7 4 7 5 7 6 7 7 + 7 8 7 9 7 a 7 b 7 c 7 d 7 e 7 f 8 0 + 8 1 8 2 8 3 8 4 8 5 8 6 8 7 8 8 +8 9 8 a 8 b 8 c 8 d 8 e 8 f 9 0 9 1 + 9 2 9 3 9 4 9 5 9 6 9 7 9 8 9 9 9 +a 9 b 9 c 9 d 9 e 9 f a 0 a 1 a 2 + a 3 a 4 a 5 a 6 a 7 a 8 a 9 a a a b + a c a d a e a f b 0 b 1 b 2 b 3 b + 4 b 5 b 6 b 7 b 8 b 9 b a b b b c + b d b e b f c 0 c 1 c 2 c 3 c 4 c 5 + c 6 c 7 c 8 c 9 c a c b c c c d +c e c f d 0 d 1 d 2 d 3 d 4 d 5 d 6 + d 7 d 8 d 9 d a d b d c d d d e d +f e 0 e 1 e 2 e 3 e 4 e 5 e 6 e 7 + e 8 e 9 e a e b e c e d e e e f f 0 + f 1 f 2 f 3 f 4 f 5 f 6 f 7 f 8 f + 9 f a f b f c f d f e f f 10 : 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 + 0 9 0 a C:\test>

      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". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice.