gnuplot-beta — Developers and beta testers of new gnuplot code

Re: fontconfig configration file search path in static build on windows

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta; Tatsuro MATSUOKA >
> Cc: 
> Date: 2016/2/16, Tue 13:09
> Subject: Re: fontconfig configration file search path in static build on windows
> 
> On Tuesday, 16 February 2016 12:52:38 PM Tatsuro MATSUOKA wrote:
>>  ----- Original Message -----
>> 
>>  > From: sfeam
>>  > To: gnuplot-beta; Tatsuro MATSUOKA 
>>  > Cc: 
>>  > Date: 2016/2/16, Tue 12:30
>>  > Subject: Re: fontconfig configration file search path in static build 
> on windows
>>  > 
>>  > On Tuesday, 16 February 2016 11:57:06 AM Tatsuro MATSUOKA wrote:
>>  >>  This is just information.
>>  >> 
>>  >>  >From an demand, I have built static linked gnuplot binary on 
> windows.
>>  >> 
>>  >>  However, fontconfig feature could not be used because 
>>  >>  fontconfig cannot find fontconfig configuration path
>>  >>  if fontconfig path is relative to ../etc/fonts from bin.
>>  >> 
>>  >>  This directory structure only effective using dll version 
> fontconfig.
>>  >> 
>>  >>  For static link on windows, fontconfig 2.11.1, fontconfig 
> application
>>  >>  search fonts directory where a exe file exist.
>>  >> 
>>  >>  See:
>>  >>  
> https://lists.freedesktop.org/archives/fontconfig/2016-February/005676.html
>>  > 
>>  > Is there some reason you cannot set FONTCONFIG_PATH?
>>  > 
>>  > If this path is the same for multiple applications then they would
>>  > all benefit from the same "first" initialization of the font 
> cache.
>>  > 
>>  >     Ethan
>> 
>> 
>>  Unlike Unix, on windows there are many different applications which use 
> different version of fontconfig 
>>  or different setting or build of fontconfig.
> 
> I understand.  
> But this is the path to the font cache, not the path to the library executable.
> 
>>  So global seting PATH preferably is avoided if possible.
> 
> You really do want a shared path for system fonts.
> Otherwise all programs that use the fonts suffer from this same problem.
> Sharing a font cache will benefit all of the them.


TeX for windows (like MiKTeX) uses fontconfig. 
The font configuration for TeX for windows is different from that of the original fontconfig.
I would like to avoid unexpected conflict different setting of font configuration file. 

From this demand, windows version fontconfig may have feature to search font 
configuration path relatively if FONTCONFIG_PATH is not set from some version of fontconfig.
(The above is just my speculation.)
>>  In addition, if we use gnuplot in usb stick, FONTCONFIG_PATH is not set 
> easily.
> 
> Doesn't windows have some way of setting this once for the user,
> rather than many times for each program that runs?
> 
The USB stick can set on different computer but the drive name of USB is different 
if computer is different. Setting FONTCONFIG_PATH is not useful for portable use.

Tatsuro 

Re: fontconfig configration file search path in static build on windows

[sfeam <sf...@us...>]

On Tuesday, 16 February 2016 12:52:38 PM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: sfeam
> > To: gnuplot-beta; Tatsuro MATSUOKA 
> > Cc: 
> > Date: 2016/2/16, Tue 12:30
> > Subject: Re: fontconfig configration file search path in static build on windows
> > 
> > On Tuesday, 16 February 2016 11:57:06 AM Tatsuro MATSUOKA wrote:
> >>  This is just information.
> >> 
> >>  >From an demand, I have built static linked gnuplot binary on windows.
> >> 
> >>  However, fontconfig feature could not be used because 
> >>  fontconfig cannot find fontconfig configuration path
> >>  if fontconfig path is relative to ../etc/fonts from bin.
> >> 
> >>  This directory structure only effective using dll version fontconfig.
> >> 
> >>  For static link on windows, fontconfig 2.11.1, fontconfig application
> >>  search fonts directory where a exe file exist.
> >> 
> >>  See:
> >>  https://lists.freedesktop.org/archives/fontconfig/2016-February/005676.html
> > 
> > Is there some reason you cannot set FONTCONFIG_PATH?
> > 
> > If this path is the same for multiple applications then they would
> > all benefit from the same "first" initialization of the font cache.
> > 
> >     Ethan
> 
> 
> Unlike Unix, on windows there are many different applications which use different version of fontconfig 
> or different setting or build of fontconfig.

I understand.  
But this is the path to the font cache, not the path to the library executable.

