Convert Decimal to Hex and store to array in C - c

I've been trying to convert decimal from 1 to 99 to hexadecimal and store them into an array.
What I have is something like this:
int main(){
int i =1;
char dump_holder[3];
char hex_holder[100];
for (i=1;i<100;i++){
sprintf(dump_holder, "%02x",i);
hex_holder[i] = atoi(dump_holder);
printf("this: %02x\n", hex_holder[i]);
}
return 0;}
I'm getting correct value a certain number. This code returns:
this: 01
this: 02
this: 03
this: 04
this: 05
this: 06
this: 07
this: 08
this: 09
this: 00
this: 00
this: 00
this: 00
this: 00
this: 00
this: 0a
this: 0b
this: 0c
this: 0d
this: 0e
this: 0f
this: 10
this: 11
this: 12
this: 13
this: 01
this: 01
this: 01
this: 01
this: 01
this: 01
this: 14
this: 15
this: 16
this: 17
this: 18
this: 19
this: 1a
this: 1b
this: 1c
this: 1d
I think the stray values are the null terminator, but I'm not sure.

well, the basic thing is I cannot understand what you are actually trying to achive
but I will try my best:
int main(){
int i =1;
char dump_holder[3];
char hex_holder[100];
for (i=1;i<100;i++){
/* convert numerical value to string */
sprintf(dump_holder, "%02x",i);
/* convert string value back to numerical value */
//hex_holder[i] = atoi(dump_holder); //won't work
hex_holder[i] = strtol(dump_holder, NULL, 16); // this will
/* print the numerical value in hex representation */
printf("this: %02x\n", hex_holder[i]);
}
return 0;}
are you trying to create a string representation of the values in hex format?
if so, you are going about this the wrong way
right now you are not doing much except wasting proccessing power
even so i added a small code that will actuallt conver the code to a string representation of the values. Maybe that is what you actually intended to do
int main()
{
int i = 1;
char dump_holder[3];
/* the array should be an array of strings (restricted here to 2chars) */
char hex_holder[100][2];
for (i=1;i<100;i++){
/* convert numerical value to string representation */
sprintf(hex_holder[i], "%02x",i);
/* print the string produced */
printf("this: %s\n", hex_holder[i]);
}
return 0;
}

atoi assumes decimal representation, try strtol(dump_holder, NULL, 16); instead.

To understand the problem in your code, you first need to understand -
How atoi works?
Read about atoi and go through the example demonstrating its behavior
here.
In your program output, after 09 you are getting six times 00 because the atoi is returning 0 for the hex values 0a, 0b, 0c, 0d, 0e and 0f.
After this the program output is:
this: 0a
this: 0b
this: 0c
this: 0d
this: 0e
this: 0f
Reason is -
The hex value after 0f is 10. 10 is stored in dump_holder variable which is passed to atoi.
atoi returned integer value 10 which is stored in hex_holder[i].
Your program is printing the value stored in hex_holder[i], which is of type char, using %x format specifier. So, the value 10 is getting printed as 0a.
Using incorrect format specifier is undefined behavior which includes it may do exactly what the programmer intended or silently generating incorrect results or anything else.
Just to convert decimal from 1 to 99 to hexadecimal and store them into an array, you can do:
#include <stdio.h>
int main() {
char hex_holder[100][3];
for (int i = 1; i < 100; i++) {
snprintf (hex_holder[i], 3, "%02x", i);
printf("this: %s\n", hex_holder[i]);
}
return 0;
}

Related

Reading data pointed to by an address

working on my reversing skillset here and I came upon something I thought i understood but I managed to confuse myself.
Working in C mainly
My function returns me an address for the information I want to access.
LRESULT ret = SendMessage(hComboBox, CB_GETITEMDATA, (WPARAM)0 , (LPARAM) 0);
// the exact function doesn't really matter here.
printf("Address: %p\n", ret); // Output is 09437DF8
A dump of this address results in
09437DF8 A0 55 E8 12
This is the address (note endianness) of the data I really want to read.
12e855A0
12 E8 55 A0 - 30 00 3A 00 30 00 33 00 3A 00 32 00 32 00 00 00 - UNICODE "0:03:22"
Now I'm fairly certain this is just basic pointers/referencing/de-referencing but i cant wrap my head what I have to do to read this value pragmatically.
wprintf(L"%s\n", <value at address pointed to by ret>);
// Yes its a null terminated string
// Im working via injected dll, so no access violations
// string is unicode
Perhaps something like this?
#include <stdio.h>
#include <wchar.h>
int main()
{
wchar_t *name = L"UNICODE String";
void **ret = (void **)&name;
wprintf(L"%ls \n", *(wchar_t **)ret);
return 0;
}

Getting MAC address in c and writing it to a txt file

