http://bugs.winehq.org/show_bug.cgi?id=60241 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be --- Comment #4 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, (In reply to Ken Sharp from comment #1)
1 Find ONE bug. 2. Report it. 3. GOTO 1
I agree with Ken Sharp. "When to report a bug You should report a bug when: •Wine doesn't run a program the same way as Windows does (e.g. crashes) with the default Wine configuration (i.e. no dlls from Windows, or DllOverrides set). (...)" "How to report Each bug report should cover one problem. If there are additional problems with the same application or game, file separate reports for each.(...)" Our bug writing policies are entirely based on "an application is not working" and "one issue per report" approach. This is a realistic approach that allows issue tracking and developers to work on well defined tasks. It's the responsibility of the bug reporter to check if the issue exist (and if it's still present in new wine release). (In reply to Nikolay Sivov from comment #2)
That doesn't seems like a reasonable approach.
What would be a reasonable approach, then? It's not reasonable to report 1900 "possible" bugs in a single bug (or auto-generated individual reports), and expect the Wine developers to assert the existence of those "potential" issues, to sort what's valuable or not. It amounts to a "fix all what this AI says are bugs in Wine" metabug. To me, it's invalid. If not invalid, then who's going to read that report? to get what out of it? and how are we supposed to track such bug? (In reply to Rafał Mikrut from comment #0)
////////////////////////////////////////////////////
### CPY_3 `HIGH`
**Description:** In `ImmGetImeMenuItemsA` and `ImmGetImeMenuItemsW`, the per-item conversion loop copies from a fixed index `1` instead of the loop variable `i`: `memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) )` and, symmetrically, `memcpy( &menuW[i], &menuA[1], sizeof(IMEMENUITEMINFOA) )`. Every output element ends up filled with data copied from source index `1` (wrong data for all `i != 1`), and when `ret` is `1` this also reads `menuW[1]`/`menuA[1]`, one element past what was populated/allocated for a single-item result - an out-of-bounds read.
**Locations:** ```c memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) ); ``` **Fix:** Use the loop index instead of the literal `1` in both functions: ```c memcpy( &menuA[i], &menuW[i], sizeof(IMEMENUITEMINFOA) ); ```
The original code is valid, if the intent is to initialize the item with index i in menuA[] with the content of the item with fixed index 1 of menuW[]. The analysis doesn't provide any context to check what that function is actually doing, so that "potential" issue requires validation by checking the original intent and if the code is a correct implementation of it.
////////////////////////////////////////////////////
### LOGIC_66 `MEDIUM`
**Description:** In `EMFDC_PlgBlt()`, the bounding-box computation loop updates `x_min`, `y_min`, `x_max` correctly with `min()`/`max()` against their own running value, but `y_max` is computed with `max( y_min, points[i].y )` instead of `max( y_max, points[i].y )`. This is a copy-paste typo that makes the computed `emr->rclBounds.bottom` wrong whenever `y_max` and `y_min` diverge.
**Locations:** dlls/gdi32/emfdc.c:1875 ``` x_min = min( x_min, points[i].x ); y_min = min( y_min, points[i].y ); x_max = max( x_max, points[i].x ); y_max = max( y_min, points[i].y ); ```
**Fix:**
```c // before y_max = max( y_min, points[i].y );
// after y_max = max( y_max, points[i].y ); ```
What if the copy-paste error is in the "x_max = max( x_max, ..." that should have been "x_max = max( x_min, ...". Maybe the code initialize x_min and y_min to some value to be compared with points[i] to get min and max of each. Again, there is no context to validate what the code has to achieve and the potential issue requires manual investigation.
//////////////////////////////////////////////////// ### CPY_52 `MEDIUM`
**Description:** In `ace_flags_to_samba()` the branch for `CONTAINER_INHERIT_ACE` sets `SEC_ACE_FLAG_NO_PROPAGATE_INHERIT` instead of `SEC_ACE_FLAG_CONTAINER_INHERIT`. This is a copy-paste from the next line (`NO_PROPAGATE_INHERIT_ACE`), so `CONTAINER_INHERIT_ACE` is silently dropped and duplicated as `NO_PROPAGATE_INHERIT_ACE` whenever a share's DACL/SACL ACE flags are converted for Samba, corrupting ACL inheritance semantics passed to `NetShareAdd`/`NetShareGetInfo`.
**Locations:** dlls/netapi32/unixlib.c:427 ``` if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ```
**Fix:** Change the `CONTAINER_INHERIT_ACE` mapping to use the correct destination flag: ```c if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_CONTAINER_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ```
What if the code just deal with setting SEC_ACE_FLAG_NO_PROPAGATE_INHERIT, and must do so whether CONTAINER__INHERIT_ACE or NO_PROPAGATE_INHERIT_ACE is set? Again, without context, there is no proof that the code is actually wrong, and like the other issues, this need manual investigation to even know if there is an actual problem with that. Note that the AI statements "this is a copy-paste from the ... line" is unfounded. How could the AI know which line was copied from which other, or even that they are actually copied and not just similar? This is just one more case of AI confident & eloquent presentation and positive assertion of factually false information. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.