AUTO変数領域サイズ計算のワード桁あふれを修正 (GH#2 取りこぼし)

[shuyo]

概要

src/*.has の見逃しバグ確認ワークフロー中に発見。GH#2（str変数128個以上でワードオフセットが符号反転）の修整が AUTO（func ローカル）変数領域では str しか直っていなかった取りこぼしを修正する。

詳細

XB2.HAS の Variable_clr_sub（v_initF パス）は、型ごとに変数領域サイズを a1 に加算してエリア先頭ポインタを並べる。GH#2 修整時に str だけ ext.l + adda.l（32bit）化され、int/char/float は adda.w（ワード）のまま残っていた。

adda.w は加算値を符号拡張するため、サイズが $8000 以上になると符号反転して領域が壊れる。1関数内のその型のローカル変数数で：

型	修整前	あふれ閾値
int	lsl.w #2→adda.w（×4）	約8192個
char	andi.w→adda.w（≈×1）	約32765個
float	lsl.w #3→adda.w（×8）	約4096個
str	ext.l+lsl.l #8+adda.l	✅ GH#2で修整済

str と同じ ext.l + 32bit 加算に揃え、閾値を約32767に引き上げた（実質無制限）。空の型（個数-1 = -1）は addq.w #1 を先に行う既存イディオムで 0 になり、ext.l 後も正しく 0 のまま。

clear パス（a1_clr_d0x4）は a1 をポインタ後置増分で進め、ワード dbra の閾値も int/char/float とも ≥32768（str init 修整値と同等）なので変更不要。GLOBAL 変数領域（XBSTAT.HAS）は既に正しく long。

影響

実用閾値（1関数に数千個のローカル変数）は高く即時被害は考えにくいが、GH#2 と同クラスの潜在バグであり、str の修整との一貫性も欠いていた。

検証

HAS.X でビルドし run68 で：

• グローバル変数プログラム（SELFTEST）：正常
• func ローカル int/char/float（autovar）：ret=30 / c=65 / g=1.25 すべて正しい（修整したパスを実際に通過）
• アセンブルエラーなし

🤖 Generated with Claude Code