From tex at 2krueger.de  Sun Jun 16 15:40:34 2019
From: tex at 2krueger.de (Marcel Fabian =?utf-8?Q?Kr=C3=BCger?=)
Date: Sun, 16 Jun 2019 15:40:34 +0200
Subject: [metapost] Uninitialized variable sometimes causing malformed
 TFM files
In-Reply-To: <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
References: <1698775e004.126d363e2137320.9078909525616149190@2krueger.de>
 <CAG5iGsALzOz6RRds_9GEEN8TzMyiuAPHipQohgs0gyHzXN5vMQ@mail.gmail.com>
 <1699c3d2363.df453344155867.4688771535091515686@2krueger.de>
 <CAG5iGsBvzuuYNeve=f0dxrT0B+yXiFueTCkTb-SLRNba+TXS9w@mail.gmail.com>
 <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
Message-ID: <20190616134034.3huyohkn43km6wsk@yoga>

On Wed, Mar 20, 2019 at 08:26:22PM +0100, Marcel Kr?ger wrote:
>  ---- On Wed, 20 Mar 2019 19:01:08 +0100 luigi scarso <luigi.scarso at gmail.com> wrote ----
>  > 
>  > 
>  > On Wed, Mar 20, 2019 at 6:54 PM Marcel Kr&uuml;ger <tex at 2krueger.de> wrote:
>  > Thanks. There is one other thing, I do not really know if I would describe it as a backward compatibility bug or a feature request:
>  > 
>  > For non-"scaled" numbersystems, code like
>  > 
>  > filldraw stroke z1e--z2e;
>  > (example taken from cmbase.mf, `left_bracket`)
>  > 
>  > fail, because z1e-- is interpreted as z 1e- - instead of z1e --. So z1e--z2e is equal to z1-z2e, leading to lots of errors.
>  > 
>  > I understand that the new numbersystems and the exponential syntax can lead to problems of this kind, but I think this could be avoided:
>  > Maybe a `e+` / `e-` could only be interpreted as exponential notation if it is followed by a  digit? I do not think
>  > anyone would write "1e-" or "3e+" for 1 or 3, so it should not lead to any breakage.
>  > On the other hand it would catch almost all cases where this is invoked accidentially.
>  > 
>  > A possible implementation of this change  is attached.
>  > 
>  > 
>  > hm it looks like a serious bug, and I fear I will not able to fix it for next TL --- but I hope to put it into trunk immediately after the TL code is frozen.
>  > 
> 
> Right, I am sorry for bringing this up so late in the TL cycle.
> 
> One additional note on this: The behaviour described above (`1e-` being interpreted as `1`) seems to be specific to the `double` mode.
> The `decimal` mode just fails because it is not able to parse the number, which further reduces the risk of breaking some code by changing the current
> behaviour.
> 
> Also I attached a fixed version of the earlier patch, there was a smaller error.
> 
> Best regards,
> Marcel Kr?ger
> 
>  > 
>  > -- 
>  > luigi
>  >

Hi,

are there still plans to fix this?

Best regards,
Marcel




From luigi.scarso at gmail.com  Sun Jun 16 15:53:36 2019
From: luigi.scarso at gmail.com (luigi scarso)
Date: Sun, 16 Jun 2019 15:53:36 +0200
Subject: [metapost] Uninitialized variable sometimes causing malformed
	TFM files
In-Reply-To: <20190616134034.3huyohkn43km6wsk@yoga>
References: <1698775e004.126d363e2137320.9078909525616149190@2krueger.de>
 <CAG5iGsALzOz6RRds_9GEEN8TzMyiuAPHipQohgs0gyHzXN5vMQ@mail.gmail.com>
 <1699c3d2363.df453344155867.4688771535091515686@2krueger.de>
 <CAG5iGsBvzuuYNeve=f0dxrT0B+yXiFueTCkTb-SLRNba+TXS9w@mail.gmail.com>
 <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
 <20190616134034.3huyohkn43km6wsk@yoga>
Message-ID: <CAG5iGsAvBJ90AsD4Ytqg8rbjN77BF8p7F991BVtkCOuHF7RrRQ@mail.gmail.com>

On Sun, Jun 16, 2019 at 3:41 PM Marcel Fabian Kr?ger <tex at 2krueger.de>
wrote:

> On Wed, Mar 20, 2019 at 08:26:22PM +0100, Marcel Kr?ger wrote:
> >  ---- On Wed, 20 Mar 2019 19:01:08 +0100 luigi scarso <
> luigi.scarso at gmail.com> wrote ----
> >  >
> >  >
> >  > On Wed, Mar 20, 2019 at 6:54 PM Marcel Kr&uuml;ger <tex at 2krueger.de>
> wrote:
> >  > Thanks. There is one other thing, I do not really know if I would
> describe it as a backward compatibility bug or a feature request:
> >  >
> >  > For non-"scaled" numbersystems, code like
> >  >
> >  > filldraw stroke z1e--z2e;
> >  > (example taken from cmbase.mf, `left_bracket`)
> >  >
> >  > fail, because z1e-- is interpreted as z 1e- - instead of z1e --. So
> z1e--z2e is equal to z1-z2e, leading to lots of errors.
> >  >
> >  > I understand that the new numbersystems and the exponential syntax
> can lead to problems of this kind, but I think this could be avoided:
> >  > Maybe a `e+` / `e-` could only be interpreted as exponential notation
> if it is followed by a  digit? I do not think
> >  > anyone would write "1e-" or "3e+" for 1 or 3, so it should not lead
> to any breakage.
> >  > On the other hand it would catch almost all cases where this is
> invoked accidentially.
> >  >
> >  > A possible implementation of this change  is attached.
> >  >
> >  >
> >  > hm it looks like a serious bug, and I fear I will not able to fix it
> for next TL --- but I hope to put it into trunk immediately after the TL
> code is frozen.
> >  >
> >
> > Right, I am sorry for bringing this up so late in the TL cycle.
> >
> > One additional note on this: The behaviour described above (`1e-` being
> interpreted as `1`) seems to be specific to the `double` mode.
> > The `decimal` mode just fails because it is not able to parse the
> number, which further reduces the risk of breaking some code by changing
> the current
> > behaviour.
> >
> > Also I attached a fixed version of the earlier patch, there was a
> smaller error.
> >
> > Best regards,
> > Marcel Kr?ger
> >
> >  >
> >  > --
> >  > luigi
> >  >
>
> Hi,
>
> are there still plans to fix this?
>
> Best regards,
> Marcel
>
>
>
> --
> http://tug.org/metapost/
>

Hm, have you mixed email ?
Here Subject  says
Re: [metapost] Uninitialized variable sometimes causing malformed TFM files
the content is quite different .

-- 
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/metapost/attachments/20190616/d495089e/attachment.html>

From tex at 2krueger.de  Sun Jun 16 15:59:38 2019
From: tex at 2krueger.de (Marcel Fabian =?utf-8?Q?Kr=C3=BCger?=)
Date: Sun, 16 Jun 2019 15:59:38 +0200
Subject: [metapost] Uninitialized variable sometimes causing malformed
 TFM files
In-Reply-To: <CAG5iGsAvBJ90AsD4Ytqg8rbjN77BF8p7F991BVtkCOuHF7RrRQ@mail.gmail.com>
References: <1698775e004.126d363e2137320.9078909525616149190@2krueger.de>
 <CAG5iGsALzOz6RRds_9GEEN8TzMyiuAPHipQohgs0gyHzXN5vMQ@mail.gmail.com>
 <1699c3d2363.df453344155867.4688771535091515686@2krueger.de>
 <CAG5iGsBvzuuYNeve=f0dxrT0B+yXiFueTCkTb-SLRNba+TXS9w@mail.gmail.com>
 <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
 <20190616134034.3huyohkn43km6wsk@yoga>
 <CAG5iGsAvBJ90AsD4Ytqg8rbjN77BF8p7F991BVtkCOuHF7RrRQ@mail.gmail.com>
Message-ID: <20190616135938.52nntt3iolo2lndn@yoga>

On Sun, Jun 16, 2019 at 03:53:36PM +0200, luigi scarso wrote:
> [...]
> 
> Hm, have you mixed email ?
> Here Subject  says
> Re: [metapost] Uninitialized variable sometimes causing malformed TFM files
> the content is quite different .
> 
> -- 
> luigi

That's because the original report was part of an answer in a mostly
unrelated thread and I was too lazy to change the subject back then...


From luigi.scarso at gmail.com  Sun Jun 16 16:14:00 2019
From: luigi.scarso at gmail.com (luigi scarso)
Date: Sun, 16 Jun 2019 16:14:00 +0200
Subject: [metapost] Uninitialized variable sometimes causing malformed
	TFM files
In-Reply-To: <20190616134034.3huyohkn43km6wsk@yoga>
References: <1698775e004.126d363e2137320.9078909525616149190@2krueger.de>
 <CAG5iGsALzOz6RRds_9GEEN8TzMyiuAPHipQohgs0gyHzXN5vMQ@mail.gmail.com>
 <1699c3d2363.df453344155867.4688771535091515686@2krueger.de>
 <CAG5iGsBvzuuYNeve=f0dxrT0B+yXiFueTCkTb-SLRNba+TXS9w@mail.gmail.com>
 <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
 <20190616134034.3huyohkn43km6wsk@yoga>
Message-ID: <CAG5iGsD4Xb+WeemuokAgJ-COB=Cnx2O0EHo1k-2m5tqWe+82Bw@mail.gmail.com>

On Sun, Jun 16, 2019 at 3:41 PM Marcel Fabian Kr?ger <tex at 2krueger.de>
wrote:

> On Wed, Mar 20, 2019 at 08:26:22PM +0100, Marcel Kr?ger wrote:
> >  ---- On Wed, 20 Mar 2019 19:01:08 +0100 luigi scarso <
> luigi.scarso at gmail.com> wrote ----
> >  >
> >  >
> >  > On Wed, Mar 20, 2019 at 6:54 PM Marcel Kr&uuml;ger <tex at 2krueger.de>
> wrote:
> >  > Thanks. There is one other thing, I do not really know if I would
> describe it as a backward compatibility bug or a feature request:
> >  >
> >  > For non-"scaled" numbersystems, code like
> >  >
> >  > filldraw stroke z1e--z2e;
> >  > (example taken from cmbase.mf, `left_bracket`)
> >  >
> >  > fail, because z1e-- is interpreted as z 1e- - instead of z1e --. So
> z1e--z2e is equal to z1-z2e, leading to lots of errors.
> >  >
> >  > I understand that the new numbersystems and the exponential syntax
> can lead to problems of this kind, but I think this could be avoided:
> >  > Maybe a `e+` / `e-` could only be interpreted as exponential notation
> if it is followed by a  digit? I do not think
> >  > anyone would write "1e-" or "3e+" for 1 or 3, so it should not lead
> to any breakage.
> >  > On the other hand it would catch almost all cases where this is
> invoked accidentially.
> >  >
> >  > A possible implementation of this change  is attached.
> >  >
> >  >
> >  > hm it looks like a serious bug, and I fear I will not able to fix it
> for next TL --- but I hope to put it into trunk immediately after the TL
> code is frozen.
> >  >
> >
> > Right, I am sorry for bringing this up so late in the TL cycle.
> >
> > One additional note on this: The behaviour described above (`1e-` being
> interpreted as `1`) seems to be specific to the `double` mode.
> > The `decimal` mode just fails because it is not able to parse the
> number, which further reduces the risk of breaking some code by changing
> the current
> > behaviour.
> >
> > Also I attached a fixed version of the earlier patch, there was a
> smaller error.
> >
> > Best regards,
> > Marcel Kr?ger
> >
> >  >
> >  > --
> >  > luigi
> >  >
>
> Hi,
>
> are there still plans to fix this?
>
>
yes


-- 
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/metapost/attachments/20190616/d7fab72e/attachment.html>