> So global seting PATH preferably is avoided if possible.

You really do want a shared path for system fonts.
Otherwise all programs that use the fonts suffer from this same problem.
Sharing a font cache will benefit all of the them.

> In addition, if we use gnuplot in usb stick, FONTCONFIG_PATH is not set easily.

Doesn't windows have some way of setting this once for the user,
rather than many times for each program that runs?

	Ethan

Re: fontconfig configration file search path in static build on windows

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam
> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2016/2/16, Tue 12:30
> Subject: Re: fontconfig configration file search path in static build on windows
> 
> On Tuesday, 16 February 2016 11:57:06 AM Tatsuro MATSUOKA wrote:
>>  This is just information.
>> 
>>  >From an demand, I have built static linked gnuplot binary on windows.
>> 
>>  However, fontconfig feature could not be used because 
>>  fontconfig cannot find fontconfig configuration path
>>  if fontconfig path is relative to ../etc/fonts from bin.
>> 
>>  This directory structure only effective using dll version fontconfig.
>> 
>>  For static link on windows, fontconfig 2.11.1, fontconfig application
>>  search fonts directory where a exe file exist.
>> 
>>  See:
>>  https://lists.freedesktop.org/archives/fontconfig/2016-February/005676.html
> 
> Is there some reason you cannot set FONTCONFIG_PATH?
> 
> If this path is the same for multiple applications then they would
> all benefit from the same "first" initialization of the font cache.
> 
>     Ethan


Unlike Unix, on windows there are many different applications which use different version of fontconfig 
or different setting or build of fontconfig.

So global seting PATH preferably is avoided if possible.

In addition, if we use gnuplot in usb stick, FONTCONFIG_PATH is not set easily.

Tatsuro

Re: fontconfig configration file search path in static build on windows

[sfeam <sf...@us...>]

On Tuesday, 16 February 2016 11:57:06 AM Tatsuro MATSUOKA wrote:
> This is just information.
> 
> >From an demand, I have built static linked gnuplot binary on windows.
> 
> However, fontconfig feature could not be used because 
> fontconfig cannot find fontconfig configuration path
> if fontconfig path is relative to ../etc/fonts from bin.
> 
> This directory structure only effective using dll version fontconfig.
> 
> For static link on windows, fontconfig 2.11.1, fontconfig application
> search fonts directory where a exe file exist.
> 
> See:
> https://lists.freedesktop.org/archives/fontconfig/2016-February/005676.html

Is there some reason you cannot set FONTCONFIG_PATH?

If this path is the same for multiple applications then they would
all benefit from the same "first" initialization of the font cache.

	Ethan

fontconfig configration file search path in static build on windows

[Tatsuro M. <tma...@ya...>]

This is just information.

From an demand, I have built static linked gnuplot binary on windows.

However, fontconfig feature could not be used because 
fontconfig cannot find fontconfig configuration path
if fontconfig path is relative to ../etc/fonts from bin.

This directory structure only effective using dll version fontconfig.

For static link on windows, fontconfig 2.11.1, fontconfig application
search fonts directory where a exe file exist.

See:
https://lists.freedesktop.org/archives/fontconfig/2016-February/005676.html


Tatsuro 

Re: Changes to stable-5-0 branch

[Hans-Bernhard B. <HBB...@t-...>]

Am 15.02.2016 um 23:31 schrieb sfeam:

> I am having trouble to understand how in our particular case C++ can
> fail to find the C language definition of isnan() from <math.h>
>
> and <math.h> as I understand it is required to define isnan() by C99.

It would be.  _But_ we're not running a C99 compiler here; we're running 
a C++ compiler.  Now a C++11 compiler would be required (C++1x 
26.8p3,p4) to effectively pull in the C99 version of <math.h>, including 
isnan(), except that in C++ it's not a macro: it's a set of three 
overloaded functions.  C++ really doesn't want macros for this sort of 
thing.

A compiler that's not running in C++11 mode (or equivalent) is not only 
not required to do that: it's even kind-of forbidden.  Earlier editions 
of the C++ standard explicitly listed which functions <math.h> shall 
bring into a C++ program's global name space (C++03 26.5p1,p2). isnan() 
was not among them.  To overcome this limit might take an equivalent of 
what the AC_USE_SYSTEM_EXTENSIONS method of autoconf does for us about 
the difference between "strict" and "extended" C, but for C++.

> So why does the C++ compiler not pick up the C99 macro even if
> it wouldn't otherwise define it on its own?

Because the header itself hides it from C++'s view, probably by querying 
(__STDC_VERSION__ >= 199901L) and/or (__cplusplus >= 201103L)

