Sponsored Content
Top Forums UNIX for Advanced & Expert Users byte swapping 32-bit float and weird od results Post 302317361 by GoDonkeys on Monday 18th of May 2009 08:57:09 PM
Old 05-18-2009
byte swapping 32-bit float and weird od results

I'm attempting to read a file that is composed of complex 32-bit floating point values on Solaris 10 that came from a 64-bit Red Hat computer.

When I first tried reading the file, it looked like there was a byte-swapping problem and after running the od command on the file Solaris and Red Hat computers, I saw that they were indeed swapped (every other byte). So, I wrote a little Java program that would swap every other byte and the result was the at the byte-level, the files were the same on both computers. The following is the result of running 'od -x' on the file, showing the first 32-bits which represent the real portion of the first complex number:

f8a6 be03 cd76 bc99

What's weird is that when I run 'od -f' on both computers to see the 32-bit floating point value, I get different results! On the Red Hat computer I get: -1.288782e-01 and on the Solaris computer I get: -2.7055474e+34 Smilie. How can I have the same byte level file yet come up with completely different values when I try to print out the bytes as 32-bit floats?

This is really messing me up trying to write a C++ program to read this file on the Solaris computer. I'm getting the same value in my C++ code as what I see when I run 'od -f' on the Solaris computer. I've tried just about everything that I can think of and haven't been able to get past this.

Does anyone have any idea on what's going on with the od command between the Red Hat and Solaris computers? Any ideas on how to get my C++ code to give me the correct value for the 32-bit float?
 

8 More Discussions You Might Find Interesting

1. Programming

math.h: float ceilf(float x)

Good morning, I'm testing the use of ceilf: /*Filename: str.c*/ #include <stdio.h> #include <math.h> int main (void) { float ceilf(float x); int dev=3, result=0; float tmp = 3.444f; printf("Result: %f\n",ceilf(tmp)); return 0; } (1 Reply)
Discussion started by: jonas.gabriel
1 Replies

2. Shell Programming and Scripting

Check if 2 files are identical byte-to-byte?

In my server migration requirement, I need to compare if one file on old server is exactly the same as the corresponding file on the new server. For diff and comm, the inputs need to be sorted. But I do not want to disturb the content of the file and need to find byte-to-byte match. Please... (4 Replies)
Discussion started by: krishmaths
4 Replies

3. Shell Programming and Scripting

Remove a byte(Last byte from the last line)

Hi All Can anyone please suggest me how to remove the last byte from a falt file .This is from the last line's last BYTE. Please suggest me something. Thank's and regards Vinay (1 Reply)
Discussion started by: vinayrao
1 Replies

4. Programming

Weird timing results in C

I was running some timings in my code to see which of several functions was the best and I've been getting some odd results. Here's the code I'm using: static double time_loop(int (*foo)(int)) { clock_t start, end; int n = 0, i = 0; start = clock(); for (; i <= MAXN; i++) if... (6 Replies)
Discussion started by: CRGreathouse
6 Replies

5. UNIX for Dummies Questions & Answers

Byte to BIT conversion

I have a varchar column which contains the data at ‘bit' level.the data needs to be extract / transform at bit level and this will contain a Boolean value - 0/1. How can we handle using shell scripts At source level(DB2 Database) we have a column of length 250 char ie varchar(250) so each char... (2 Replies)
Discussion started by: Codesearcher
2 Replies

6. Shell Programming and Scripting

Converting String To Integer/Float (weird case)

Hi guys, I'm new here. I have a problem at work. One of our scripts was eventually having a bug and only detected recently. Here's the issue and background: Bash Script which calls AWK script Awk script returns a string as per below (example):var1='00000-123'So, when we convert it, the... (18 Replies)
Discussion started by: sekfarok
18 Replies

7. UNIX for Beginners Questions & Answers

Weird 'find' results

Hello and thanks in advance for any help anyone can offer me I'm trying to learn the find command and thought I was understanding it... Apparently I was wrong. I was doing compound searches and I started getting weird results with the -size test. I was trying to do a search on a 1G file owned by... (14 Replies)
Discussion started by: bodisha
14 Replies

8. Windows & DOS: Issues & Discussions

Which version of Windows Vista to install with a product key? 32-bit or 64-bit?

Hello everyone. I bought a dell laptop (XPS M1330) online which came without a hard drive. There is a Windows Vista Ultimate OEMAct sticker with product key at the bottom case. I checked dell website (here) for this model and it says this model supports both 32 and 64-bit version of Windows... (4 Replies)
Discussion started by: milhan
4 Replies
PACK(3) 								 1								   PACK(3)

