I ran into this scenario a several years ago on the job. This is C99 code, but it will not compile.
It is a good practice to define and use variables as close to where they are needed and limit their scope as much as possible. My understanding is that this helps the compiler as registers optimization is easier if the life span of a variable is clearly define.
Why this code won't compile has to do with scope. A case statement will not create a private area of scope.Adding redundant braces fixes this problem:
What is happening here is that the variable accumulator in the first example is within the scope of the switch statement, where as with the second example, accumulator scope is limited to the case. The case/break statement does not define a block of scope.
I always use the redundant braces around case statements. However, when I discovered this problem, I was working for a company that didn't like the redundant braces and told me not to use them. While it was often difficult for me to abandon what I considered good coding practices, it was useful in finding "gotchas" caused by not-as-good practices. Various companies I have worked for have different policies on coding standards. Some were really good, but most were either non-existent or poor to the point of being useless. While developing coding standards can become a religious war I think it is more useful to have a good standard than no standard at all. This is especially useful for new programmers who generally have no common practices and could easily stumble on a problem like this.
Usually when I fail to accomplish some task I don't bother to write about it. However I think it might be interesting to write about some of my failed approaches to problems. Today I was looking into implementing a function to calculate the inverse sine function (arcsin) to arbitrary precision. I've done this in the past for log, exponential, sine, cosine, and pi. Right now, however, I have no inverse trigonometric functions.
The easiest way to implement any continuous function is to use it's Maclaurin series (the Taylor series centered at zero). This is easy to find for most functions, and here is the series for inverse sine:
This series suffers from a problem that many series do—it converges slowly when x is near 1 or -1. I typically address this by using the Taylor series with some different points to solve the problem. The first natural choice here is 1 and -1 since these are problem points. In order to calculate the Taylor series we need a general equation for the nth derivative. After some searching around I found this equation:
That's a mess, but we can now apply the Taylor series to this. Recall the Taylor series expansion for a function:
So we want to take the nth derivative for 1 and -1. However, it quickly becomes apparent that something bad is going to happen if we do this.
And that's a problem—one cannot divide by 0. Using -1 is no better because squaring negative one is just one, and results in the exact same problem.
Here my approach simply cannot be applied, and I will have to look into other methods to address the issue of slow converges. I have not taken any formal numerical analysis and lack the an understanding of the tools one would typically use to tackle this kind of problem. However that hasn't stopped me in the past. So I will need to think on it more.