I am working on a malloc lab program where i need to find the performance index of utility and throughput. I am able to get the output efficiency but there is one problem when executing for the first time.
I have given specific set of files which includes traces and other files,When i am trying to run the program first time it is showing errors but when i run the same code with same command second time to multiple times i am not getting error and output is fine? why it is showing error in when running first time ? is there any problem with allocating memory or performing operation in malloc ?
the commands and first time error as follows ,
enter code here
#ubuntu:$ make
when i run this first time i am getting error which is as follows ,
enter code here
gcc -Wall -O2 -m32 -c -o mdriver.o mdriver.c
mdriver.c: In function ‘remove_range’:
mdriver.c:438:9: warning: variable ‘size’ set but not used [-Wunused-but-set-variable]
int size;
^
mdriver.c: In function ‘read_trace’:
mdriver.c:498:11: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%d", &(trace->sugg_heapsize)); /* not used */
^
mdriver.c:499:11: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%d", &(trace->num_ids));
^
mdriver.c:500:11: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%d", &(trace->num_ops));
^
mdriver.c:501:11: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%d", &(trace->weight)); /* not used */
^
mdriver.c:524:12: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%u %u", &index, &size);
^
mdriver.c:531:12: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%u %u", &index, &size);
^
mdriver.c:538:12: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
fscanf(tracefile, "%ud", &index);
^
gcc -Wall -O2 -m32 -c -o mm.o mm.c
mm.c:780:13: warning: ‘mm_check’ defined but not used [-Wunused-function]
static int mm_check(void)
^
gcc -Wall -O2 -m32 -c -o memlib.o memlib.c
gcc -Wall -O2 -m32 -c -o fsecs.o fsecs.c
gcc -Wall -O2 -m32 -c -o fcyc.o fcyc.c
gcc -Wall -O2 -m32 -c -o clock.o clock.c
gcc -Wall -O2 -m32 -c -o ftimer.o ftimer.c
gcc -Wall -O2 -m32 -o mdriver mdriver.o mm.o memlib.o fsecs.o fcyc.o clock.o ftimer.o
I run the same command again
enter code here
#ubuntu:$ make
make: `mdriver' is up to date.
Now then it shows no error and after that if i run the program with the required commands it works perfectly fine ,but it is showing errors first time ?
There is no error in your source. There are many warnings. The object and executable files will be generated even source is having warnings. In makefile, the files will not be recompiled if the timestamp is remains same.
For more understanding, tiger some compilation error in your source and run make command again and again then you can understand the difference.
Related
I'm compiling with a command:
gcc grep.c -std=c99 -g -Winit-self -pedantic -w -o main2 && ./main2 lib text.txt
and I wish to receive warnings for initialized but not used variables and functions.
If you use -Wunused-variable it will warn for unused variables. But I recommend using -Wall -Wextra. Then you will get that for free with a bunch of other stuff.
When it comes to unused functions I refer to this: GCC -Wunused-function not working (but other warnings are working)
You can use the -Wunused-but-set-variable option to warn for these.
test.c:
int main(void)
{
int c = 0;
c = 3;
}
Example:
$ gcc test.c -Wunused-but-set-variable -o test
test.c: In function ‘main’:
test.c:3:9: warning: variable ‘c’ set but not used [-Wunused-but-set-variable]
int c = 0;
^
Here is the content of source file get.c :
#include <stdio.h>
int main(){
//int i = 0;
char b[10];
gets(b);
puts(b);
return 0;
}
When I compile it with these command
gcc -o get get.c -Wall -Werror
The output is
/tmp/ccYEWZvx.o: In function `main':
get.c:(.text+0x10): warning: the `gets' function is dangerous and should not be used.
But when change the code to
#include <stdio.h>
int main(){
int i = 0; // **this line just be uncommented**
char b[10];
gets(b);
puts(b);
return 0;
}
Using the same command, the output is
cc1: warnings being treated as errors
get.c: In function 'main':
get.c:4: error: unused variable 'i'
So, why this unused variable warning be treated as error, while the use of gets() not?
The gets() warning is being issued by the linker not the compiler, so the compiler settings do not apply.
Only the linker is able to determine that the symbol is resolved with the standard library gets() rather than some other implementation with the same name.
To instruct the linker to treat warnings as errors you need to pass it the --fatal-warnings option. In turn when not invoking the linker directly, options are passed to the linker by gcc using the -Wl option in a comma separated list:
gcc -o get get.c -Wall -Werror -Wl,--fatal-warnings
Note that the GNU linker is documented separately from the compiler, as part of binutils. The linker options are described here.
If you look at the output from the first example, it says the "error" is in an object file, which means it is generated by the linker.
The second error is generated by the compiler, which means there is no object file being generated and so the linker will not be invoked.
-Werror make all warnings as errors, to print only security warnings you can use: -Wformat -Wformat-security
You can read warnings options here https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
The compiler abort the compilation if an error is occurred, instead it continue the compilation if there are one or more warnings.
How can I let gcc and clang generate warnings for header files included by header files in non-current directories?
I'm using gcc 4.9.2 and clang 3.6.0.
For example, assume that ./include_a.c includes ./dir/a.h, ./dir/a.h includes ./b.h, and ./b.h is expected to generate a warning for -Wconversion; then, gcc and clang with -Wconversion DO NOT generate the expected warning when they compile include_a.c. With -Wconversion -Wsystem-headers, the expected warning is generated, but it often comes with many useless warnings for system headers. When ./b.h is directly included from a source file in the current directory (such as ./include_b.c), the expected warning is generated without -Wsystem-headers.
The following shell script reproduces this example (the case of clang is omitted):
#!/bin/sh
mkdir dir
echo '#include "b.h"' >dir/a.h
echo 'void f() {int a = 0; char b = a;}' >b.h
echo '#include "dir/a.h"' >include_a.c
echo '#include "b.h"' >include_b.c
set -x
gcc -c include_a.c -Wconversion # DOES NOT generate a warning
gcc -c include_a.c -Wconversion -Wsystem-headers # generate a warning
gcc -c include_b.c -Wconversion # generate a warning
Output:
+ gcc -c include_a.c -Wconversion
+ gcc -c include_a.c -Wconversion -Wsystem-headers
In file included from dir/a.h:1:0,
from include_a.c:1:
./b.h: In function ‘f’:
./b.h:1:31: warning: conversion to ‘char’ from ‘int’ may alter its value [-Wconversion]
void f() {int a = 0; char b = a;}
^
+ gcc -c include_b.c -Wconversion
In file included from include_b.c:1:0:
b.h: In function ‘f’:
b.h:1:31: warning: conversion to ‘char’ from ‘int’ may alter its value [-Wconversion]
void f() {int a = 0; char b = a;}
^
This behavior seems not to be a bug because gcc and clang perform in the same way, but how can I obtain warnings from all the my source files?
I just moved to gcc4.9 . Now when I run make to compile my program, I noticed the verbosity of messages is much increased. In particular in the warnings, I receive a lot more of info I don't need, mainly such messages:
myfile.c: In function 'myfunc':
myfile.c:4677:10: warning: passing argument 1 of 'sprintf' from incompatible pointer type
sprintf(str1,"file.txt");
^
In file included from /usr/include/features.h:374:0,
from /usr/include/stdio.h:27,
from myfile.c:28:
/usr/include/i386-linux-gnu/bits/stdio2.h:31:1: note: expected 'char * __restrict__' but argument is of type 'char **'
__NTH (sprintf (char *__restrict __s, const char *__restrict __fmt, ...))
^
My compilation parameters are always the same "-g -O3".
I tried -g0 and -g1, but verbosity doesn't lower.
So wanted to ask, how can I set gcc to suppress all those excessive compile-time messages in the warnings, everything starting from "In file included..." and after?
EDIT:
I guess I have to elaborate more what I want to achieve.
I want the warnings, so I don't need -w option.
I do want to see:
myfile.c: In function 'myfunc':
myfile.c:4677:10: warning: passing argument 1 of 'sprintf' from incompatible pointer type
sprintf(str1,"file.txt");
^
I do NOT want to see:
In file included from /usr/include/features.h:374:0,
from /usr/include/stdio.h:27,
from myfile.c:28:
/usr/include/i386-linux-gnu/bits/stdio2.h:31:1: note: expected 'char * __restrict__' but argument is of type 'char **'
__NTH (sprintf (char *__restrict __s, const char *__restrict __fmt, ...))
I'm not interested that primitive sprintf is declared in a,called by b (...who actually could be interested in that...?!?)
The previous gcc version didn't have that issue, so my best guess, there must be some new option in gcc4.9 to remove that (but I couldn't find it)
Does anybody know how to remove everything starting from "In file included..." further(in the warning)?
Thanks
I strongly recommend you don't do this, but if you insist:
gcc -w inhibits all warnings. This is something you could have discovered from googling 'gcc suppress warnings'. . .
That said, the warnings are valid - you appear to be doing wrong things in your code. If you want to get rid of the warnings, why not fix the code? Then you have better code and no warnings.
What you suggest is a workaround, but I can still try it. Could you please write here that filter you talk about?
OK; I'd create a shell script to do the hard work. There are two ways to handle it. One is to call the script gcc-filter and then instead of running:
gcc -g -O3 -Wall -Wextra -Werror -I/where/ever -c source.c
you would run:
gcc-filter gcc -g -O3 -Wall -Wextra -Werror -I/where/ever -c source.c
Using make, you can achieve that by specifying CC="gcc-filter gcc" or equivalent.
The alternative is to run the script after redirecting output:
gcc -g -O3 -Wall -Wextra -Werror -I/where/ever -c source.c 2>&1 | gcc-filter
I'm going to assume the first technique.
gcc-filter.sh
"$#" 2>&1 |
sed '/^In file /,/^ *^/d' >&2
The first line runs gcc (or whatever command is specified by the arguments; it doesn't have to be gcc) with the arguments as specified on the command line. It redirects both standard output and standard error to a pipe (I'll come back to this), which goes to sed.
The sed line looks for the pattern In file at the start of a line, and deletes from there up to the first line that starts with a caret after optional spaces. The redirection sends the information that it passes through to standard error.
There are two prime defects with the script as it stands:
It assumes that standard output and standard error can be merged (or, more succinctly, that gcc doesn't write much to standard output).
It works off one pattern of error reporting. If there are other sequences that should be filtered, you will need to add to the sed script.
You can deal with the standard output vs standard error issue, but it is mildly mind blowing (maybe 'mind puffing').
(
"$#" 2>&1 1>&3 |
sed '/^In file /,/^ *^/d' >&2
) 3>&1
The sub-shell ( ... ) 3>&1 sends data written to file descriptor 3 so it goes to standard output.
Inside the sub-shell 2>&1 1>&3 | arranges for:
Standard output to go to the pipe.
Standard error to go where standard output is going (the pipe).
Standard output to go to file descriptor 3 (without changing where standard error is going, the pipe).
The sed command therefore gets the standard error output from gcc as its standard input, filters it, and the >&2 sends its standard output to standard error.
The net result is that standard error is filtered while standard output is not. However, be aware that you can end up with different interleaving of output from the two streams as a result of the buffering going on.
One other problem: exit status. The exit status of the script as written is the exit status of the sed command, which will be 0 under most circumstances. If we need to relay the exit status from gcc, we have to work with the Bash set -o pipefail, I think. Or you can poke at the PIPESTATUS array; exit ${PIPESTATUS[0]} should exit with the same exit status that gcc exited with.
Demonstrating the code working on Linux
The system is running an Ubuntu 14.04 LTS derivative with GCC 4.9.2.
Test code b.c
(I'd used up x.c, y.c, z.c, and a.c on other programs.)
#include <stdio.h>
int main(void)
{
char array[512];
char *buffer = array;
sprintf(&buffer, "file.txt");
printf("%s\n", buffer);
return 0;
}
Compilation without gcc-filter.sh:
$ make b.o WFLAG3= WFLAG4= WFLAG5= WFLAG6= IFLAGS= LDFLAGS= LDLIBS= cc -g -O3 -std=c11 -Wall -Wextra -Werror -c -o b.o b.c
b.c: In function ‘main’:
b.c:8:3: error: passing argument 1 of ‘sprintf’ from incompatible pointer type [-Werror]
sprintf(&buffer, "file.txt");
^
In file included from /usr/include/features.h:374:0,
from /usr/include/stdio.h:27,
from b.c:1:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:31:1: note: expected ‘char * restrict’ but argument is of type ‘char **’
__NTH (sprintf (char *__restrict __s, const char *__restrict __fmt, ...))
^
cc1: all warnings being treated as errors
<builtin>: recipe for target 'b.o' failed
make: *** [b.o] Error 1
$
Compilation with gcc-filter.sh
$ make b.o CC="./gcc-filter.sh gcc"
./gcc-filter.sh gcc -g -O3 -std=c11 -Wall -Wextra -Werror -c -o b.o b.c
b.c: In function ‘main’:
b.c:8:11: error: passing argument 1 of ‘sprintf’ from incompatible pointer type [-Werror]
sprintf(&buffer, "file.txt");
^
cc1: all warnings being treated as errors
<builtin>: recipe for target 'b.o' failed
make: *** [b.o] Error 1
$
gcc-filter.sh
#!/bin/bash
set -o pipefail
(
"$#" 2>&1 1>&3 |
sed '/^In file /,/^ *^/d' >&2
) 3>&1
exit ${PIPESTATUS[0]}
And another test
I also created c.c which contained three sprintf() lines and three printf() lines, and the filtered output was:
$ ./gcc-filter.sh gcc -g -O3 -std=c11 -Wall -Wextra -Werror -c c.c
c.c: In function ‘main’:
c.c:8:11: error: passing argument 1 of ‘sprintf’ from incompatible pointer type [-Werror]
sprintf(&buffer, "file1.txt");
^
c.c:10:11: error: passing argument 1 of ‘sprintf’ from incompatible pointer type [-Werror]
sprintf(&buffer, "file2.txt");
^
c.c:12:11: error: passing argument 1 of ‘sprintf’ from incompatible pointer type [-Werror]
sprintf(&buffer, "file3.txt");
^
cc1: all warnings being treated as errors
$
So multiple errors are handled properly (but in times past, more than one similar script has appeared to work on a single instance of an error message but when tested on multiple error messages, it was too enthusiastic about discarding output).
I’m using the following flags, but still I m not able to get this warning:
pointer of type void * used in arithmetic
Flags used:
-O2 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -fno-strict-aliasing
-Wpointer-arith should catch this type of warning, but I’m not able to get this warning:
pointer of type void * used in arithmetic
Which specific cflag should be used to get this warning?
Edit: my mistake, it is there as part of a macro check which is not defined. :( By defining that macro, I’m able to get that error.
You're right. -Wpointer-arith should give you a warning as per the documentation.
I have just tried the following program (with intentional error):
~/code/samples$ cat foo.c
#include <stdio.h>
int main (int argc, char **argv)
{
void * bar;
void * foo;
foo = bar + 1;
return 0;
}
I have compiled the program with just the -Wpointer-arith option, and all your options as listed above. Both attempts threw up the desired warning. I am using gcc version 4.3.4 (Debian 4.3.4-6).:
~/code/samples$ gcc -Wpointer-arith foo.c
foo.c: In function ‘main’:
foo.c:6: warning: pointer of type ‘void *’ used in arithmetic
and
~/code/samples$ gcc -O2 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -fno-strict-aliasing foo.c
cc1: warnings being treated as errors
foo.c: In function ‘main’:
foo.c:6: error: pointer of type ‘void *’ used in arithmetic
The compiler does throw up the warning if you give it the 'right' code. So, I would recommend you examine why it is you expect this warning. Maybe the code you're compiling has changed?
One possible clue I can give you: foo = bar + 1; in the code above triggers the warning. But foo = bar ++; will not (You get a different warning). So if your code uses increment (or decrement) operators on pointers, it will probably not trigger the warning.
I know this is not a direct answer, but I hope this helps you focus your investigation.
With gcc 4.2.1 on OS X, I get this warning:
p.c:7: warning: wrong type argument to increment
for the following program:
#include <stdio.h>
int main(void)
{
int i[] = { 42 };
void *p = i;
printf("%p\n", p++);
return 0;
}
I am compiling it as:
$ gcc -Wpointer-arith p.c
Can you post your program, or post the result of compiling the above?