pack - Pack data into binary string

SYNOPSIS
string pack (string $format, [mixed $args], [mixed $...]) DESCRIPTION
Pack given arguments into a binary string according to $format. The idea for this function was taken from Perl and all formatting codes work the same as in Perl. However, there are some formatting codes that are missing such as Perl's "u" format code. Note that the distinction between signed and unsigned values only affects the function unpack(3), where as function pack(3) gives the same result for signed and unsigned format codes. PARAMETERS
o $format - The $format string consists of format codes followed by an optional repeater argument. The repeater argument can be either an integer value or * for repeating to the end of the input data. For a, A, h, H the repeat count specifies how many characters of one data argument are taken, for @ it is the absolute position where to put the next data, for everything else the repeat count specifies how many data arguments are consumed and packed into the resulting binary string. Currently implemented formats are: pack(3) format characters +-----+---------------------------------------------------+ |Code | | | | | | | Description | | | | +-----+---------------------------------------------------+ | a | | | | | | | NUL-padded string | | | | | A | | | | | | | SPACE-padded string | | | | | h | | | | | | | Hex string, low nibble first | | | | | H | | | | | | | Hex string, high nibble first | | | | | c | | | | | | | signed char | | | | | C | | | | | | | unsigned char | | | | | s | | | | | | | signed short (always 16 bit, machine byte order) | | | | | S | | | | | | | unsigned short (always 16 bit, machine byte | | | order) | | | | | n | | | | | | | unsigned short (always 16 bit, big endian byte | | | order) | | | | | v | | | | | | | unsigned short (always 16 bit, little endian byte | | | order) | | | | | i | | | | | | | signed integer (machine dependent size and byte | | | order) | | | | | I | | | | | | | unsigned integer (machine dependent size and byte | | | order) | | | | | l | | | | | | | signed long (always 32 bit, machine byte order) | | | | | L | | | | | | | unsigned long (always 32 bit, machine byte order) | | | | | N | | | | | | | unsigned long (always 32 bit, big endian byte | | | order) | | | | | V | | | | | | | unsigned long (always 32 bit, little endian byte | | | order) | | | | | q | | | | | | | signed long long (always 64 bit, machine byte | | | order) | | | | | Q | | | | | | | unsigned long long (always 64 bit, machine byte | | | order) | | | | | J | | | | | | | unsigned long long (always 64 bit, big endian | | | byte order) | | | | | P | | | | | | | unsigned long long (always 64 bit, little endian | | | byte order) | | | | | f | | | | | | | float (machine dependent size and representation) | | | | | d | | | | | | | double (machine dependent size and representa- | | | tion) | | | | | x | | | | | | | NUL byte | | | | | X | | | | | | | Back up one byte | | | | | Z | | | | | | | NUL-padded string (new in PHP 5.5) | | | | | @ | | | | | | | NUL-fill to absolute position | | | | +-----+---------------------------------------------------+ o $args - RETURN VALUES
Returns a binary string containing data. CHANGELOG
+--------+---------------------------------------------------+ |Version | | | | | | | Description | | | | +--------+---------------------------------------------------+ | 5.6.3 | | | | | | | The "q", "Q", "J" and "P" codes were added to | | | enable working with 64-bit numbers. | | | | | 5.5.0 | | | | | | | The "Z" code was added with equivalent function- | | | ality to "a" for Perl compatibility. | | | | +--------+---------------------------------------------------+ EXAMPLES
Example #1 pack(3) example <?php $binarydata = pack("nvc*", 0x1234, 0x5678, 65, 66); ?> The resulting binary string will be 6 bytes long and contain the byte sequence 0x12, 0x34, 0x78, 0x56, 0x41, 0x42. NOTES
Caution Note that PHP internally stores integer values as signed values of a machine-dependent size (C type long). Integer literals and operations that yield numbers outside the bounds of the integer type will be stored as float. When packing these floats as integers, they are first cast into the integer type. This may or may not result in the desired byte pattern. The most relevant case is when packing unsigned numbers that would be representable with the integer type if it were unsigned. In systems where the integer type has a 32-bit size, the cast usually results in the same byte pattern as if the integer were unsigned (although this relies on implementation-defined unsigned to signed conversions, as per the C standard). In systems where the integer type has 64-bit size, the float most likely does not have a mantissa large enough to hold the value without loss of precision. If those systems also have a native 64-bit C int type (most UNIX-like systems don't), the only way to use the I pack format in the upper range is to create integer negative values with the same byte representation as the desired unsigned value. SEE ALSO
unpack(3). PHP Documentation Group PACK(3)
All times are GMT -4. The time now is 01:04 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy