Subject: bug#17681: 24.3.91; "Arithmetic Error" in hide-ifdef mode when using shift operators

From: Luke Lee <[email-masked]>
Date: Fri, 6 Jun 2014 19:11:08 +0800

>Is this patch posted anywhere?

I only send it to Stefan for review since it's a set of patches
that forms the complete work of

http://www.emacswiki.org/emacs/hideif.el.

Patch set #1 has already been submitted into Emacs trunk
while patch set #2 is still under Stefan's reviewing. Patchset
#3 to come. All 3 patches forms the hideif.el posted on
EmacsWiki. You can try this version.

>When you say fail, do you mean it will give an error?
>If so, why not ignore-errors around these evaluations?

Different versions of Emacs seems to behave
differently. On my Linux machine it's Emacs 24.3.50.2
and it does not throw any error. On Cygwin Emacs
24.3.2 it throw an error. It seems that others' submitted
`hif-string-to-number' introduced some difference.

On Cygwin's Emacs version the `split-string' function
used in `hif-string-to-number' take no more than 3
arguments but it takes 4 arguments in my Linux
Emacs 24.3.50.2. After fixing this they still behave
differently. I'm focusing on Linux version so I did
not investigate what makes the difference.

Due to the internal behavior of hideif sometimes it's
not so easy to just ignore some errors then continue.
There are still some cases that hideif will throw an
error. To prevent hideif from throwing any errors, it's
actually another TODO item. I'll first complete the
reviewing of the remaining patch set.

2014-06-06 15:17 GMT+08:00 Glenn Morris <[email-masked]>:

> Luke Lee wrote:
>
> >>I think he already sent me a patch fixing this problem
> >
> > Yes, I think my new patch fixed that problem.
>
> Is this patch posted anywhere?
>
> > However, if you're trying to hide jiffies.h it will eventually failed
> > at some other place due to the "unsigned long" integer postfix (i.e.
> > the "UL" in 100000UL), which hideif still consider it a "TODO".
> >
> > #define TICK_USEC ((1000000UL + USER_HZ/2) / USER_HZ)
>
> When you say fail, do you mean it will give an error?
> If so, why not ignore-errors around these evaluations?
>

-- 
Best regards,
Luke Lee