> If it's only this one place, may the simplest work-around is:
> -                               if (isnan(*image))
> +                               if (*image != *image)   // this test works even if isnan() is missing

That might well be the case.

Re: Long delay in first use of fontconfig features in gd terminal in my MinGW build

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Mojca Miklavec 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta 
> Date: 2016/2/15, Mon 17:45
> Subject: Re: Long delay in first use of fontconfig features in gd terminal in my MinGW build
> 
> On 15 February 2016 at 09:24, Tatsuro MATSUOKA wrote:
>>  Hello
>> 
>>  This is not a bug but a slightly annoying matter.
>> 
>>  For the gnuplot binaries for windows built by me,
>>  If I use fontconfig features in gd terminal for example
>> 
>>  gnuplot> set term png font 'Times New Roman'
>> 
>>  If it is used for the first time, a long delay happes in first use.
>>  (depending on environment. ca. several ten seconds).
>> 
>>  However, once the fontconfig features is used, delay does not occur.
>> 
>>  For cairo based terminal, this delay does not occur.
>> 
>>  For the binary provided by Bastian, this delay does not occur.
>> 
>>  Have anyone seen the similar issue?
> 
> On all systems with libraries that use fontconfig, fontconfig has to
> scan all system fonts occasionally. On Linux that most likely happens
> semi-automatically somewhere in the background and only once for all
> applications. On Mac and Windows this is a bit more tricky because
> every single piece of software uses its own copy of fontconfig and its
> own database. The described behaviour is a well known "problem". On OS
> X many software packages like MPlayer, VNC, Gimp, ... would display a
> notice when I start them, letting me know that I have to wait until
> the font database gets rebuilt/updated.
> 
> I don't believe that you can entirely avoid that. You can probably
> influence the frequency of updates and location of the database. Maybe
> your build of fontconfig creates a font database at some temporary
> location that Windows deletes when you shut down the computer (that is
> pure guessing). In any case you should not get delays every time you
> start gnuplot.
> 
> I don't understand why the delay happens with gd, but not with cairo
> though (if both use fontconfig). I would expect a delay with every
> terminal that depends on fontconfig, but only once in a while (maybe
> once per month or when you try to use a font that's not in the
> database).
> 
> Mojca


Thanks for your detailed explanation.

> I don't understand why the delay happens with gd, but not with cairo
> though (if both use fontconfig).


For cairo based terminal, it is possible that I might make mistakes.

First I have tried used enhanced text handing on gd terminals.

set term png
set out 'test.png'
set title '{/:Bold A}'
plot sin(x)
set out

First I felt that gnuplot hanged.

For pngcairo

set term pngcairo
set out 'test.png'
set title '{/:Bold A}'
plot sin(x)
set out

worked as expected

But I did not execute

set term pngcairo font 'Times New Roman'

Other fontconfing application like fc-list have long delay in first use.
You explanation is quite right for windows.

Tatsuro 

Re: Changes to stable-5-0 branch

[sfeam <sf...@us...>]

On Sunday, 14 February 2016 10:46:24 AM Bastian Märkisch wrote:
> 
> Am 13.02.2016 um 21:23 schrieb sfeam:
> (snip)
> > In particular the change below is problematic because it was already tried in
> > the main branch and turned out to cause problems on some systems:
> >
> >          * src/qtterminal/qt_term.h src/qtterminal/qt_conversion.cpp:  isnan()
> >          is in namespace std.
> >
> > See 5.1 ChangeLog:
> >
> > 2015-12-10  Hans-Bernhard Broeker  <br...@ph...>
> >
> >          * src/qtterminal/qt_conversion.cpp (qt_imageToQImage): Do not call
> >          C++ isnan() without a namespace specifier.
> >
> >          EAM:  Reverting this change.  We may need a fix, but this isn't it.
> >          qtterminal/qt_conversion.cpp:
> >          In function 'QImage qt_imageToQImage(int, int, coordval*, t_imagecolor)':
> >          qtterminal/qt_conversion.cpp:129:14:
> >          error: expected unqualified-id before '(' token if (std::isnan(*image))
> >
> > I don't know what the issue is here, but since adding the std:: qualifier
> > is known to break the build on some systems that were perfectly happy before
> > this, I think it is not suitable for the stable branch.
> >
> 
> OK. Reverted in branch-5-0-stable.
> 
> The problem is that isnan is in the C99 standard, but wasn't in the C++ 
> standard until C++11. Hence, many C++ compilers implemented it "their" 
> way, as _isnan (MSVC), ::isnan, std::isnan or macro (as in C99). See 
> e.g. the discussion at
> http://stackoverflow.com/questions/570669/checking-if-a-double-or-float-is-nan-in-c
> Btw. simply adding a "using namespace std" doesn't solve the issue 
> either, since some compilers have both, ::isnan and std::isnan.

I am having trouble to understand how in our particular case C++ can
fail to find the C language definition of isnan() from <math.h>

The source line at issue is 

qt_conversion.cpp:129:                          if (isnan(*image))
included from 
qt_term.cpp:78:#include "qt_conversion.cpp"

But before this we have
qt_term.cpp:57: #include "term_api.h"  // for stdfn.h, JUSTIFY, encoding, ...
term_api.h:43:#include "stdfn.h"
stdfn.h:291:# include <math.h>

and <math.h> as I understand it is required to define isnan() by C99.
So why does the C++ compiler not pick up the C99 macro even if
it wouldn't otherwise define it on its own?

> 
> Too me it looks like the only way of solving this in a portable way is 
> to implement a C function like this in e.g. stdfn.c|h :
> 
> TBOOLEAN gp_isnan(double v)
> {
> 	return isnan(v);
> }

If it's only this one place, may the simplest work-around is:

--- old/qt_conversion.cpp  2016-02-14 13:51:54.866487634 -0800
+++ new/qt_conversion.cpp     2016-02-15 14:29:15.785792815 -0800
@@ -126,7 +126,7 @@ QImage qt_imageToQImage(int M, int N, co
                        QRgb* line = (QRgb*)(qimage.scanLine(n));
                        for (int m = 0; m < M; m++)
                        {
-                               if (isnan(*image))
+                               if (*image != *image)   // this test works even if isnan() is missing
                                {
                                        image++;
                                        *line++ = 0x00000000;



	Ethan

> 
>    Bastian

Re: Long delay in first use of fontconfig features in gd terminal in my MinGW build

[Mojca M. <moj...@gm...>]

On 15 February 2016 at 09:24, Tatsuro MATSUOKA wrote:
> Hello
>
> This is not a bug but a slightly annoying matter.
>
> For the gnuplot binaries for windows built by me,
> If I use fontconfig features in gd terminal for example
>
> gnuplot> set term png font 'Times New Roman'
>
> If it is used for the first time, a long delay happes in first use.
> (depending on environment. ca. several ten seconds).
>
> However, once the fontconfig features is used, delay does not occur.
>
> For cairo based terminal, this delay does not occur.
>
> For the binary provided by Bastian, this delay does not occur.
>
> Have anyone seen the similar issue?

On all systems with libraries that use fontconfig, fontconfig has to
scan all system fonts occasionally. On Linux that most likely happens
semi-automatically somewhere in the background and only once for all
applications. On Mac and Windows this is a bit more tricky because
every single piece of software uses its own copy of fontconfig and its
own database. The described behaviour is a well known "problem". On OS
X many software packages like MPlayer, VNC, Gimp, ... would display a
notice when I start them, letting me know that I have to wait until
the font database gets rebuilt/updated.

I don't believe that you can entirely avoid that. You can probably
influence the frequency of updates and location of the database. Maybe
your build of fontconfig creates a font database at some temporary
location that Windows deletes when you shut down the computer (that is
pure guessing). In any case you should not get delays every time you
start gnuplot.

I don't understand why the delay happens with gd, but not with cairo
though (if both use fontconfig). I would expect a delay with every
terminal that depends on fontconfig, but only once in a while (maybe
once per month or when you try to use a font that's not in the
database).

Mojca

Long delay in first use of fontconfig features in gd terminal in my MinGW build

[Tatsuro M. <tma...@ya...>]

Hello

This is not a bug but a slightly annoying matter.

For the gnuplot binaries for windows built by me,
If I use fontconfig features in gd terminal for example

gnuplot> set term png font 'Times New Roman'

If it is used for the first time, a long delay happes in first use.
(depending on environment. ca. several ten seconds).

However, once the fontconfig features is used, delay does not occur.

For cairo based terminal, this delay does not occur.

For the binary provided by Bastian, this delay does not occur.

Have anyone seen the similar issue?

Tatsuro   

Re: Changes to stable-5-0 branch

[Bastian M. <bma...@we...>]

Am 13.02.2016 um 21:23 schrieb sfeam:
(snip)
> In particular the change below is problematic because it was already tried in
> the main branch and turned out to cause problems on some systems:
>
>          * src/qtterminal/qt_term.h src/qtterminal/qt_conversion.cpp:  isnan()
>          is in namespace std.
>
> See 5.1 ChangeLog:
>
> 2015-12-10  Hans-Bernhard Broeker  <br...@ph...>
>
>          * src/qtterminal/qt_conversion.cpp (qt_imageToQImage): Do not call
>          C++ isnan() without a namespace specifier.
>
>          EAM:  Reverting this change.  We may need a fix, but this isn't it.
>          qtterminal/qt_conversion.cpp:
>          In function 'QImage qt_imageToQImage(int, int, coordval*, t_imagecolor)':
>          qtterminal/qt_conversion.cpp:129:14:
>          error: expected unqualified-id before '(' token if (std::isnan(*image))
>
> I don't know what the issue is here, but since adding the std:: qualifier
> is known to break the build on some systems that were perfectly happy before
> this, I think it is not suitable for the stable branch.
>

OK. Reverted in branch-5-0-stable.

The problem is that isnan is in the C99 standard, but wasn't in the C++ 
standard until C++11. Hence, many C++ compilers implemented it "their" 
way, as _isnan (MSVC), ::isnan, std::isnan or macro (as in C99). See 
e.g. the discussion at
http://stackoverflow.com/questions/570669/checking-if-a-double-or-float-is-nan-in-c
Btw. simply adding a "using namespace std" doesn't solve the issue 
either, since some compilers have both, ::isnan and std::isnan.

Too me it looks like the only way of solving this in a portable way is 
to implement a C function like this in e.g. stdfn.c|h :

TBOOLEAN gp_isnan(double v)
{
	return isnan(v);
}


   Bastian

Re: Changes to stable-5-0 branch

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta
> Cc: Bastian Märkisch 
> Date: 2016/2/14, Sun 05:23
> Subject: Re: Changes to stable-5-0 branch
> 
> On Saturday, 13 February 2016 06:34:27 PM Bastian Märkisch wrote:
>>  Hi,
>> 
>>  Today I checked in some changes to the stable-5-0 branch which make 
>>  gnuplot sources compatible with MSYS2/Mingw-w64 on Windows, as well as 
>>  they make wxWidgets 3.0 work.  These changes should in principle be 
>>  compatible with other platforms, but I could only check on CentOS5 & 6.
>>  Of course it still compiles cleanly using MSVC2012 or the old MSYS/MinGW 
>>  combination, too.
> 
> In general it is not good to make changes in the stable branch that have not
> already been tested in the main branch (5.1).  Obviously there are exceptions
> like fixing a bug that is only present in the stable branch.
> 
> In particular the change below is problematic because it was already tried in
> the main branch and turned out to cause problems on some systems:
> 
>         * src/qtterminal/qt_term.h src/qtterminal/qt_conversion.cpp:  isnan()
>         is in namespace std.
> 

I have been used this isnan change for MinGW-w64 (both 32 and 64bit)
without any reports.

Tatsuro

Re: Changes to stable-5-0 branch

[sfeam <sf...@us...>]

On Saturday, 13 February 2016 06:34:27 PM Bastian Märkisch wrote:
> Hi,
> 
> Today I checked in some changes to the stable-5-0 branch which make 
> gnuplot sources compatible with MSYS2/Mingw-w64 on Windows, as well as 
> they make wxWidgets 3.0 work.  These changes should in principle be 
> compatible with other platforms, but I could only check on CentOS5 & 6.
> Of course it still compiles cleanly using MSVC2012 or the old MSYS/MinGW 
> combination, too.

In general it is not good to make changes in the stable branch that have not
already been tested in the main branch (5.1).  Obviously there are exceptions
like fixing a bug that is only present in the stable branch.

In particular the change below is problematic because it was already tried in
the main branch and turned out to cause problems on some systems:

        * src/qtterminal/qt_term.h src/qtterminal/qt_conversion.cpp:  isnan()
        is in namespace std.

See 5.1 ChangeLog:

2015-12-10  Hans-Bernhard Broeker  <br...@ph...>

        * src/qtterminal/qt_conversion.cpp (qt_imageToQImage): Do not call
        C++ isnan() without a namespace specifier.

        EAM:  Reverting this change.  We may need a fix, but this isn't it.
        qtterminal/qt_conversion.cpp:
        In function 'QImage qt_imageToQImage(int, int, coordval*, t_imagecolor)':
        qtterminal/qt_conversion.cpp:129:14:
        error: expected unqualified-id before '(' token if (std::isnan(*image))

I don't know what the issue is here, but since adding the std:: qualifier
is known to break the build on some systems that were perfectly happy before
this, I think it is not suitable for the stable branch.   

> There's another patch I would like to include, which avoids warnings 
> about incompatible linkage of wxEvents on Windows.  It works on CentOS6, 
> too.  Could someone please verify it does not break e.g. the Mac build?

It works for me on linux (tested on 2 systems), but again I'd be happier if it went
into 5.1 before applying it to the stable branch.

	Ethan

>    Bastian

Changes to stable-5-0 branch

[Bastian M. <bma...@we...>]

Hi,

Today I checked in some changes to the stable-5-0 branch which make 
gnuplot sources compatible with MSYS2/Mingw-w64 on Windows, as well as 
they make wxWidgets 3.0 work.  These changes should in principle be 
compatible with other platforms, but I could only check on CentOS5 & 6.
Of course it still compiles cleanly using MSVC2012 or the old MSYS/MinGW 
combination, too.

There's another patch I would like to include, which avoids warnings 
about incompatible linkage of wxEvents on Windows.  It works on CentOS6, 
too.  Could someone please verify it does not break e.g. the Mac build?

   Bastian

Re: possible buffer overflow in tkcanvas?

[Ethan A M. <sf...@us...>]

On Saturday, 13 February, 2016 02:47:43 Jun T. wrote:
> With the CVS HEAD, clang gives the following warning (and suggestion):
> 
> ../term/tkcanvas.trm:694:33: warning: the value of the size argument in 'strncat' is too large, might lead to a buffer overflow [-Wstrncat-size]
>                 strncat(tmp_dashpattern, buf, sizeof(tmp_dashpattern) - strlen(tmp_dashpattern));


Thanks.  Good idea to run it through clang.
The clang I have here (3.5.2) picks up two more errors in tkcanvas
in addition to the ones you saw.  One is harmless, but this one

../term/tkcanvas.trm:683:27: warning: comparison of array 'custom_dash_pattern->dstring' not
      equal to a null pointer is always true [-Wtautological-pointer-compare]
        if (custom_dash_pattern->dstring != NULL) {
            ~~~~~~~~~~~~~~~~~~~~~^~~~~~~    ~~~~

can cause a real failure.

	Ethan


>                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../term/tkcanvas.trm:694:33: note: change the argument to be the free space in the destination buffer minus the terminating null byte
>                 strncat(tmp_dashpattern, buf, sizeof(tmp_dashpattern) - strlen(tmp_dashpattern));
>                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                                               sizeof(tmp_dashpattern) - strlen(tmp_dashpattern) - 1
> 
> So I looked into the function TK_dashtype() and noticed two more
> suspicious code (in addition to the line 694 pointed out by clang).
> I attached a patch, but I haven't done any tests (I don't know
> how to use tkcanvas). So please consider my patch just as a suggestion.
> 
> Lines 694 and 685 may be dangerous in the following sense:
> 
> If strlen(src) >=n,
>   strncat(dest, src, n) adds n chars AND a trailing NUL to dest.
>   strncpy(dest, src, n) copies n chars to dest but does not NUL
>   terminate it.
> 
> So the safest way of using these functions is:
>   strncat(dest, src, sizeof(dest) - strlen(dest) - 1);
> and
>   strncpy(dest, src, sizeof(dest) - 1);
>   dest[sizeof(dest)-1] = NUL;
> 
> (line 685 is safe in the present case since dstring is shorter than
> tmp_dashpattern, but ...)
> 
> 
> And what does the line 696
>     tmp_dashpattern[strlen(tmp_dashpattern) - 1] = NUL;
> want to achieve?
> Maybe a simple confusion between strncat and strncpy?
> 
> 
> BTW, are 32 bytes really necessary for buf[]? (line 690).
> sizeof(tmp_dashpattern) = 3*DASHPATTERN_LENGTH = 24 < 32
> (if DASHPATTERN_LENGTH = 8).
> 

Re: possible buffer overflow in tkcanvas?

[Jun T. <tak...@kb...>]

2016/02/13 02:47, Jun T. <tak...@kb...> wrote:
> And what does the line 696
>    tmp_dashpattern[strlen(tmp_dashpattern) - 1] = NUL;
> want to achieve?

Sorry, this line must be retained.
It's used for eliminating the trailing space ' '
(assuming that buf[] is not truncated by strncat()).

possible buffer overflow in tkcanvas?

[Jun T. <tak...@kb...>]

With the CVS HEAD, clang gives the following warning (and suggestion):

../term/tkcanvas.trm:694:33: warning: the value of the size argument in 'strncat' is too large, might lead to a buffer overflow [-Wstrncat-size]
                strncat(tmp_dashpattern, buf, sizeof(tmp_dashpattern) - strlen(tmp_dashpattern));
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../term/tkcanvas.trm:694:33: note: change the argument to be the free space in the destination buffer minus the terminating null byte
                strncat(tmp_dashpattern, buf, sizeof(tmp_dashpattern) - strlen(tmp_dashpattern));
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                              sizeof(tmp_dashpattern) - strlen(tmp_dashpattern) - 1

So I looked into the function TK_dashtype() and noticed two more
suspicious code (in addition to the line 694 pointed out by clang).
I attached a patch, but I haven't done any tests (I don't know
how to use tkcanvas). So please consider my patch just as a suggestion.

Lines 694 and 685 may be dangerous in the following sense:

If strlen(src) >=n,
  strncat(dest, src, n) adds n chars AND a trailing NUL to dest.
  strncpy(dest, src, n) copies n chars to dest but does not NUL
  terminate it.

So the safest way of using these functions is:
  strncat(dest, src, sizeof(dest) - strlen(dest) - 1);
and
  strncpy(dest, src, sizeof(dest) - 1);
  dest[sizeof(dest)-1] = NUL;

(line 685 is safe in the present case since dstring is shorter than
tmp_dashpattern, but ...)


And what does the line 696
    tmp_dashpattern[strlen(tmp_dashpattern) - 1] = NUL;
want to achieve?
Maybe a simple confusion between strncat and strncpy?


BTW, are 32 bytes really necessary for buf[]? (line 690).
sizeof(tmp_dashpattern) = 3*DASHPATTERN_LENGTH = 24 < 32
(if DASHPATTERN_LENGTH = 8).

Re: SourceForge seems to add adware to software (windows installer)

[Tatsuro M. <tma...@ya...>]

Hello

On the Octave ML, there reported a news concerning to SourceForge.
The new owners seem to start to eliminate mistakes from the past.

Octave ML report:
http://octave.1599824.n4.nabble.com/We-need-to-talk-about-SourceForge-tp4670942p4674746.html


SourceForge announce:
https://sourceforge.net/blog/sourceforge-acquisition-and-future-plans/


Tatsuro

Re: timestamp in Changelog in CVS tree is wrong

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2016/2/11, Thu 11:39
> Subject: timestamp in Changelog in CVS tree is wrong
> 
> Hello
> 
> I have checked recent snapshot cvd on 2016-02-11.
> 
> However, the latest change date is 2016-02-20.
> 
> Please correct the date.
> 
> Tatsuro


I have confirmed the timestamp is now corrected.

Thanks

Tatsuro

timestamp in Changelog in CVS tree is wrong

[Tatsuro M. <tma...@ya...>]

Hello

I have checked recent snapshot cvd on 2016-02-11.

However, the latest change date is 2016-02-20.

Please correct the date.

Tatsuro

Re: Win32 build of gnuplot 5.0.2

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Bastian Märkisch 
> To: Tatsuro MATSUOKA ; gnuplot-beta
> Cc: 
> Date: 2016/2/10, Wed 17:54
> Subject: Re: Win32 build of gnuplot 5.0.2
> 
> 
> 
> Am 04.02.2016 um 07:00 schrieb Tatsuro MATSUOKA:
>>  Bastian:
>> 
>>  Do you use MinGW32 compliers on the original site(http://www.mingw.org/) ?
>> 
>>  Tatsuro
> 
> 
> Yes, indeed. I am using MinGW's gcc 4.8.1. Old, but it works.
> Also I do use binary packages of libraries whenever possible.
> Please find a full list below.
> 
>   Bastian
> 
> 
> Build environment:
>   - recent MinGW/MSYS, GCC v4.8.1, (1)
>   - lua 5.2 (1)
>   - zlib 1.2.8 (1)
>   - cairo 1.10.2 (2)
>   - expat 2.0.1 (2)
>   - fontconfig 2.8.0 (2)
>   - freetype 2.4.2 (2)
>   - gettext 0.18.1.1 (2)
>   - glib 2.28.8 (2)
>   - libpng 1.4.3 (2)
>   - pango 1.29.4 (2)
>   - pkg-config 0.26 (2)
>   - libgd 2.1.0 (3)
>   - libjpeg-turbo (4)
>   - wxWidgets wxMSW 2.8.12 (5)
>   - libcerf 1.3 (6)
>   - libcaca SVN rev #4872 (7)
>   - Qt 5.1.2 (8)
> 
>   (1) binary, http://www.mingw.org/
>   (2) binary, http://www.gtk.org/download/win32.php
>   (3) source, http://www.libgd.org
>   (4) binary, http://www.libjpeg-turbo.org/
>   (5) source, http://www.wxwidgets.org/downloads/
>   (6) source, http://apps.jcns.fz-juelich.de/src/libcerf/
>   (7) source, http://caca.zoy.org/wiki/libcaca
>   (8) binary, http://qt-project.org/downloads


Thank you for information.
It will be helpful for me and other people who would like to try on MinGW32 build.

It would be better to write about my MinGW64 build environments.
However, I do not have enough time to mention it at the moment.

Tatsuro

Re: Win32 build of gnuplot 5.0.2

[Bastian M. <bma...@we...>]

Am 04.02.2016 um 07:00 schrieb Tatsuro MATSUOKA:
> Bastian:
>
> Do you use MinGW32 compliers on the original site(http://www.mingw.org/) ?
>
> Tatsuro


Yes, indeed. I am using MinGW's gcc 4.8.1. Old, but it works.
Also I do use binary packages of libraries whenever possible.
Please find a full list below.

   Bastian


Build environment:
   - recent MinGW/MSYS, GCC v4.8.1, (1)
   - lua 5.2 (1)
   - zlib 1.2.8 (1)
   - cairo 1.10.2 (2)
   - expat 2.0.1 (2)
   - fontconfig 2.8.0 (2)
   - freetype 2.4.2 (2)
   - gettext 0.18.1.1 (2)
   - glib 2.28.8 (2)
   - libpng 1.4.3 (2)
   - pango 1.29.4 (2)
   - pkg-config 0.26 (2)
   - libgd 2.1.0 (3)
   - libjpeg-turbo (4)
   - wxWidgets wxMSW 2.8.12 (5)
   - libcerf 1.3 (6)
   - libcaca SVN rev #4872 (7)
   - Qt 5.1.2 (8)

   (1) binary, http://www.mingw.org/
   (2) binary, http://www.gtk.org/download/win32.php
   (3) source, http://www.libgd.org
   (4) binary, http://www.libjpeg-turbo.org/
   (5) source, http://www.wxwidgets.org/downloads/
   (6) source, http://apps.jcns.fz-juelich.de/src/libcerf/
   (7) source, http://caca.zoy.org/wiki/libcaca
   (8) binary, http://qt-project.org/downloads

Re: array.dem does not exist in demo directory (cvs 2016-02-07)

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2016/2/8, Mon 09:39
> Subject: array.dem does not exist in demo directory (cvs 2016-02-07)
> 
> Hello
> 
> On the cvs tree (ChangeLOg date 2016-02-07),
> a file demo/array.dem is missing.
> 
> 
> Please correct the cvs tree.
> 
> Tatsuro


I have confirmed that the cvs tree now inculdes array.dem.

Thanks!

Tatsuro

array.dem does not exist in demo directory (cvs 2016-02-07)

[Tatsuro M. <tma...@ya...>]

Hello

On the cvs tree (ChangeLOg date 2016-02-07),
a file demo/array.dem is missing.


Please correct the cvs tree.

Tatsuro

Re: set samples , consistency

[Ethan A M. <sf...@us...>]

On Friday, 05 February, 2016 08:38:42 pl...@pi... wrote:
> Hi,
> 
> I have fitted an analytic fn to some data using gnuplot and now I want 
> to create a synthetic monthly dataset by outputting to "table".
> 
> Since gnuplot will always produce a point at start and end of range I 
> specify the plot range in integer years and set samples to  (years-1) 
> *12 +1 to account for the  last year in the range just having one datum 
> point.
> 
> 
> plot [1978:2016] cos3(x) * cos2(x)
> set samples  (2015-1978)*12+1  # 445
> set table "synth.txt"
> rep
> unset table
> 
> This gives the expected number of data lines but the dates are not 
> consistent from year to year. There is a small drift in the decimal part 
> of the dates.
> 
> Only a handful of data lines get an exact beginning of year , ie no 
> decimal part:
> 
>     awk '($1 !~ /[0-9]\./){print}'  "synth.txt"
> 
> # Curve 0 of 1, 445 points
> # Curve title: "cos3(x) * cos2(x))"
> # x y type
>   1978 -0.801801  i
>   1981 -0.895154  i
>   1994 -0.105538  i
>   1997 -0.733846  i
>   2000 -0.563258  i
>   2013  0.204895  i
>   2016 -0.168844  i
> 
> 
> On a 200y range it worked as expected. Is there some rounding error 
> issue or trick I am missing?

Leap years?

The leap-year cycle is 200 years.