Ticket #10 (defect)
Opened 1 year ago
Last modified 1 year ago
Inconsistent use of const
Status: closed (fixed)
| Reported by: | brian.wibecan@hp.com | Assigned to: | anonymous |
|---|---|---|---|
| Priority: | major | Version: | |
| Keywords: | Cc: | ||
Reminder: I am build UPCIO with HP UPC and with async disabled.
There are a few instances where a pointer to struct is declared with a const target but then either assigned to a pointer with a non-const target or, equivalently, passed as an argument to a function where a pointer with a nonconst target is expected. One example:
upc_all_fread_list_shared takes as its fifth parameter a pointer to const struct. It passes that pointer as fourth argument to gupc_map_vec, which is supposed to be a pointer to nonconst struct. The function gupc_map_vec actually modifies the pointed-to object, so the argument cannot be a pointer to const. If upc_all_fread_list_shared is promising not to modify the pointed to object, it is violating that promise in this call.
A similar problem occurs in the corresponding write function, and in the async variants.
There were some other references to the memvec field in the struct aio_request; it's declared as pointing a upc_shared_memvec, but in upc_all_fread_list_shared_async.upc and possibly elsewhere it is assigned a value from a pointer to const upc_shared_memvec ("casting away the const"). I changed the field definition to include const, and that issue was resolved, but that may not be what is intended.
Some of these discrepancies will be caught by providing prototypes for all the gupc_* functions.
Attachments
Change History
07/09/07 13:58:16: Modified by sbahra
- owner changed from somebody to kunxi.
07/12/07 01:09:42: Modified by kunxi
- owner changed from kunxi to anonymous.
- status changed from new to assigned.
gupc_map_vec would change anything of memvec or filvec, add the const decorator to the pointer would solve this problem.
07/12/07 01:09:54: Modified by anonymous
- attachment filevec-const.diff added.
08/01/07 06:56:00: Modified by anonymous
08/01/07 07:34:14: Modified by anonymous
08/01/07 07:54:42: Modified by anonymous
08/24/07 05:11:40: Modified by sbahra
- status changed from assigned to closed.
- resolution set to fixed.
Fix committed, thanks.

First off, thanks a lot for the bug reports Brian. Regarding AIO fields, some variables are volatile yes (specifically, almost always the aio control block buffer itself). As we interact with this field directly (due to marshalling requirements) this cannot really be "fixed". Behavior is correct however.
Regarding gupc behavior, this has been committed to trunk a while ago. Other issues here will be looked at respectively by authors and will be fixed ASAP.