4 ms·

> why not compile-time error for reading memory that hasn't been written https://en.wikipedia.org/wiki/Rice%27s_theorem?useskin=vector https://en.wikipedia.org

> why not compile-time error for reading memory that hasn't been written https://en.wikipedia.org/wiki/Rice%27s_theorem?useskin=vector https://en.wikipedia.org/wiki/Rice%27s_theorem?useskin=vecto...

TheCoelacanth 1y ago
A compiler doesn't have to accept all possible programs. If it can't prove that a variable is initialized before being read, then it can simply require that you explicitly initialize it.
- dooglius 1y ago
  Sure, but then not accepting many programs would be the answer to parent's question "why not"
  - jerf 1y ago
    Not accepting many C programs, maybe. It's pretty easy to create a language where declaration is initialization of some sort, as evidenced by the large number of languages in common use where, one way or another, that's already the case. This isn't some whacko far out idea. Most languages already today don't have any way (modulo "unsafe", or some super-carefully declared and defined method that is not the normal operation of the language) of reading uninitialized memory. It's only the residual C-likes bringing up the rear where this is even a question. (I wouldn't count Odin's "explicitly label this as not getting initialized"; I'm talking about defaults being sharp and pointy. If a programmer explicitly asks for the sharp and pointy, then it's a valid choice to give it to them.)
    - dooglius 1y ago
      I think we are in agreement? Odin works the way you describe, and GP in response expressed a preference that the compiler instead fail at compile time if it detected that memory had not been explicitly initialized; my response was to explain why this is not (in the general case) feasible.
      - reverius42 1y ago
        It may not be feasible in the general case by changing the compiler, but it's definitely feasible in the general case by changing the language. If you can't specify an uninitialized variable syntactically then you don't have to analyze whether it exists semantically.
trealira 1y ago
Somehow Rust is able to do it, though. Is it really that hard for compilers to do flow analysis to detect and forbid uses of uninitialized variables? Not even being sarcastic, I genuinely would like to know why more languages don't do this.
- trealira 1y ago
  This is a self-response, but I've thought of a case where it might be fairly difficult for a compiler to prove a variable is always initialized, because of the use of pointers. Take this function to copy a linked list in C: struct node { struct node *next; int data; }; struct node *copy_list(struct node *list_node) { struct node *new_list, **indirect; indirect = &new_list while (list_node != NULL) { // Pretend malloc can't fail struct node *np = malloc(sizeof(*np)); np->data = list_node->data; *indirect = np; indirect = &np->next; list_node = list_node->next; } *indirect = NULL; return new_list; } The variable "new_list" is always initialized, no matter what, even though it's never explicitly on the left hand side of an assignment. If the while loop never ran, then indirect is pointing to the address of new_list after the loop, and the "*indirect = NULL;" statement sets it to NULL. If the loop did run, then "new_list" is set to the result of a call to malloc. In all cases, the variable is set. But it feels like it would be hard for something that isn't a formal proof assistant to prove this. The equivalent Rust code (unidiomatic as it would be to roll your own linked list code) would require you to set "new_list" to be None before the loop starts.
- steveklabnik 1y ago
  The flow analysis isn't particularly hard, but lots of languages simply don't do it because they don't allow uninitialized variables in the first place. Given null is a pretty common concept, you just say they're initialized but null, and you don't even need to do the analysis at all.
  - trealira 1y ago
    Thanks for explaining. I guess that makes sense, but it surprises me: language implementors choosing to do the slightly worse option not due to technical limitations or historical baggage, but just because it's easier. I thought only C was like that. That's not to insult any of them; it's not like I'm the maintainer of a compiler for a major programming language.

> why not compile-time error for reading memory that hasn't been written https://en.wikipedia.org/wiki/Rice%27s_theorem?useskin=vector https://en.wikipedia.org/wiki/Rice%27s_theorem?useskin=vecto...

TheCoelacanth 1y ago

A compiler doesn't have to accept all possible programs. If it can't prove that a variable is initialized before being read, then it can simply require that you explicitly initialize it.

dooglius 1y ago
Sure, but then not accepting many programs would be the answer to parent's question "why not"
- jerf 1y ago
  Not accepting many C programs, maybe. It's pretty easy to create a language where declaration is initialization of some sort, as evidenced by the large number of languages in common use where, one way or another, that's already the case. This isn't some whacko far out idea. Most languages already today don't have any way (modulo "unsafe", or some super-carefully declared and defined method that is not the normal operation of the language) of reading uninitialized memory. It's only the residual C-likes bringing up the rear where this is even a question. (I wouldn't count Odin's "explicitly label this as not getting initialized"; I'm talking about defaults being sharp and pointy. If a programmer explicitly asks for the sharp and pointy, then it's a valid choice to give it to them.)
  - dooglius 1y ago
    I think we are in agreement? Odin works the way you describe, and GP in response expressed a preference that the compiler instead fail at compile time if it detected that memory had not been explicitly initialized; my response was to explain why this is not (in the general case) feasible.
    - reverius42 1y ago
      It may not be feasible in the general case by changing the compiler, but it's definitely feasible in the general case by changing the language. If you can't specify an uninitialized variable syntactically then you don't have to analyze whether it exists semantically.

trealira 1y ago

Somehow Rust is able to do it, though. Is it really that hard for compilers to do flow analysis to detect and forbid uses of uninitialized variables? Not even being sarcastic, I genuinely would like to know why more languages don't do this.

trealira 1y ago
This is a self-response, but I've thought of a case where it might be fairly difficult for a compiler to prove a variable is always initialized, because of the use of pointers. Take this function to copy a linked list in C: struct node { struct node *next; int data; }; struct node *copy_list(struct node *list_node) { struct node *new_list, **indirect; indirect = &new_list while (list_node != NULL) { // Pretend malloc can't fail struct node *np = malloc(sizeof(*np)); np->data = list_node->data; *indirect = np; indirect = &np->next; list_node = list_node->next; } *indirect = NULL; return new_list; } The variable "new_list" is always initialized, no matter what, even though it's never explicitly on the left hand side of an assignment. If the while loop never ran, then indirect is pointing to the address of new_list after the loop, and the "*indirect = NULL;" statement sets it to NULL. If the loop did run, then "new_list" is set to the result of a call to malloc. In all cases, the variable is set. But it feels like it would be hard for something that isn't a formal proof assistant to prove this. The equivalent Rust code (unidiomatic as it would be to roll your own linked list code) would require you to set "new_list" to be None before the loop starts.
steveklabnik 1y ago
The flow analysis isn't particularly hard, but lots of languages simply don't do it because they don't allow uninitialized variables in the first place. Given null is a pretty common concept, you just say they're initialized but null, and you don't even need to do the analysis at all.
- trealira 1y ago
  Thanks for explaining. I guess that makes sense, but it surprises me: language implementors choosing to do the slightly worse option not due to technical limitations or historical baggage, but just because it's easier. I thought only C was like that. That's not to insult any of them; it's not like I'm the maintainer of a compiler for a major programming language.