
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>

<body>

<div>https://bugs.astron.com/view.php?id=520

<div>https://github.com/tcsh-org/tcsh/pull/101</div>

<div>I'm not sure if my solution is portable, but is what made the fix. I also provide portability among different character encodings. <span style="color: var(--textPrimary);">Lastly, line 193 on sh.exp.c has a wrong type.</span></div>

<div><br>

</div>

</div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><br>

</div>

<div>

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

<div><br>

</div>

<div>On my machine (an ARM-based cellphone)</div>

<div>@ calc = ( 1 << 63 )</div>

<div>raises a "@: Badly formed number." error. I inspected why's that, and turns out the conversion yields a '(' (left parenthesis) character.</div>

<div><br>

</div>

<div>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.</div>

<div><br>

</div>

<div>Changing putn1's argument to unsigned remedied the issue.</div>

<div><br>

</div>

<div>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</div>

<div>@ calc = ( 1 << 63 )</div>

<div>doesn't raise an error, you may need a larger second operand; else, you're lucky enough for it not to cause an error.</div>

</div>

</body>

</html>