| Summary: | Version 0.19.2 causes regressions in Debian Installer | ||
|---|---|---|---|
| Product: | FriBidi | Reporter: | أحمد المحمودي <aelmahmoudy> |
| Component: | general | Assignee: | Behdad Esfahbod <freedesktop> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Screenshot of Debian Installer (please note the line with window title & "Go Back" button)
Patch adding fribidi support for newt Full patch for newt (to be applied after patch in attachment #33507) |
||
Created attachment 33507 [details] [review] Patch adding fribidi support for newt I've attached the patch that Debian uses to add fribidi support to newt, could it possibly that there is something wrong with this patch that caused regression with fribidi 0.19.2 ? This bug can be reproduced using whiptail: whiptail --yesno test 20 50 Hello, The following patch for newt zero-initialises fribidi_log2vis' output buffer, since it no longer does so itself: - out = (FriBidiChar *)malloc(sizeof(FriBidiChar)*(len+1)); + out = (FriBidiChar *)calloc(len+1, sizeof(FriBidiChar)); This patch solved the issue, yet the question remains, if this is considered a regression in fribidi that it doesn't zero-initialize the output buffer of fribidi_log2vis or not. I hope to hear a feedback from Behdad about this. Which file are you referring to? Please attach a real patch so I can see what's going on. Thanks. Created attachment 33531 [details] [review] Full patch for newt (to be applied after patch in attachment #33507 [details] [review]) The whole context probably isn't obvious in this patch, so a few lines before this patch there is: func_ptr = dlsym(handle, "fribidi_log2vis"); Then a few lines after this patch there is this call: (*func_ptr)(in, len, base_dir, out, NULL, NULL, NULL); So that last patch, is a workaround for newt because fribidi 0.19.2 doesn't add a NULL terminating character at the end of output string (visual_str in fribidi_log2vis function). Now, the question is: is this a bug that fribidi_log2vis does not add a NULL terminating character at the end of visual_str, or is that meant to be ? I don't think such a patch is necessary. Need a test case or more details of what's going on. AFAIU FriBidi does what it always did.(In reply to comment #7) > So that last patch, is a workaround for newt because fribidi 0.19.2 doesn't add > a NULL terminating character at the end of output string (visual_str in > fribidi_log2vis function). > > Now, the question is: is this a bug that fribidi_log2vis does not add a NULL > terminating character at the end of visual_str, or is that meant to be ? That's by design. All FriBidi API works with explicit length arguments. We never rely on or ensure nul-termination. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 33502 [details] Screenshot of Debian Installer (please note the line with window title & "Go Back" button) There are regressions in the newt frontend of Debian Installer with the new version of the fribidi. Note the line with the window title and the Go Back button in the attached screenshot. If Debian Installer is built against fribidi 0.10.9, those problems disappear.