CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
Search Posts SEARCH
Who's Online WHO'S
Log in LOG

Home: Perl Programming Help: Intermediate:
Strange behavior on 32-bit Value 10 in big-endian w/ print?


New User

Nov 26, 2010, 12:37 PM

Post #1 of 2 (1254 views)
Strange behavior on 32-bit Value 10 in big-endian w/ print? Can't Post


I am struggling with a problem I have.

Currently I am working on a file format and when writing numbers, I pack() them with

pack("N", $num_to_pack);

into a 32-bit big-endian sequence (network order).

I now want write this four byte sequence into a file,

print $my_fh pack("N", $num_to_pack);

This is, when things seem to go magical. I would expect that exact four bytes are written into the file, because

length pack("N", $num_to_pack)

is always 4, even if use bytes; is activated. In nearly every case, the resulting sequence in the file is four bytes long and in correct order. BUT, if my value is 10, the Sequence written will be "00 00 00 0D 0A", that is five bytes.

At first, I thought this would happen only in my program, because it is not that uncomplex. But then, I tested the following code as-is:

open F, ">", "out" 
or die "Cannot open: $!\n";

my $val = 10;

print(F pack("N", $val));
printf(F "%4s", pack("N", $val));

and checked "out"'s contents. Guess what? "00 00 00 0D 0A 00 00 00 0D 0A". So am I totally missing something or what is going on here?

I so hope this has just something to do with the \r\n thingy, because 0D is 13 in hex. And 13 10... Well, does not seem that random to me :P.

Nevertheless I was pretty surprised by this behavior, help thus would be appreciated.

New User

Dec 6, 2010, 9:46 AM

Post #2 of 2 (1172 views)
Re: [dire] Strange behavior on 32-bit Value 10 in big-endian w/ print? [In reply to] Can't Post

Either my question was too easy or too hard.

What ever.

I found out what was the problem. Shame on me I blamed it on Perl (or at least on the ActiveState implementation as I am using Windows).

The problem is that Windows obviously still uses some ancient DOS code, which is, one has to specify whether to use a file on the HD as a "text" file or as a binary file. In the latter case, everything works just fine. But beware the text mode! Windows then translates every "\n" into "\r\n". I my case, the binary value "10" - same as "\n" in Windows' view got translated to "\r\n" aka. the values 13 and 10. Thus, all one has to do is setting

binmode HANDLE;

after the open call, because it will tell the OS to open the file in binary mode. If I am told correct, in Linux this is not necessary as there just exists one file mode - and that is the binary mode.

But if your code should be platform-independent, a binmode is never wrong.


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives