Re: Uninitialized variable sometimes causing malformed TFM files
Marcel Fabian Krüger <[email protected]> Sun, 16 Jun 2019 16:28:33 +0200
| Newsgroups | gmane.comp.tex.metapost |
|---|---|
| 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 <[email protected]> > 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 < > > [email protected]> wrote ---- > > > > > > > > > > > > On Wed, Mar 20, 2019 at 6:54 PM Marcel Krüger <[email protected]> > > 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 -- http://tug.org/metapost/