News for hackers. Stuff that matters.
Re:“It is never a compiler error” by topspin on Tuesday November 14, 2017 @06:14PM (#15700164)
I had some bad experiences with visual studio's compiler recently (last two years.) I was working on OpenGL code and discovered a couple different constructs that would crash the compiler. The first time I figured it was a fluke, but by the third distinct case I became rather alarmed; the code should have produced errors, not compiler failures. I concluded that MS's compiler is decidedly less robust than GCC and clang; I've seen one compiler crash from a release GCC compiler in the last 10-odd years.
Re:“It is never a compiler error” by dvtv75 on Tuesday November 14, 2017 @07:22PM (#15700531)
When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there.

Eventually, someone (Natalie) moved the comment below the assignment, and it worked normally. I tried putting it back above, and it wouldn't compile. Can't remember what happened if I left the moved comment in place and put another above the assignment. I found two like that - one in CodeWarrior, one in Turbo Pascal a few years before that simply returned "error 0: no error."

It wasn't anything complicated in either case, just very basic stuff.

Re:“It is never a compiler error” by jfultz on Tuesday November 14, 2017 @11:14PM (#15701412)
I've used a lot of C/C++ compilers over the years, and the two compilers marked in my memory as having enough bugs to be noticeable and disturbing were Visual C++ 4.1 (so notably bad that MS essentially apologized for its screwup and conceded that 4.2 was largely about fixing 4.1's problems) and CodeWarrior for Mac (pretty much any version, I think...I never tried the Windows version, but the thought of it makes me shiver).

CW had a pretty nice environment to develop in compared to its contemporary competitors, but it just didn't have a solid compiler.

Re:“It is never a compiler error” by animal531 on Wednesday November 15, 2017 @05:50AM (#15702867)
This was pretty common in Turbo Pascal, your program would just suddenly stop working when you added a new blank line. (It would compile, but something would usually be off in the output causing the program to fail or crash).

Removing the offending line or adding a different mix of blanks/instructions would get you back to a working state again. Very frustrating.

Re:“It is never a compiler error” by nv-vn on Tuesday November 14, 2017 @07:47PM (#15700635)
Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like:

    int x = 0;
    int y = 2;
    DoSomething(); // Didn't run with x before y
I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changing some configuration (different compiler version or flags I think).

Only other time I bumped into it was in Idris, which is to be expected frankly.

Re:“It is never a compiler error” by ethbro on Tuesday November 14, 2017 @11:39PM (#15701495)
From what I remember of a deep dive post I read on this once, the ordering type bug / no-bug situations tend to be the result of incorrect optimizations. Changing the ordering will sometimes make the code look just different enough to go down a different (not bugged) optimization path.

If you ever catch them still there with a "no optimizations" flag, then that's a pretty serious bug!

Re:“It is never a compiler error” by throwaway613834 on Tuesday November 14, 2017 @07:31PM (#15700564)
Any chance the line endings were different and that was somehow messing it up?
Re:“It is never a compiler error” by MichaelGG on Tuesday November 14, 2017 @07:17PM (#15700508)
Yeah working on FreeSWITCH, upgrading to VS2015 and we encountered an issue with a long series of else branches. Ended up having to split and nest for the code to compile.