You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When translating C code that uses setjmp/longjmp along with volatile variables, c2rust produces Rust code that does not preserve the expected behavior seen in the original C code, particularly with regard to variable state post-longjmp.
Source C code
#include<stdio.h>#include<stdlib.h>#include<setjmp.h>jmp_bufbuf;
voidtest_function() {
staticintcall_count=0;
call_count++;
printf("test_function called %d time(s)\n", call_count);
if (call_count==2) {
longjmp(buf, 1);
}
}
intmain(void) {
volatileintloop_var=0;
if (setjmp(buf) ==0) {
for (loop_var=0; loop_var<5; loop_var++) {
printf("loop_var before function call: %d\n", loop_var);
test_function();
printf("loop_var after function call: %d\n", loop_var);
}
} else {
printf("Returned via longjmp with loop_var: %d\n", loop_var);
}
return0;
}
Output by gcc and clang
loop_var before function call: 0
test_function called 1 time(s)
loop_var after function call: 0
loop_var before function call: 1
test_function called 2 time(s)
Returned via longjmp with loop_var: 1
The C program outputs the value of loop_var as 1 after the longjmp is triggered because the volatile keyword ensures the variable is updated directly in memory, and longjmp restores this correctly.
loop_var before function call: 0
test_function called 1 time(s)
loop_var after function call: 0
loop_var before function call: 1
test_function called 2 time(s)
Returned via longjmp with loop_var: 0
Observation
The translated Rust code fails to preserve the updated value of loop_var post-longjmp. Instead, it incorrectly retains the initial value (i.e., 0 instead of 1), indicating a potential issue with how volatile access or setjmp/longjmp semantics are handled in the translation. This discrepancy may stem from how c2rust translates the volatile qualifier and the semantics of setjmp/longjmp.
The text was updated successfully, but these errors were encountered:
Yeaseen
changed the title
Inconsistent Behavior with Translated setjmp/longjmp and volatile Usage
Modification to volatile variable between setjmp/longjmp not retained in translated rust code
Nov 24, 2024
Description
When translating C code that uses
setjmp
/longjmp
along withvolatile
variables,c2rust
produces Rust code that does not preserve the expected behavior seen in the original C code, particularly with regard to variable state post-longjmp
.Source C code
Output by gcc and clang
The C program outputs the value of loop_var as 1 after the longjmp is triggered because the volatile keyword ensures the variable is updated directly in memory, and longjmp restores this correctly.
godbolt view
Translated Rust code
Click here to view the translated rust code
Translated Rust code's output
Observation
The translated Rust code fails to preserve the updated value of loop_var post-longjmp. Instead, it incorrectly retains the initial value (i.e.,
0
instead of1
), indicating a potential issue with howvolatile
access orsetjmp/longjmp
semantics are handled in the translation. This discrepancy may stem from howc2rust
translates thevolatile
qualifier and the semantics ofsetjmp/longjmp
.The text was updated successfully, but these errors were encountered: