But vec's approach might provide reproducible results on different architectures.

Each of the snippets I posted produces the same output on both little-endian and big-endian machines.

With pack, you say what you want, and you get it. It's far cleaner than being told what you're going to get —sometimes LE, sometimes BE, based on the size of the third arg— and having to work around that.

> Each of the snippets I posted produces the same output on both little-endian and big-endian machines

I believe you, but how do you reliably check the output?

And what does "same output" exactly mean?

I did machine programming on big-endian architectures, I don't know what to trust anymore.

Do I need to check with Devel::Peek to be sure?

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

I believe you, but how do you reliably check the output?

Whether using vec, pack or some other means, there are two ways: Reading the documentation, or testing experimentally on the appropriate machines.

And what does "same output" exactly mean?

For the code in Re: Displaying bit-vectors with Most Significant Bits to the left?, the topic was producing 0000011100000101 from $m0.

For the code in Re^2: Displaying bit-vectors with Most Significant Bits to the left?, the topic was producing a string consisting of the byte 0b00000111 followed by the byte 0b00000101.

I did machine programming on big-endian architectures, I don't know what to trust anymore. Do I need to check with Devel::Peek to be sure?

Check what? If pack or vec produced the expected strings? Devel::Peek::Dump would be too noisy. I'd use one of the following:

sprintf "%v02X", $bytes

unpack 'H*', $bytes
[download]

For example,

$ perl -e'
   for my $format (qw( n v )) {
      my $bytes = pack($format, 0x1234);
      CORE::say sprintf "%v02X", $bytes;
      CORE::say unpack "H*", $bytes;
   }
'
12.34
1234
34.12
3412
[download]