Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Is the mechanism to ensure effect safety is flow-insensitive ? #147

Open
Absoler opened this issue Apr 29, 2022 · 1 comment
Open

Is the mechanism to ensure effect safety is flow-insensitive ? #147

Absoler opened this issue Apr 29, 2022 · 1 comment

Comments

@Absoler
Copy link

Absoler commented Apr 29, 2022

csmith may generate this code:

int g_1;
int g_2;
int g_3[1]={ 0};
int* g_4 = &g_1;

……

for( int i=0; i<=2; i++){
g_3[g_2] = (*g_4)++;
g_4 = &g_2;
}

There is no problem until the second round, where *g_4 = g_2, and "g_3[g_2] = g_2++;" doesn't satisfy effect safety. But when generate this statement, we didn't know g_4 would point to g_2 in the future, and in Block::post_creation_analysis, it seems also no consideration of this situation.

@jxyang
Copy link
Member

jxyang commented Apr 29, 2022

Block::find_fixed_point takes a generated for-loop, and repeat the execution several times to make sure all statements in the for-loop body are defined.

I don't see a problem with the generated code. There is a sequence point between computing (*g_4)++ and the assignment to g_3[g_2]. So the fact that g_2 is modified before the sequence point doesn't endanger effect safety when g2 is read for the assignment after the sequence point.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants