counters issues

[Rimole]

Brief outline of the bug

see https://mirror.ctan.org/macros/latex/contrib/lastpage/lastpage.pdf
Version 2.1d 2024-11-24
subsection 3.11 Page counter overflow
page 6

1. Ignored values: That should never happen. Either it is supported, or there is an error. (At least a warning.)

2. Error message ‘Counter too large’: For example \alph of -1 is not too large (but too small).
   Suggestion for error message: ‘Counter out of range’ and help text: 'Counter has value value, shall be printed as presentation command, which only supports values in the range supported domain.'

3. When -MAX or +MAX is exceeded - get a surprise: see example below. Yes, you could use that to add half a million to MAX, subtract one million, and get the right result in the end, but without any warning that is as dangerous as nitroglycerin.

4. When you change something, I would really appreciate it if the alphalph package is not broken by it (or if it gets fixed at the same time), and also if the \erroralphalph from pageslts package is not broken by it (or if it gets fixed at the same time).

Minimal example showing the bug

\RequirePackage{latexbug}
\documentclass{article}
\newcounter{b}\setcounter{b}{-2147483646}
\addtocounter{b}{0}%
\begin{document}
counters\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
arabic :\arabic{b}:\addtocounter{b}{-1}\\
\end{document}

Log file (required) and possibly PDF file

counters.log

counters.pdf

[davidcarlisle]

It is not clear what bug you are reporting, your point 4 seems to imply that something has changed but the definition of \arabic has not changed since the earliest releases of LaTeX almost 40 years ago, and is basically the behaviour of the TeX primitive \number. As this needs to work in an expansion context there is very limited possibility for raising errors and changing the behaviour after so many decades would almost certainly break some existing uses.

[Rimole]

OK, me bad for reporting several things at once. Let's focus on point 3.:

\documentclass{article}
\newcounter{b}
\begin{document}
\setcounter{b}{-2147483646}
Counter value is $-2147483646$, subtract one \addtocounter{b}{-1} results in value $-2147483647$, printed by \verb|\arabic| as: \arabic{b}, which is OK.\\

Counter value is $-2147483647$, subtract one \addtocounter{b}{-1} results in value $-2147483648$, printed by \verb|\arabic| as: \arabic{b}, which is strange, because $-2147483647$ was said to be the lowest possible value. If\verb|\setcounter{b}{-2147483648}| is used directly, \verb|! Number too big. [...] -2147483648| results.\\

Counter value is $-2147483648$, subtract one \addtocounter{b}{-1} results in mathematical value $-2147483649$, printed by \verb|\arabic| as: \arabic{b} (no negative pre-sign!), which is just $4\,294\,967\,296$ off from the real value. \verb|\setcounter{b}{-2147483649}| again results in an error.\\

\verb|\setcounter{b}{-2000000000}\addtocounter{b}{-2000000000}\arabic{b}| prints $294967296$ instead of either giving an error or printing $-4000000000$.\\

Same with positive numbers:\\

\setcounter{b}{+2147483646}
\noindent Counter value is $+2147483646$, add one \addtocounter{b}{+1} results in value $+2147483647$, printed by \verb|\arabic| as: \arabic{b}, which is OK.\\

Counter value is $+2147483647$, add one \addtocounter{b}{+1} results in value $+2147483648$, printed by \verb|\arabic| as: \arabic{b}, which is strange, because $+2147483647$ was said to be the highest possible value. If\verb|\setcounter{b}{+2147483648}| is used directly, \verb|! Number too big. [...] 2147483648| results.\\

Counter value is $+2147483648$, add one \addtocounter{b}{+1} results in mathematical value $+2147483649$, printed by \verb|\arabic| as: \arabic{b} (negative pre-sign!), which is just $4\,294\,967\,296$ off from the real value. \verb|\setcounter{b}{+2147483649}| again results in an error.\\

\verb|\setcounter{b}{2000000000}\addtocounter{b}{2000000000}\arabic{b}| prints $-294967296$ instead of either giving an error or printing $4000000000$.
\end{document}

So, with \addtocounter you can go beyond +/- MAX without error message. Instead, LaTeX just silently adds -/+ 2 times MAX and continues as if nothing strange had happened. The resulting number is very wrong. I presume the error is not in \arabic but in \addtocounter, more precisely in \advance\csname c@#1\endcsname #2\relax, because \c@b cannot be set outside of +- MAX, but it can be advanced to wrong values.

[u-fischer]

Same with positive numbers:\\

completly unrelated but you should not end paragraphs with \\, that only leads to lots of underfull hbox messages. Use the parskip package or set \parskip if you want space between paragraphs

[davidcarlisle]

I presume the error is not in \arabic but in \addtocounter

The behaviour is not due to LaTeX code at all, but is a feature of the primitive TeX arithmetic which gives a number too big error on assignment but silently wraps round on overflow from addition.

\count0=2147483647
\showthe\count0
\advance\count0 by 1
\showthe\count0

\bye

It Is of course possible to add additional checks at the macro layer or (as with l3fp completely implement arithmentic at that level) but in general there are limits to which LaTeX hides the underlying TeX implementation.

The etex numexpr equivalent does catch this.

\showthe\numexpr\count0+1\relax

throws

! Arithmetic overflow
```

One possibility, which might be useful for other reasons, would be to make the 2e counter commands match the expl3 int module and accept etex numeric expressions in more places, then this issue would be resolved, however there are some compatibility issues related to any such change.