Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I know there have been a number of discussions of whether break and continue should be considered harmful generally (with the bottom line being - more or less - that it depends; in some cases they enhance clarity and readability, but in other cases they do not).
Suppose a new project is starting development, with plans for nightly builds including a run through a static analyzer. Should it be part of the coding guidelines for the project to avoid (or strongly discourage) the use of continue and break, even if it can sacrifice a little readability and require excessive indentation? I'm most interested in how this applies to C code.
Essentially, can the use of these control operators significantly complicate the static analysis of the code possibly resulting in additional false negatives, that would otherwise register a potential fault if break or continue were not used?
(Of course a complete static analysis proving the correctness of an aribtrary program is an undecidable proposition, so please keep responses about any hands-on experience with this you have, and not on theoretical impossibilities)
Thanks in advance!
My immediate reaction is that the hoops you'd have to jump through to avoid break and continue would probably hurt the code overall, and make static analysis (or much of anything else) considerably more difficult.
It'll depend a bit on the exact sort of code you're dealing with though. Just for example, if you have something that would really be best implemented as a switch statement, a prohibition against break would essentially force you to use nested if/elses which would make the code much more difficult to analyze correctly, and depending on the circumstances, would be very likely to negatively impact the output code as well.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
When I compile programs in Ada, I typically notice a longer compile time for code of similar length and of similar content to programs written in C or C++.
While it is true that it comes down to the compiler and system to determine compile time the Ada compilation generally takes longer. Is this process radically different than the compile/link process of C or C++. Does it consist of different stages?
What about the Ada compilation process makes the compilation take longer than ?
It is all about the amount of time and effort put into making the compiler fast.
Compilers that have a broader scope tend to have more money to invest in making fast; however, sometimes there are other elements at stake. For example, the details of a compiler might include static type checking, various "extra" correctness checks, and other items (programming contract compliance, code quality, etc) that might adjust the compile time.
Ada tends to have had less money thrown at its compiler, and it is likely a slightly more complex language to parse than C. Both of these factors lend themselves to making it likely that its compiler will be slower.
Note that speed of compilation has little to do with the "quality" of the language. While C might have a larger footprint, Ada has made its mark on the programming world in other ways.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am prone to writing code like this:
if (*t) while (*++t);
It reads: if string t does not start with /0, then move to the end.
Note the while loop has no body, so the semicolon terminates it.
I'd like to know if it is good practice to do this? Why and why not?
C is one of the oldest popular language in use today. I believe there's a good chance of finding one or more established style guide(s).
I know that Google has one for their C++ open source projects - http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Can anyone point me to resources on why or why not write code in certain manner?
Usually it is a good practice to write separate lines of code. Like in case of large pieces of code, debugging is clearer if we write code in separate lines.
It depends! Who is going to have to read and maintain this code? Coding standards exist for two major reasons:
To make code more readable and maintainable. When there are multiple developers, it makes code more consisent (which is more readable).
To discourage common errors. For example, a standard might require putting literals first in conditionals to discourage the assignment-as-comparison bug.
How do these goals apply to your specific code? Are you prone to making mistakes? If this is Linux kernel code, it's a lot more tolerable to have code like this than if it's a web app maintained by entry level programmers.
It reads: if string t does not start with /0, then move to the end.
Then consider putting a comment on it that says that.
Surprisingly - it is usually more expensive to maintain code over time than to write it in the first place. Maintenance costs are minimized if code is more readable.
There are three audiences for your code. You should think of how valuable their time is while you are formatting:
Fellow coders, including your co-workers and code-reviewers. You
want these people to have a high reputation of you. You should write code that is easily understandable for them.
Your future self. Convoluted code may be obvious while you are
writing it, but pick it up again in two weeks, and you will not
remember what it means. The 'concise' statement that you wrote in 10
minutes will someday take you 20 minutes to decipher.
The Optimizing Compiler, which will produce efficient code no matter
whether your line is concise or not. The compiler does not care - try to save time for the other two. (Cue angry remarks about this item. I am in favor of writing efficient code, but concise styles like the one we are describing here will not affect compiler efficiency.)
Bad practice, because not easy to parse. I'd do
while (*t) ++t;
and let the compiler do the tiny bit of optimization.
The textual translation of it reads even shorter than yours
advance t until it points to a 0
Although you can write some pretty clever code in one line in C, it's usually not good practice in terms of readability and ease of maintenance. What's straightforward for you to understand may look completely foreign to someone maintaining your code in future.
You need to strike a balance between conciseness and readability. To this end, it's usually better to separate the code out so each line does one thing.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My anti-virus identifies the compiled ".exe" of this source as a virus
"Gen: Variant:Graftor" . Can anybody explain why?
void main()
{
float x=3.0/7.0;
double y=3.0/7.0;
int a= (x==y);
}
Well, unmanaged / native programs can pose security risks and probably your antivirus marked this as such. Antiviruses use heuristics - so the algorithms are aproximate, they tend to work on a "best effort" idea, and in case of antiviruses "false positives" like your sample is preferable to missing actual viruses.
Another possibility is the way you compiled your program, there are a lot of compiler optimization and some are related to security - so your program randomizes certain parts of the memory etc. Maybe the antivirus looks at how a C program is compiled and yours has no security flags turned on? Hmm...
About Generic Detections
Unlike more traditional detections (also known as signatures or single-file detections) a Generic Detection does not identify a unique or individual malicious program. Instead, a Generic Detection looks for broadly applicable code or behavior characteristics that indicate a file as potentially malicious, so that a single Generic Detection can efficiently identify dozens, or even hundreds of malware.
This is a false positive. These sometimes occur in every antivirus product because of the complexity of present-day malware and file compression/protection utilities that are used on both malware and legitimate software.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to use Splint as code analyzer for our C code base. But we never tried Splint tool before so we want your input on it's benifts, pros and cons.
Lint tools are useful for finding common problems and errors that code reviews tend to miss. My opinion is that you have nothing to lose when doing static code analysis. The only down side is that you might get a lot of false positives or warnings that might be unimportant (i.e. coding style recommendation). You just have to develop good filtering skills. Static analyzers might also not catch everything, but hey it is better than nothing.
Here is a white paper from the SANS institute that might interest you:
http://www.sans.org/reading_room/whitepapers/securecode/secure-software-development-code-analysis-tools_389
Read this blog post and these slides for a quick overview of what it can do for you.
Splint excels at making your code more idiomatic (and therefore easier to read, for various compilers to parse, more portable, and easier to refactor). Splint can find subtle bugs such as implicit casts between ints and floats. Splint tracks down memory leaks and other security vulnerabilities.
Try it: splint hello.c.
As waffleman suggested static analysers do produce a lot of false alarms. I have found Prevent to give better alarms than Sparrow. Those are two we use for static analysis.
An example of a typical false alarm and good alarm is:
bar (char **output)
{
*output = malloc(100);
}
foo()
{
char *output=NULL;
bar(&output)
}
In function bar it would report memory leak for the pointer output. In the function foo it reports NULL dereference when the function bar is called. But nevertheless its a choice between finding a true alarm between 100s of false alarms.
So we can find memory leaks which can be missed during code reviews. Prevent license is expensive and once a alarm is marked false it doesnt appear in the subsequent analysis. Hence you have to find if Splint does the same.
The tool looks for pattern that could possibly be errors. The advantage is that the tool may find latent bugs and the disadvantage is that it may find a whole bunch on false positives as well.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Just out of curiosity, assuming there exists a software life form. How would you detect him/her? What are your criteria of figuring out if something/someone is intelligent or not?
It seems to me that it should be quite simple to create such software once you set the right target (not just following a naive "mimic human->pass Turing Test" way).
When posting an answer try also finding a counter example. I have real difficuly inventing anything consistent which I myself agree with.
Warmup
First we need to understand what a life form is.
Take this explanation, for example:
An entity which exists and tries to continue its existence through nourishment or procreation.
If we accept this explanation then in fact many programs represent a life form.
They exist, that's obvious. They attempt to continue their existence through opening child processes, surviving in persistent data storages and continuing the next day.
So, here we are, among digital life forms around us.
On the other hand, there's the idea of evolving and being sentient.
With evolving, it's easy. Many programs have been written to be able to modify their body to adapt to certain scenarios. Computer viruses are first examples of that.
With sentience, it is a different story. An entity needs to be aware of its existence, understand itself and the environment around it, also take active decisions on its life activities.
A computer program has nothing of that kind. In fact, if it still applies, the scientists haven't figured out the definition of "being aware of itself" and consciousness. So until we know what that means, we can't attribute that quality to an entity or the other way around, to take it away.
The bottom line is, you can argue a computer program to be a life form, but it does not qualify for a sentient being.
Thinks humanly, acts humanly.
OR
Thinks rationally, acts rationally.