Opened 6 years ago
Last modified 2 years ago
#95 assigned defect
Incorrect consideration of global and local variables in resolving waitfor mutex object. — at Version 4
Reported by: | Thierry Delisle | Owned by: | |
---|---|---|---|
Priority: | major | Component: | cfa-cc |
Version: | 1.0 | Keywords: | resolver |
Cc: |
Description (last modified by )
The following code :
#include <monitor.hfa> monitor M { condition e; } m; void rtn( M & mutex m ); void bar( M & mutex m ) { waitfor( rtn, m ); // not ambiguous, select parameter }
Produces the following error:
cfa test.c CFA Version 1.0.0 (debug) test.c:92:1 error: Ambiguous function in call to waitfor
If mangling is removed for mutex
then the following code encounters widening problems:
//---------- struct monitor_desc {}; struct monitor_guard_t {}; void ?{}( monitor_guard_t & this, monitor_desc ** m, int count, void (*func)() ); struct monitor_dtor_guard_t {}; void ?{}( monitor_dtor_guard_t & this, monitor_desc ** m, void (*func)() ); //---------- forall( dtype T | sized(T) | { void ^?{}( T & ); } ) void delete( T * ptr ); //---------- monitor test {}; int main() { test * t = 0; delete(t); }
Note the monitor_guard_t
and monitor_dtor_guard_t
structs are needed because they are expected by the code handling the mutex and monitor keywords.
Change History (4)
comment:1 Changed 6 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 6 years ago by
comment:3 Changed 6 years ago by
Owner: | Thierry Delisle deleted |
---|
The first part of fixing this is to remove the mangling on mutex
, I believe mangling that way can only lead to problems. After that however, there is a resolver bug that requires exact matching for assertion regardless of widening rules and I believe that needs to be changed.
comment:4 Changed 6 years ago by
Description: | modified (diff) |
---|
Note: See
TracTickets for help on using
tickets.
The source of this bug is that the local parameter
m
does not hide the globalm
. This is because the localm
mangles to a different name because it ismutex
. Having some ability to overload based onmutex
is useful, so we can't necessarily just take it out of the mangler, but it should in principle be possible to modify the mangler so that top-levelmutex
qualifiers don't affect mangling.