Following is my code. In this program I use system function and passe a command line argument to get the mac address of the pc and then write it into the txt file. txt file is creating successfully. But When I try to open the txt file which was created it wont show anything. It show letter M and some blank spaces. Any idea why is this happening ? Thank you.
#include<stdio.h>
int main()
{
system("wmic nic where (AdapterTypeId=0 AND netConnectionStatus=2) get MACAddress >macaddress.txt");
FILE * fpointer=fopen("macaddress.txt","r");
char buffer[500];
while(!feof(fpointer)){
fgets(buffer,500,fpointer);
puts(buffer);
}
fclose(fpointer);
}
This will do what you want, but if instead of just printing the contents of the file you actually want to do something with it and you need the text as ASCII you'll need to perform that conversion yourself from wide characters.
Since this particular file is just normal letters and numbers text you can convert the wide string to narrow with sprintf.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
system("wmic nic where (AdapterTypeId=0 AND netConnectionStatus=2) get MACAddress > macaddress.txt");
//Binary mode tells fgetws to read wide characters instead of multi-byte.
FILE * fp = fopen("macaddress.txt", "rb");
if (fp)
{
wchar_t buffer[500] = { 0 };
fread(buffer, 1, 2, fp); //read and discard BOM
while (fgetws(buffer, 500, fp))
{
// %ls means the parameter is a wide string.
// %S also works in Visual Studio
printf("%ls", buffer);
//Convert wide characters to ASCII
//This assumes the wide characters are all in the ASCII range
char ascii[500] = { 0 };
sprintf(ascii, "%ls", buffer);
printf("%s", ascii);
}
fclose(fp);
}
return 0;
}
It is not an ASCII encoded file. Here is a dump
0 1 2 3 4 5 6 7 8 9 A B C D E F
0000:0000 FF FE 4D 00 41 00 43 00 41 00 64 00 64 00 72 00  ■M.A.C.A.d.d.r.
0000:0010 65 00 73 00 73 00 20 00 20 00 20 00 20 00 20 00 e.s.s. . . . . .
0000:0020 20 00 20 00 20 00 20 00 0D 00 0A 00
etc so as not to reveal my MAC address.
Note too it contains zeros which will terminate any string output after reading with fgets.
My text editor (Notepad++) shows the correct content because it sets the right text format automatically.

Why does printf() print ffffff before actual data. C [duplicate]

