That "int" is saying that your function "main" will return a signed integer.
That's what your operating system or C run time expects so it's the correct thing to do.
If you don't specify any type for a function the C compiler will by default assume you mean integer so that is also correct.
It's conidered bad practice to not specify types on functions so don't do it.
propgcc with option "-Wall" to turn on extra warnings, which you should always use, will generate a warning for this.
I always like to get the full signature of main correct, giving the parameters and their types like so:
That "int" is saying that your function "main" will return a signed integer.
That's what your operating system or C run time expects so it's the correct thing to do.
If you don't specify any type for a function the C compiler will by default assume you mean integer so that is also correct.
It's conidered bad practice to not specify types on functions so don't do it.
Don't you hate it when tools encourage bad practice?
It always stings eventually, like lemon juice in a paper cut. I hate that.
No, I think prof_braino was serious. Programming in Forth is like pouring lemon juice on a paper cut. But once you're done the antiseptic nature of lemon juice makes it all better, just like with Forth.
Now if he was actually referring to the Gnu C compiler, then I think he has the wrong impression. With warnings turned on the tools encourage good programming practice. However, the tools do allow for writing quick and dirty programs, where good programming practice can get in the way.
where "a" is a byte sized char and "b" is a 32 bit int without any complaint from the compiler. You may be meaning to do this but such implicit type conversions and potential loss of data are a source of bugs that many would frown on.
There are those who say that such programming is "bad practice" as you haven't written there that you mean to do that type conversion. Your intent may be unclear to whoever reads it next. There are a billion other things a C compiler does not check. Even with warnings wound up 11.
Having all warnings switched on is good practice, it can save you from a lot of debugging and help you deliver more reliable and portable code, but it does nothing to discourage many bad practices.
Of course we like it that way. Not too lax but not as mind numbingly strict as ADA.
Forth of course does not give a sh...
Mind you I'm not really complaining about C or Forth. My current fad is JavaScript which also does not care much what you do. Without jslint to check over your work it's a minefield.
I would always like to keep the power to point the gun at my foot if I want to:)
I presume you mean the fact that C can be a bit lax about things.
I guess you hate Forth then as checks nothing ever:)
Different, FORTH demands we always know what we are doing. We know to check this stuff.
In this case the tool allows you to do something bad under the assumption its fine. So many hours of my life have been wasted by bugs from average (or slightly below) programmers getting caught by this. And how they argue! They always get so defensive rather than just figure it out and fix it. Where are those tasers? I still feel the need to have one in hand when discussing this topic.
Anyway, we don't have to worry about forth, nobody uses it anyway.
... Gnu C compiler, then I think he has the wrong impression. With warnings turned on the tools encourage good programming practice. However, the tools do allow for writing quick and dirty programs, where good programming practice can get in the way.
Yes, that's half the problem. Folks think this is ok is the other half of the problem.
..."good programming practice can get in the way"... I love that. Pretty much says it all.
I don't particularly mind, aside from the "problem" parts that are the cause of all the problems we have to fix. Remove those, and the problems didn't have a change to happen.
Don't get me wrong, experts are aware and take care to resolve this stuff. But n00bs are not aware, and leave land mines and booby traps for themselves without knowing it. Most people are not experts, most are about average.
I think you misunderstood my comment about quick and dirty programs. I do this all the time when I need to write a quick program to test out something, or to generate text, etc. However, production code should always have warnings enabled, and it's also a good idea to treat warnings as errors. That's what we do where I work.
It's up to project management to establish coding guidelines and practices. Turning on warnings in the compiler should be part of the project coding requirements. If your project manager isn't doing that you should probably get a new project manager. If your programmers don't agree with turning on warnings you should hire new programmers.
I think you misunderstood my comment about quick and dirty programs. I do this all the time when I need to write a quick program to test out something, or to generate text, etc. However, production code should always have warnings enabled, and it's also a good idea to treat warnings as errors. That's what we do where I work.
And I'm sure you do great work. But others see this, and do the same, and forget to go back and enable the warning. I'm pretty sure I understand your comment completely. I have to deal with this constantly at the bug review meetings.
It's up to project management to establish coding guidelines and practices. Turning on warnings in the compiler should be part of the project coding requirements. If your project manager isn't doing that you should probably get a new project manager. If your programmers don't agree with turning on warnings you should hire new programmers.
Preaching to the choir, pal. I agree completely. Somehow, we keep getting stuck with the same project management, and the same programmers that forget to enable warning in the production code, because they turned them off "to test something" and it worked. On almost every project, at almost every company, just with different faces.
And I'm sure you do great work. But others see this, and do the same, and forget to go back and enable the warning. I'm pretty sure I understand your comment completely. I have to deal with this constantly at the bug review meetings.
You're still not getting it. I never turn off -Wall or -Werror in the product code that I'm working on. Why would I do that? The compiler options are set in makefiles that I normally wouldn't touch anyhow. If you have engineers that are checking in changes that are turning off warnings that should be addressed by their manager. If the engineering manager doesn't care about it, and his manager doesn't care, then there seems to be a serious management problem.
The quick and dirty code that I referred to earlier are small throw-away programs that are usually less than 20 lines. I write these almost every day or so to do things like generate an ASCII table when I don't have one handy, or process a text file to extract information.
Franny
Posts: 127
Comments
That's what your operating system or C run time expects so it's the correct thing to do.
If you don't specify any type for a function the C compiler will by default assume you mean integer so that is also correct.
It's conidered bad practice to not specify types on functions so don't do it.
propgcc with option "-Wall" to turn on extra warnings, which you should always use, will generate a warning for this.
I always like to get the full signature of main correct, giving the parameters and their types like so:
int main (int argc, char* argv[]) { ....Don't you hate it when tools encourage bad practice?
It always stings eventually, like lemon juice in a paper cut. I hate that.
Ah, gotcha!
I presume you mean the fact that C can be a bit lax about things.
I guess you hate Forth then as checks nothing ever:)
Now if he was actually referring to the Gnu C compiler, then I think he has the wrong impression. With warnings turned on the tools encourage good programming practice. However, the tools do allow for writing quick and dirty programs, where good programming practice can get in the way.
There are those who say that such programming is "bad practice" as you haven't written there that you mean to do that type conversion. Your intent may be unclear to whoever reads it next. There are a billion other things a C compiler does not check. Even with warnings wound up 11.
Having all warnings switched on is good practice, it can save you from a lot of debugging and help you deliver more reliable and portable code, but it does nothing to discourage many bad practices.
Of course we like it that way. Not too lax but not as mind numbingly strict as ADA.
Forth of course does not give a sh...
Mind you I'm not really complaining about C or Forth. My current fad is JavaScript which also does not care much what you do. Without jslint to check over your work it's a minefield.
I would always like to keep the power to point the gun at my foot if I want to:)
Different, FORTH demands we always know what we are doing. We know to check this stuff.
In this case the tool allows you to do something bad under the assumption its fine. So many hours of my life have been wasted by bugs from average (or slightly below) programmers getting caught by this. And how they argue! They always get so defensive rather than just figure it out and fix it. Where are those tasers? I still feel the need to have one in hand when discussing this topic.
Anyway, we don't have to worry about forth, nobody uses it anyway.
Strange... Visual Studio C++ warns about things like this... Maybe it's just GNU that doesn't?
Yes, that's half the problem. Folks think this is ok is the other half of the problem.
..."good programming practice can get in the way"... I love that. Pretty much says it all.
I don't particularly mind, aside from the "problem" parts that are the cause of all the problems we have to fix. Remove those, and the problems didn't have a change to happen.
Don't get me wrong, experts are aware and take care to resolve this stuff. But n00bs are not aware, and leave land mines and booby traps for themselves without knowing it. Most people are not experts, most are about average.
It's up to project management to establish coding guidelines and practices. Turning on warnings in the compiler should be part of the project coding requirements. If your project manager isn't doing that you should probably get a new project manager. If your programmers don't agree with turning on warnings you should hire new programmers.
And I'm sure you do great work. But others see this, and do the same, and forget to go back and enable the warning. I'm pretty sure I understand your comment completely. I have to deal with this constantly at the bug review meetings.
Preaching to the choir, pal. I agree completely. Somehow, we keep getting stuck with the same project management, and the same programmers that forget to enable warning in the production code, because they turned them off "to test something" and it worked. On almost every project, at almost every company, just with different faces.
The quick and dirty code that I referred to earlier are small throw-away programs that are usually less than 20 lines. I write these almost every day or so to do things like generate an ASCII table when I don't have one handy, or process a text file to extract information.