Random value in output even after initializing the variables - c

#include<stdio.h>
int main()
{
int a , b;
a = 2;
b = 3;
printf("%d , %d", a , b);
return 0;
}
The output comes out to be ->
PS E:\Coding\C\C C++> cd "e:\Coding\C\C C++" ; if ($?) { gcc hello.c -o hello } ; if ($?) { .\hello }
4214884
Why is this happening? Is there something wrong with the compiler?

The code seems okay, it should give the correct output.
After saving the code, compile the program again.
gcc file_name_with_extension
It'll create an execitable file. Then run that file by simply giving the name of the executable file without any extension.

Related

How to extract only hex code from my compiled code

I wrote a program in C and I want to get .hex file from it.
My C program for testing:
int main(){
int j = 9;
int k = 10;
int l = j + k;
int m = j - k;
}
This is ouptut that i'm looking for:
fe010113
00112e23
00812c23
02010413
00900513
...
In terminal, I compiled my code using riscv-none-gcc compiler with these --specs=nosys.specs main.c -o main.o arguments.
But when i opened the main.o file i saw this:
��������≤�
������ˇˇˇˇ�|
���� ���t�� ���BFàÅ���ˇˇˇˇ�|
� ���H���º�:���BJàNÅâX»B¡B…B����ˇˇˇˇ�|
�(���|���ˆ�l���BDàíXÅâD¡B»B…B“B�������ˇˇˇˇ�|
�4���∏���
�ö���B BàFâLíìîÅ8
¡B»B…B“B”B‘B�B������ˇˇˇˇ�|
�������î�����H������§�‘���B0BñFïXìîó ôÅàâíò
B
»F¡B…B“B”B‘B’B÷B◊BÿBŸB�B������ˇˇˇˇ�|
����l��x�������l��z�������l��|�������l��~�������l��Ä�������l��Ç�������l��Ñ�������l��à�������l��å�������l��é�������ˇˇˇˇ�|
������ê������������������������t������������î�����������ò�����������ú�����������§�����������®�����������–�����������‹�����������‡������ ��������������
���������������ˇ������������Òˇ������������Òˇ���î�������������������Òˇ����ò�������*���ÿ��������,���Ù��������?����������U���‹�������d���§�������ã���N�������ó���‡������ �£���†�������¬������������ÒˇÓ������������Òˇ…������������Òˇ–������������ÒˇŸ���®�(����Â������������ÒˇÏ������������Òˇ˜������������Òˇ˛������������Òˇ������������Òˇ��ò��������������������Òˇ��®��������%��§��������8��§��������I��ú��������]��ú��������p��ú��������Ü��®������Òˇò��¯����� �∏��¸����� �ü��ÿ������“��|������Ë��–�������¯��–��������–�������������� �.������� �M��î������`��ˆ�l�����¡��÷�������r��º�:�����Ñ������� �§��é������∆��à������Ï��§�‘�����Ä��™��,�����˝��Ñ��������
�ö�����-��~������M�������� �Y��Ç������{��‹�������á��b�®�����é��x�:�����ì��z������≤��x���������÷�������«��≤�
�����T��‘������Œ��®�������›��‹������� �������� �‰������� �2��t�� �������Ä��������å������1��ê������7������� �N������� �`������� ��__call_atexit.c�register_fini�crtstuff.c�deregister_tm_clones�__do_global_dtors_aux�completed.3272�__do_global_dtors_aux_fini_array_entry�frame_dummy�object.3277�__frame_dummy_init_array_entry�main.c�fini.c�impure.c�impure_data�init.c�__atexit.c�lock.c�_exit.c�__FRAME_END__�__fini_array_end�__fini_array_start�__init_array_end�__preinit_array_end�__init_array_start�__preinit_array_start�__global_pointer$�__lock___atexit_recursive_mutex�__lock___arc4random_mutex�__retarget_lock_close�__SDATA_BEGIN__�__TMC_END__�__dso_handle�__lock___env_recursive_mutex�__lock___sinit_recursive_mutex�_global_impure_ptr�__libc_init_array�__libc_fini_array�__lock___malloc_recursive_mutex�__retarget_lock_release_recursive�__retarget_lock_try_acquire_recursive�__call_exitprocs�__retarget_lock_try_acquire�__register_exitproc�__retarget_lock_close_recursive�__BSS_END__�__retarget_lock_acquire_recursive�__bss_start�memset�main�__retarget_lock_init_recursive�__retarget_lock_init�atexit�__DATA_BEGIN__�_edata�__lock___at_quick_exit_mutex�__retarget_lock_acquire�__retarget_lock_release�_exit�__lock___dd_hash_mutex�__lock___tz_mutex�__lock___sfp_recursive_mutex��.symtab�.strtab�.shstrtab�.text�.sdata2�.eh_frame�.init_array�.fini_array�.data�.sdata�.sbss�.bss�.comment�.debug_frame����������������������������������������������������t��t��������������������!���������î�î��������������������)���������ò�ò��������������������3���������ú�ú�������������������?���������§�§�������������������K���������®�®��(�����������������Q���������–�–��������������������X���������‹�‹��������������������^���������‡�‹��<������������������c������0�������‹��9�����������������l�������������� ��<�������������������������������T��`��
���+��������� ��������������¥��}�������������������������������1��y������������������
Maybe not a great question, but is there somewhere my compild code? if yes, how can i find and extract or hexdump it? I am using Mac.
Thanks.

scanf produces segfault when the program is run with a custom entry point (using gcc 7.4.0)

Consider the following code:
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("main\n");
int a;
scanf("%d", &a);
printf("a = %d\n", a);
return 0;
}
int main1() {
printf("main1\n");
int a;
scanf("%d", &a);
printf("a = %d\n", a);
exit(0);
return 0;
}
int main2() {
printf("main2\n");
int a = getchar() - '0';
int b = getchar() - '0';
int c = getchar() - '0';
printf("a = %d\n", 100 * a + 10 * b + c);
exit(0);
return 0;
}
Assuming that the code resides in a file called test.c, the following works fine (it prints "a = 123"):
gcc -o test test.c
echo 123 | ./test
If, however, I run the program with a custom entry point, I get the dreaded Segmentation fault:
gcc -o test test.c -e"main1"
echo 123 | ./test
But if I replace the scanf with three getchars, the program runs fine again despite being run with a custom entry point:
gcc -o test test.c -e"main2"
echo 123 | ./test
To make things even more interesting, these problems occur with gcc 7.4.0 but not with gcc 4.8.4.
Any ideas?
The -e command line flag redefines the actual entry point of your program, not the “user” entry point. By default, using GCC with the GNU C standard library (glibc) this entry point is called _start, and it performs further setup before invoking the user-provided main function.
If you want to replace this entry point and continue using glibc you’ll need to perform further setup yourself. But alternatively you can use the following method to replace the main entry point, which is much simpler:
gcc -c test.c
objcopy --redefine-sym main1=main test.o
gcc -o test test.o
Note, this will only work if you don’t define main in your code, otherwise you’ll get a “multiple definition of `main'” error from the linker.

Argument index specifier not working on MinGW gcc

I can't get the argument index format specifier on fprintf() to work when compiling C code on Windows with gcc-7.2.0-mingw.
Take the following program as an example:
#include <stdio.h>
int main(void) {
int x;
x = 10;
fprintf(stdout, "%1$d == %1$d\n", x);
return 0;
}
Let's compile and run it:
C:\path\to\dir>gcc -Wall -std=c89 -o main.exe main.c
C:\path\to\dir>main.exe
$d == $d
C:\path\to\dir>
While I expected the output to be 10 == 10 (Try it online!).
What's happening and how can I make the argument index specifier work properly?
Note: the same happens if I try to print strings, floats or anything else.

Change something in C program with Shell Script

Is it possible to write a script to run this code for different values of A;
#include <stdio.h>
#define A 3
int main (){
printf("In this version A = %d\n", A);
return(0);
}
I guess something like for loop?
Is it possible to write a script to run this code for different values of A;
Not as it is because the macro A has a fixed value defined in your code. Instead you can pass the value as an argument:
#include <stdio.h>
int main(int argc, char **argv){
if(argc == 2) {
printf("In this version A = %s\n", argv[1]);
}
return 0;
}
(The code doesn't check if its input is an integer -- which you can test if necessary).
and you can run it via script. For example, compile the above (gcc -Wall -Wextra test.c -o test) using a for loop of bash:
$ for ((i = 0; i < 10; i++)); do ./test $i; done
In this version A = 0
In this version A = 1
In this version A = 2
In this version A = 3
In this version A = 4
In this version A = 5
In this version A = 6
In this version A = 7
In this version A = 8
In this version A = 9
$
No. But you can make A a command line arg:
#include <stdio.h>
int main (int argc, char *argv[]) {
int a;
if (argc != 2 || sscanf(argv[1], "%d", &a) != 1) return 1;
printf("In this version A = %d\n", a);
return 0;
}
Compile to a binary named foo, then
foo 42
will print
In this version A = 42
You can also compile different versions by defining A in the compilation command line. From your original program, remove the #define. Then
gcc -DA=42 foo.c -o foo
./foo
will print the same as above.
DO you need run program repeated from script? why not to make program that accepts arguments from command line?
1)The main() function actually takes arguments, you can compile program once and pass different parameters, as shown in answers above
2) If you need to change some code parameters from make script, I'd say, create separate header that would contain defines and write script that would echo into that file (> for start, >> to continue writing).
3) Alternative way you can call you compiler with flag that would be equal to #define macro-command. For gcc it's -D, for example -DA=3 instead of #define A 3.
Most programs use makefile to be compiled. For that case you can script make file to use 2) or 3) Former is preferable because you do not need to pass that argument to all compilation targets, reducing time or re-compiling. There are tools for more advanced manipulations, like autoconf.

Can't run .exe files compiled with gcc (minGW)

I have this C code:
#include <stdio.h>
int main(void)
{
int courses = 1, groups, students = 54, average_pr_group;
/* The variable groups is uninitialized */
average_pr_group = students / groups;
printf("Groups: %d\n", groups);
printf("There are %d students pr. group in %d course(s)\n", average_pr_group, courses);
return 0;
}
Now i compile this using this command from the shell (cmd):
gcc test.c -o test.exe -lm -Wall
It compiles fine, but when I try to run the generated .exe through Windows Explorer I get this error:
In contrast, I can compile & run this piece of code just fine:
# include <stdio.h>
int main()
{
printf("Hello World");
return 0;
}
I have MinGW installed at C:\MinGW
This is my user PATH variable:
I can run the .exe just fine with msys, is it just built to withstand those kind of errors?
Variable groups is probably zero, therefore you divide by zero:
average_pr_group = students / groups;
as variable groups is uninitialized it has a undefined or garbage value and that's why the program is crashing...dividing by an uninitialized variable leads to crashing......

Resources