Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-06-09 23:10-0400 Jim Dishaw wrote:
>> 
>> 
>>> On Jun 9, 2015, at 10:39 PM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> On 2015-06-09 18:18-0400 Jim Dishaw wrote:
>>> 
>>>> Attached is a patch series that corrects a NUL termination bug in
>>> the plot buffer that I discovered while working on the windows GDI
>>> driver.
>>> 
>>> Hi Jim:
>>> 
>>> I applied this result to a private branch using "git am", styled this
>>> result (which was very easy to do, see previous comment), amended your
>>> commit with those style changes using "git add" and "git commit
>>> --amend", and then pushed that result using the normal procedure in
>>> README.developers as commit id = 868f790.
>> Thanks, I will get uncrustify working on the Windows machine I’m using so I don’t keep inconveniencing you.
>> 
>>> Note, I did not test this commit in the slightest, but I assumed you
>>> had done that already.
> 
>> The benefit of developing the the windows GDI driver is that it is
> exercising code pathways in the plot buffer that have never been
> tested.  It appears that all the other GUI drivers have shifted to
> using unicode for strings.  This error affects drivers that use
> regular strings and rely on the plot buffer, which is a very small
> set.
> 
> Hi Jim:
> 
> I am sufficiently concerned by your explanation of this fix above that
> I am now beginning to wonder a bit if it was necessary.  Of course, I
> could be just missing something, but I would appreciate a fuller
> explanation of the fix to make sure of its necessity.
> 

The fix is still necessary to replay the plot buffer with a device that uses char strings vice the Unicode string. In EscText there are two different ways of storing strings. 

> Here is some random stuff I know about our method of dealing with
> unicode which might help to clarify the discussion.
> 
> Input strings for PLplot are all in the UTF-8 representation of
> unicode whether representing glyphs that require a multi-byte UTF-8
> representation or glyphs that require only a single-byte (ascii) but
> still UTF-8 representation of glyphs. In all cases these input strings
> are a series of bytes which are null-terminated. So I really don't see
> how you are getting null-termination problems for some devices and not
> others.  Also, the xwin device driver (which is available on Cygwin,
> Mac OS X, and Linux) is an example of a driver that uses regular
> strings and relies on the plot buffer.  So this driver should be an
> excellent test case for us of plbuf changes that you do for the
> regular strings case.
> 
> How should the latest change of yours affect the xwin device driver
> results?
> 

Without the patch text strings could show random characters on redraw events. With this patch all the strings display correctly on resize events. 

> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________