4 ms·

You found one compiler bug after moving to a new version of your compiler/runtime. Not unheard of, to be honest. Now think of all the common bugs you _didn’t_ g

by elteto 3y ago

You found one compiler bug after moving to a new version of your compiler/runtime. Not unheard of, to be honest. Now think of all the common bugs you _didn’t_ get in all these years because you wrote your code in Java instead of C.

marginalia_nu 3y ago
I'm mostly referring to the fact that half the debugging was spent on a wild goose chase combing through integer types. With unsigned integers, type aliases and pointer types this would have been a lot easier to keep track of. The limited range of primitive integers also means static analysis is basically impossible. Assing a pointer to an integer or vice versa and that's a code smell. Assign an integer to an integer and the compiler is none the wiser.
- elteto 3y ago
  I think you went on a wild goose chase _because_ it was a compiler bug. You never assume "it's the compiler" on the first try, so you go looking for bugs in your code that don't exist. Java's integer types maybe didn't help in this situation, agreed. And the lack of unsigned integers is harebrained, agreed too. But I think you wouldn't have had an easier time in C. You say that the lack of unsigned types in Java is in part responsible for some of your wasted time. But C has notoriously bad integer types and promotion rules, especially for interactions between signed and unsigned! If you had found this same bug in C code (a compiler bug), your first instinct as a C programmer might have been "it's probably some signed/unsigned interaction issue". And you'd also have wasted time trying to find a non-existent issue in your code.
  - kragen 3y ago
    entirely by coincidence, i have spent a substantial part of the night finding signed/unsigned bugs in my c code by carefully reading through the disassembly, so i endorse this message
  - int_19h 3y ago
    C# is perhaps a better example, as it does have unsigned integer types, but it also does the sensible thing by e.g. promoting mixed int/uint operands to long. If you try to assign the result of such an expression to either int or uint without casting, it's a compile-time error.

by elteto 3y ago

marginalia_nu 3y ago

I'm mostly referring to the fact that half the debugging was spent on a wild goose chase combing through integer types. With unsigned integers, type aliases and pointer types this would have been a lot easier to keep track of. The limited range of primitive integers also means static analysis is basically impossible. Assing a pointer to an integer or vice versa and that's a code smell. Assign an integer to an integer and the compiler is none the wiser.

elteto 3y ago
I think you went on a wild goose chase _because_ it was a compiler bug. You never assume "it's the compiler" on the first try, so you go looking for bugs in your code that don't exist. Java's integer types maybe didn't help in this situation, agreed. And the lack of unsigned integers is harebrained, agreed too. But I think you wouldn't have had an easier time in C. You say that the lack of unsigned types in Java is in part responsible for some of your wasted time. But C has notoriously bad integer types and promotion rules, especially for interactions between signed and unsigned! If you had found this same bug in C code (a compiler bug), your first instinct as a C programmer might have been "it's probably some signed/unsigned interaction issue". And you'd also have wasted time trying to find a non-existent issue in your code.
- kragen 3y ago
  entirely by coincidence, i have spent a substantial part of the night finding signed/unsigned bugs in my c code by carefully reading through the disassembly, so i endorse this message
- int_19h 3y ago
  C# is perhaps a better example, as it does have unsigned integer types, but it also does the sensible thing by e.g. promoting mixed int/uint operands to long. If you try to assign the result of such an expression to either int or uint without casting, it's a compile-time error.