From tex at 2krueger.de  Sun Jun 16 16:28:33 2019
From: tex at 2krueger.de (Marcel Fabian =?utf-8?Q?Kr=C3=BCger?=)
Date: Sun, 16 Jun 2019 16:28:33 +0200
Subject: [metapost] Uninitialized variable sometimes causing malformed
 TFM files
In-Reply-To: <CAG5iGsD4Xb+WeemuokAgJ-COB=Cnx2O0EHo1k-2m5tqWe+82Bw@mail.gmail.com>
References: <1698775e004.126d363e2137320.9078909525616149190@2krueger.de>
 <CAG5iGsALzOz6RRds_9GEEN8TzMyiuAPHipQohgs0gyHzXN5vMQ@mail.gmail.com>
 <1699c3d2363.df453344155867.4688771535091515686@2krueger.de>
 <CAG5iGsBvzuuYNeve=f0dxrT0B+yXiFueTCkTb-SLRNba+TXS9w@mail.gmail.com>
 <1699c919c7d.e8e30d05168651.6545474686828599898@2krueger.de>
 <20190616134034.3huyohkn43km6wsk@yoga>
 <CAG5iGsD4Xb+WeemuokAgJ-COB=Cnx2O0EHo1k-2m5tqWe+82Bw@mail.gmail.com>
Message-ID: <20190616142833.j2rvouuxrpy3242i@yoga>

On Sun, Jun 16, 2019 at 04:14:00PM +0200, luigi scarso wrote:
> On Sun, Jun 16, 2019 at 3:41 PM Marcel Fabian Kr?ger <tex at 2krueger.de>
> wrote:
> 
> > On Wed, Mar 20, 2019 at 08:26:22PM +0100, Marcel Kr?ger wrote:
> > >  ---- On Wed, 20 Mar 2019 19:01:08 +0100 luigi scarso <
> > luigi.scarso at gmail.com> wrote ----
> > >  >
> > >  >
> > >  > On Wed, Mar 20, 2019 at 6:54 PM Marcel Kr&uuml;ger <tex at 2krueger.de>
> > wrote:
> > >  > Thanks. There is one other thing, I do not really know if I would
> > describe it as a backward compatibility bug or a feature request:
> > >  >
> > >  > For non-"scaled" numbersystems, code like
> > >  >
> > >  > filldraw stroke z1e--z2e;
> > >  > (example taken from cmbase.mf, `left_bracket`)
> > >  >
> > >  > fail, because z1e-- is interpreted as z 1e- - instead of z1e --. So
> > z1e--z2e is equal to z1-z2e, leading to lots of errors.
> > >  >
> > >  > I understand that the new numbersystems and the exponential syntax
> > can lead to problems of this kind, but I think this could be avoided:
> > >  > Maybe a `e+` / `e-` could only be interpreted as exponential notation
> > if it is followed by a  digit? I do not think
> > >  > anyone would write "1e-" or "3e+" for 1 or 3, so it should not lead
> > to any breakage.
> > >  > On the other hand it would catch almost all cases where this is
> > invoked accidentially.
> > >  >
> > >  > A possible implementation of this change  is attached.
> > >  >
> > >  >
> > >  > hm it looks like a serious bug, and I fear I will not able to fix it
> > for next TL --- but I hope to put it into trunk immediately after the TL
> > code is frozen.
> > >  >
> > >
> > > Right, I am sorry for bringing this up so late in the TL cycle.
> > >
> > > One additional note on this: The behaviour described above (`1e-` being
> > interpreted as `1`) seems to be specific to the `double` mode.
> > > The `decimal` mode just fails because it is not able to parse the
> > number, which further reduces the risk of breaking some code by changing
> > the current
> > > behaviour.
> > >
> > > Also I attached a fixed version of the earlier patch, there was a
> > smaller error.
> > >
> > > Best regards,
> > > Marcel Kr?ger
> > >
> > >  >
> > >  > --
> > >  > luigi
> > >  >
> >
> > Hi,
> >
> > are there still plans to fix this?
> >
> >
> yes

Great, thank you.

Marcel