Hello, and welcome back.
In this lecture, I just want to go over some common compilers and warnings.
We talked about some of the common c problems.
But sometimes you don't even know you have those errors in your program
when the compiler is trying to tell you that.
Compiler errors and warnings tend to be really cryptic to new programmers.
They may be telling you that you're missing a semicolon, but it says unreachable end of statement.
And for somebody new, they might not even know what that means.
So it takes a lot of practice in writing a lot of code and
to decipher some of these compiler warnings over time.
But I'd like to give you a heads up before that.
So some of the common problems that you saw in the previous lecture,
I'm going to actually describe some of the compiler warnings and errors and what it will actually say.
It's very, very important to tell you to understand what the compiler is telling you.
If the compiler is telling you that errors, but you don't understand that error,
it's going to take you much longer to fix that code.
But if you see the error and you know exactly what it's saying
you can then go and fix it in no time.
I remember, I would be in the lab when I first started programming,
and I would be missing a semicolon,
something very common. And the compiler would be telling me I'm missing a semicolon,
but I wouldn't know that,
it would just say unreachable end of statement, and I would be like,
what does that mean, what is a statement. I would be very confused.
So that's why I wanted to give you some tips on what the compiler is actually trying to tell you.
So it's very hard to understand what the compiler is complaining about.
To decipher these messages
are sometimes very confusing.
So you need to understand these compiler errors in order to fix them, pretty basic.
And the compiler is doing half the job for you.
It's checking the syntax, telling you exactly what's wrong,
so you should use that to your advantage.
But sometimes it's difficult to understand exactly what it's saying especially
if you're new and you don't understand some of the terminology.
The compiler makes decisions about how to translate your code
that the programmer has not written in the code.
This is convenient for the program and the compiler,
so that it can be written more succinctly.
And only expert programmers take advantage of this feature.
So what I'm telling you is when you compile,
you should always use the dash wall option.
This is going to turn on everything.
So sometimes a more advanced feature is you'll actually
take some stuff out,
have the translation a little bit more efficient.
But when you add that,
you cause the program to be compiled differently.
And as a result, you may have warnings in your code that you don't know about.
So the reason I tell you that is you always want to compile with a certain option,
which is the dash wall option.
And you actually by default that's turned on in code blocks.
And this will notify you of all cases
where the compiler is doing things that you don't know about.
It also will turn on all warnings,
give you a lot of information, it's very useful compiler option.
Once you have that option on, then you can try to
help you better understand some what the compiler is telling you.
So the compiler is going to show you
two types of problems. One is an error.
This will actually prevent the creation of the program.
You have a syntax error and the program cannot be compiled.
No executable work recreated
and. Usually, when you see errors from the compiler,
you always want to focus on that first error.
That's the most reliable error
because some of the other errors may be a result of that first error.
So always focus on that first error. Fix the errors at the top first,
and then compile again and see if the other errors go away.
Warnings. Warnings are messages that the compiler shows about
for special situations and in which some type of anomaly has been detected.
They're non-fatal errors. So the executable will be created.
But it's still something that you should fix.
A warning is there for a reason. You're either doing something incorrectly
or it could cause a problem in the future.
So you want to always fix all of your warnings.
And by compiling with the dash wall option,
you do not consider the program correct until all warnings have been eliminated.
So the compilation will not fail. This is why I tell you to use this option
as well as seeing everything that's going on by the compiler.
So some of the most common compiler messages that you'll encounter,
and this will be directly related to some of the most common c problems that
we mentioned earlier.
If a variable is undeclared, you'll see this message variable undeclared
first using this function.
This is one of the most common and usually easier to detect.
And then it will also display the symbol
before this message.
It will basically say that
you're trying to use this variable, but you never actually declared it.
We know that when you declare a variable, you specify the data type.
You can't just signing data to variables that don't exist.
A warning implicit declaration of function, this is related to the function declarations.
It's when you're trying to call a function,
but if the function doesn't have any implementation associated. You didn't include the header,
or you didn't declare it. So it doesn't know where it is, and it doesn't know
how the function is declared, it doesn't know the arguments, it doesn't know the return value.
Has no information about the function itself?
To solve this, always declare a function prototype at the top.
Another warning which is it will say warning control reaches end of non-void function,
this will happen when a function has been defined as returning a result it's non-void,
but there's no return statement included in the function.
So you forgot to return the data.
Either the function is incorrectly defined where you have to remove the
data type before the function declaration,
or you forgot to add that return statement. One of the other has to be
changed in order to fix this warning.
But you see how this is a warning. You can still compile there,
but man that could really cause cut problems in your program.
If you're expecting a function to return something and it doesn't so you want to fix your warnings
unused variable another common warning.
This is printed by the compiler when a variable is declared, but it's never used.
You shouldn't be declaring a variable if you don't use it,
so remove that declaration.
I tend to get these quite a bit when I do some of my demos
because I leave in variables that I never use.
Or when I was demonstrating how to declare a variable
and then I compiled it to show you that compiled, I would get a warning saying it was never used.
So that that's okay because I was demonstrating something. But
remove your variables if they're not being used. No need to declare.
Undefined reference to. This happens in the linking phase.
So remember the compiler or the compilation phase, it will compile.
First, it will run the preprocessor, then it will generate the object files
and then it will take those object files and link them together to make a complete program.
So during the linking phase,
it needs to resolve any external dependencies.
Or specifically any functions that you're calling,
they need to be implemented somewhere.
So if it doesn't have that object file, it's going to give you this problem.
You're trying to invoke a function, but we don't have the code for it.
So you have to either
make sure you link to this file.
Usually the link will happen for you,
but in GCC you can just do the dash l option
to add the linking file. So if you're using a function in the math header file,
but you're not linking to the math object file, you're going to get this error.
And it also happens if you have user defined
and you didn't include a c source file.
So you have multiple c source files.
One of the c source files is implementing this function.
Another c source file is including the header
and calling it,
but you never compiled the other c source file that has the implementation,
you'll see this error.
So make sure you bring in that source file, make sure you bring in
any standard library source files if you need to explicitly usually, you don't have to do that.
Another common error this is when conflicting types for.
This is when you actually have defined or declared a function prototype
and then when you went to implement it, it wasn't the same as how you declared it.
So for example, the prototype has a result type and name of parenthesis for the parameters
and then a semicolon.
And then when you define the implementation,
you have a different actual function header.
You have a different return type or you have a different number of parameters.
And this is saying well, hey, you have this one
function declaration. And then when you go to implement it down below, it's completely different.
So there's a mismatch.
And this will actually show you on the line that the conflict appears
in the previous definition that caused the contradiction.
So in the implementation is usually where it shows you the line
because usually you declare your functions at the top.
Runtime errors. Runtime errors are problems in your code
that happen when you run the program, not when you compile it.
So these are usually
crashes or they're the non-fatal errors
where you're array out of bounds or something like that.
It's when the program is running, you have some kind of logic error.
So the execution of c programs may terminate abruptly with a crash
when a runtime error is detected, something it can't handle. There's a memory corruption,
like I mentioned.
Out of bounds errors usually cause programs to crash.
Usually, what you'll see is segmentation fault.
And segmentation fault doesn't really tell you anything.
So typically what you want to do to further diagnose this problem is look at the call stack,
as I mentioned
before the program crashes stepping line by line
to see what line is causing the crash.
You can get the call stack if there's a core file, which I mentioned earlier.
And then from the call stack, you can see what line is crashing.
Or better yet, run the debugger, step line by line
and then when you execute a line, debugger, you'll see the program crash and you can identify it that way.
So these are just again some more tips
on compiler errors and warnings and messages and how to interpret them.
There's actually
links online. Or if you do google,
it will tell you every single compiler error and warning
that can be produced and it will actually give a definition of
why this was produced it is and what was
the problem essentially.
Because again, those compile errors can be very cryptic.
And even the one word said
unreachable control. You know from that description necessarily
unless you had experience that, that means oh you never return something from a function.
But if you do, one of the best ways to find and fix problems
in your program when you have compiler errors and you don't understand that compiler,
google it. And typically what will happen is you'll go to stack overflow.
And it will tell you hey this is your error this is how you solve
it. I do that to this day.
I've been programming in c for 15 years, but there are still times
when I encounter things, and I'm like what exactly does this mean.
And I'll google it, I'll actually take the compiler, put it in quotes
and it will tell me exactly what's happening.
Stack overflow is a really, really good website.
And it can really save a lot of time in the
debugging process. Don't just try to guess when you see compilers or warnings.
That compiler is trying to tell you something and it will pinpoint exactly what's going on.
So if you understand it, you're going to be able to fix your problem much, much quicker.
And if it's not something you're familiar with,
go to stack overflow or go to a website that describes all of them
and you can decipher it that way.
I hope this was helpful. Thank you.