[PATCH] Possible arithmetic with NULL pointer or test "stack_base_ptr != NULL" is irrelevant.
Hi,
Of course, I don't know if it's the best solution, but it's the most obvious.
Or the test at line 3326 is irrelavant.
\backend\tcop\postgres.c
if (stack_depth > max_stack_depth_bytes &&
stack_base_ptr != NULL)
return true;
Otherwise, if is relevant, substraction with NULL pointer is technically,undefined behavior..
Best regards.
Ranier Vilela
--- \dll\postgresql\a\backend\tcop\postgres.c 2019-11-23 13:19:20.000000000 -0300
+++ postgres.c 2019-11-24 11:13:34.131437500 -0300
@@ -3303,7 +3303,10 @@
/*
* Compute distance from reference point to my local variables
*/
- stack_depth = (long) (stack_base_ptr - &stack_top_loc);
+ if (stack_base_ptr != NULL)
+ stack_depth = (long) (stack_base_ptr - &stack_top_loc);
+ else
+ stack_depth = (long) &stack_top_loc; /*
* Take abs value, since stacks grow up on some machines, down on others
Attachments:
postgres.c.patchapplication/octet-stream; name=postgres.c.patchDownload
--- \dll\postgresql\a\backend\tcop\postgres.c 2019-11-23 13:19:20.000000000 -0300
+++ postgres.c 2019-11-24 11:13:34.131437500 -0300
@@ -3303,7 +3303,10 @@
/*
* Compute distance from reference point to my local variables
*/
- stack_depth = (long) (stack_base_ptr - &stack_top_loc);
+ if (stack_base_ptr != NULL)
+ stack_depth = (long) (stack_base_ptr - &stack_top_loc);
+ else
+ stack_depth = (long) &stack_top_loc;
/*
* Take abs value, since stacks grow up on some machines, down on others
Ranier Vilela <ranier_gyn@hotmail.com> writes:
Of course, I don't know if it's the best solution, but it's the most obvious.
Or the test at line 3326 is irrelavant.
\backend\tcop\postgres.c
if (stack_depth > max_stack_depth_bytes &&
stack_base_ptr != NULL)
return true;
Otherwise, if is relevant, substraction with NULL pointer is technically,undefined behavior..
[ shrug... ] Stack overflow in itself is outside the realm of the C
specification. Also, if you want to get nitty-gritty about it,
I believe that the standard only promises defined results from the
subtraction of two pointers that point to elements of the same array
object. So the change you propose isn't going to make it any closer
to adhering to the letter of "defined-ness". In practice, this code
works fine on every platform that Postgres is ever likely to support,
so I see no need to change it.
regards, tom lane
In practice, this code
works fine on every platform that Postgres is ever likely to support,
so I see no need to change it.
Of course, I trust your judgment.
Thank you for the review.
Best regards,
Ranier Vilela