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.