This question already has answers here:
printf adds extra `FFFFFF` to hex print from a char array [duplicate]
(3 answers)
Closed 7 years ago.
printf() function prints leading ffffff (technically I understand that most significant bit carries sign so it gets carried all the way to where data starts). But how to get rid of them I have no idea and why is it happening?
int mem_display(Cmd *cp, char *arguments)
{
int i;
char *adr;
if (!sscanf(arguments,"%x",&adr))
{
return 0;
}
printf("%#0.8s ",arguments);
for (i=0; i<16; i++) {
printf("%02.x ",(unsigned int)*(adr+i));
}
...
the output:
% UNIX> md 10668
/*calling function show memory location 0x10668*/
OUT:
10668 ffffffbc 10 20 ffffffe0 ffffffa0 40 ffffffa2 ffffffa0 44 ffffff9c 23 ffffffa0 20
solved:
printf("%0.2x ",(unsigned int)*(adr+i));
output:
UNIX> md 10000
10000 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 .ELF............
Cast to unsigned char to have the system consider *(adr+i) as unsigned, so that no sign expansion will be done.
for (i=0; i<16; i++) {
printf("%02.x ",(unsigned char)*(adr+i));
}
Please read the printf() manual, this is the correct way
printf("%02x ", (unsigned char) adr[i]);
Note: don't use this *(a + i) notation, and specially when you are casting it. It's not a bad way to dereference a pointer, it's just not appropriate in this particular situation.

Passing a 256-bit wire to a C function through the Verilog VPI

I have a 256-bit value in Verilog:
reg [255:0] val;
I want to define a system task $foo that calls out to external C using the VPI, so I can call $foo like this:
$foo(val);
Now, in the C definition for the function 'foo', I cannot simply read the argument as an integer (PLI_INT32), because I have too many bits to fit in one of those. But, I can read the argument as a string, which is the same thing as an array of bytes. Here is what I wrote:
static int foo(char *userdata) {
vpiHandle systfref, args_iter, argh;
struct t_vpi_value argval;
PLI_BYTE8 *value;
systfref = vpi_handle(vpiSysTfCall, NULL);
args_iter = vpi_iterate(vpiArgument, systfref);
argval.format = vpiStringVal;
argh = vpi_scan(args_iter);
vpi_get_value(argh, &argval);
value = argval.value.str;
int i;
for (i = 0; i < 32; i++) {
vpi_printf("%.2x ", value[i]);
}
vpi_printf("\n");
vpi_free_object(args_iter);
return 0;
}
As you can see, this code reads the argument as a string and then prints out each character (aka byte) in the string. This works almost perfectly. However, the byte 00 always gets read as 20. For example, if I assign the Verilog reg as follows:
val = 256'h000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f;
And call it using $foo(val), then the C function prints this at simulation time:
VPI: 20 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
I have tested this with many different values and have found that the byte 00 always gets mapped to 20, no matter where or how many times it appears in val.
Also, note that if I read the value in as a vpiHexStrVal, and print the string, it looks fine.
So, two questions:
Is there a better way to read in my 256-bit value from the Verilog?
What's going on with the 20? Is this a bug? Am I missing something?
Note: I am using Aldec for simulation.
vpiStringVal is used when the value is expected to be ASCII text, in order to get the value as a pointer to a C string. This is useful if you want to use it with C functions that expect a C string, such as printf() with the %s format, fopen(), etc. However, C strings cannot contain the null character (since null is used to terminate C strings), and also cannot represent x or z bits, so this is not a format that should be used if you need to distinguish any possible vector value. It looks like the simulator you are using formats the null character as a space (0x20); other simulators just skip them, but that doesn't help you either. To distinguish any possible vector value use either vpiVectorVal (the most compact representation) or vpiBinStrVal (a binary string with one 0/1/x/z character for each bit).

C Convert String to Ints Issue

I'm trying to parse some input on an embedded system.
I'm expecting something like this:
SET VARNAME=1,2,3,4,5,6,7,8,9,10\0
When I'm converting the separate strings to ints, both atoi() and strtol() seem to be returning 0 if the string begins with 8.
Here is my code:
char *pch, *name, *vars;
signed long value[256];
int i;
#ifdef UARTDEBUG
char convert[100];
#endif
if(strncmp(inBuffer, "SET",3)==0)
{
pch = strtok(inBuffer," ");
pch = strtok(NULL," ");
name = strtok(pch, "=");
vars = strtok(NULL,"=");
pch = strtok(vars,",");
i = 0;
while(pch != NULL)
{
value[i] = atoi(pch);
#ifdef UARTDEBUG
snprintf(convert, sizeof(convert), "Long:%d=String:\0", value[i]);
strncat(convert, pch, 10);
SendLine(convert);
#endif
i++;
pch = strtok(NULL,",");
// Check for overflow
if(i > sizeof(value)-1)
{
return;
}
}
SetVariable(name, value, i);
}
Passing it:
SET VAR=1,2,3,4,5,6,7,8,9,10\0
gives the following in my uart debug:
Long:1=String:1
Long:2=String:2
Long:3=String:3
Long:4=String:4
Long:5=String:5
Long:6=String:6
Long:7=String:7
Long:0=String:8
Long:9=String:9
Long:10=String:10
UPDATE:
I've checked the inBuffer both before and after 'value[i] = atoi(pch);' and it's identical and appears to have been split up to the right point.
S E T V A R 1 2 3 4 5 6 7 8 9 , 1 0
53 45 54 00 56 41 52 00 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 39 2c 31 30 00 00 00 00
UPDATE 2:
My UARTDEBUG section currently reads:
#ifdef UARTDEBUG
snprintf(convert, 20, "Long:%ld=String:%s", value[i], pch);
SendLine(convert);
#endif
If I comment out the snprintf() line, everything works perfectly. So what's going on with that?
can't you try to write your own atoi?
it's like ten lines long and then you can debug it easily (and check where the problem really is)
'0' = 0x30
'1' = 0x31
and so on, you just need to do something like
string[x] - 0x30 * pow(10, n)
for each digit you have
Not related, but
if(i > sizeof(value)-1)
{
return;
}
should be
if(i == sizeof(value)/sizeof(value[0]) )
{
return;
}
May be the cause of the problem if other pieces of code do the overflow checking in the wrong way and because of that they overwrite part of your string
I've just tried compiling and running your sample code on my own system. The output is correct (i.e. '8' appears where it should be in the output string) which indicates to me that something else is going on outside of the scope of the code you've provided to us.
I'm going to go out on a limb and say that one of your variables or functions is trampling your input string or some other variable or array. SendLine and SetVariable are places to look.
But more importantly, you haven't given us the tools to help you solve your problem. When asking people to help you debug your program, provide a simple test case, with full source, that exemplifies the problem. Otherwise, we're left to guess what the problem is, which is frustrating for us and unproductive for you.
atoi returns 0 for something that it can't render as numeric -- this is just a hunch, but have you tried dumping the binary representation of the string (or even checking that the string lengths match up)?

Resources