[Tcsh] Is dolet (@) prone to undefined behavior upon overflow? (Possible overflow issue.)

[Matheus Garcia]

https://bugs.astron.com/view.php?id=520
https://github.com/tcsh-org/tcsh/pull/101
I'm not sure if my solution is portable, but is what made the fix. I also provide portability among different character encodings. Lastly, line 193 on sh.exp.c has a wrong type.

________________________________

Good morning/afternoon/evening. I noticed putn1 breaks the conversion if the last bit is set.

On my machine (an ARM-based cellphone)
@ calc = ( 1 << 63 )
raises a "@: Badly formed number." error. I inspected why's that, and turns out the conversion yields a '(' (left parenthesis) character.

I can't tell for sure if the program is careful on overflow. I can mostly tell it isn't, since none of the variables are unsigned, and there doesn't seem to exist any checks on overflow.

Changing putn1's argument to unsigned remedied the issue.

I'd appreciate for feedbacks on other machines and systems. Note dolet and its counterparts are typed as tcsh_number_t, which, depending on the machine, may be a long or long long type. If
@ calc = ( 1 << 63 )
doesn't raise an error, you may need a larger second operand; else, you're lucky enough for it not to cause an error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.astron.com/pipermail/tcsh/attachments/20240502/5f4c5c78/attachment.htm>