Converting hexa to decimal

[Golan]

Hello,
I have a hexa file which I need to convert to decimal.
I use memcpy into variables (char for one octet, short for 2 octets
and int for 4 octets) and then print the value into the file by using
fprintf.
The problem is that I don't know how to convert a field of 6 octets?
Should I use a long variable?

Thanks

 

[Kevin Goodsell]

Hello,
I have a hexa file which I need to convert to decimal.

I don't know what that means.

I use memcpy into variables

What are you using as the source?

(char for one octet, short for 2 octets
and int for 4 octets)

If you are assuming that these types have exactly those sizes, your code
is not very portable. Any of those types may be larger than you specify,
and int may be either larger or smaller.

and then print the value into the file by using
fprintf.
The problem is that I don't know how to convert a field of 6 octets?

In C99 the type 'long long' is large enough to contain an integer that
size, but there is no type guaranteed to be large enough in earlier C
versions. One of the floating point types may be able to represent
integers that large, if you are willing to do the work to build up the
value from the bytes. Beyond that, all you can do is come up with an
algorithm for converting the bytes to text without storing the entire
value in an intermediate object of built-in type.

Should I use a long variable?

long is not guaranteed to be large enough, and typically isn't.

-Kevin

 

[gabriel]

Let me guess it

union _tagchange {
int a;
char b[4];
} change;

main()
{
int i,j;
int buf[1024];
/*
Read some hexa file,and something to buf,and i
*/
memecpy(change,buf,sizeof(int));
for(j=0;j<4;j++)
printf(change.b);
}

 

[Kevin Goodsell]

Let me guess it

OK, but please don't top-post when doing so. Top-posting is rude.

union _tagchange {

Until you know the language much better than you do now, don't use
identifiers beginning with an underscore for any purpose. This
particular case violates the implementation's namespace. From section
7.1.3, paragraph 1:

All identifiers that begin with an underscore are always
reserved for use as identifiers with file scope in both the
ordinary and tag name spaces.

int a;
char b[4];
} change;

main()

Prefer

int main(void)

"Implicit int" has been removed from the C language. Empty parameter
lists on function declarations are a bad idea unless you are sure you
know exactly what you are doing.

{
int i,j;
int buf[1024];
/*
Read some hexa file,and something to buf,and i
*/
memecpy(change,buf,sizeof(int));

There is no function memecpy in the C standard library, and you haven't
declared it anyway. This is an error in C99 and a bad idea in any C version.

Assuming you meant memcpy(), you need to #include <string.h>. Also,
there's no implicit conversion to void* from a union or int type, so the
first two arguments are wrong. Besides that, 'i' seems to be uninitialized.

If you meant to copy an int from buf (for some valid value of i in
[0, 1024) ) into the int member of change, there's no reason to use
memcpy at all. Simple assignment works just fine:

change.a = buf;

for(j=0;j<4;j++)
printf(change.b);

Using printf here is an error requiring a diagnostic in C99, and a
(possibly) silent invocation of undefined behavior in earlier versions
because there is no prototype in scope. #include <stdio.h> to fix this.

You've also severely screwed up the printf call. What happened to the
format string?

Even with those fixed, however, the code is still questionable. In
general, reading a member of a union other than the most recent member
that had a value stored in it is undefined behavior. unsigned char is
special - it has no trap representations, so inspecting the value of an
unsigned char is always defined. Whether or not this is also true for
plain char is uncertain. I'm not aware of any guarantee (and I can't
locate one) that signed char has no trap representations, so I believe
that the behavior of accessing change.b can be undefined.

Returning a value from main() would be a good idea.

}

-Kevin