On Thu, Oct 7, 2021 at 3:25 PM 余生与君 <[email protected]> wrote:
> > where p is a dummy, unused variable
> No. p here shadows the global variable with the same name local
> variable so the following context (scope) will use this local variable
> instead of the global one.
Aha...
The problem here is that even though later uses of "p" in this block
where we use ASSIGN_CONST_PTR() macro will use the local "p" pointer,
when we exit the block, the following uses will refer to the global one.
Nothing prevents them to still use incorrect value.
The fix depends only on the hope that there won't be such uses.
But they already exist:
inetd.c:
INIT_G();
real_uid = getuid();
ftpgetput.c:
INIT_G();
/* Set default values */
user = "anonymous";
password = "busybox";
Can you try something more? E.g. (in current git):
#define ASSIGN_CONST_PTR(p, v) do { \
*(void**)not_const_pp(&p) = (void*)(v); \
/* At least gcc 3.4.6 on mipsel needs optimization barrier */ \
barrier(); \
+ sleep(0); \
} while (0)
or even
- barrier(); \
+ pselect(0, NULL, NULL, NULL, {0,0}, NULL); \
Basically, we should convince clang to not load "p" too early,
by starving it of available registers to store the fetched result.
> > Also, why ({...;})
> That is to avoid conflict between the global variable and the local
> variable. When the ({...}) part is evaluating, it uses the global
> variable p and stores it into the local variable, and then returns the
> variable to initialize the local variable.
I'm not even sure other compilers would interpret it like that -
they might think that "p" inside ({}) is the newly defined one.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
