GetTickCount() を GetTickCount64() へ置き換える

[nmaya]

PR #1333

---

やりたいことの主目的はなんですか？

• uptime64 マクロコマンド
• int64 型を追加すること
• GetTickCount() で C28159 警告が出るのをつぶすこと

[m-tmatma]

内部管理を GetTickCount64 にすることです。
これにより 約49.7日でオーバーでも経過時間を正しく扱えるようになります。

それにともない uptime64 のコマンドの追加が必要になり
さらに int64 型の追加が必要になりました。

[hkanou]

uptime64 マクロコマンド

Tera Termマクロに int64 型を追加する修正と思われました。
下記の考慮はなされていますでしょうか？

1. データ型
   https://teratermproject.github.io/manual/5/ja/macro/syntax/types.html
   整数が2種類になることについて
2. 定数の形式
   https://teratermproject.github.io/manual/5/ja/macro/syntax/formats.html
   16進数表記への対応
3. マクロコマンドにint64を渡した時の挙動
   (例) fileseek：int64 型により2GBの制限が解除されるのか？ 等

[nmaya]

ライセンスについて

PR には Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> とあります。
Tera Term は BSD ライセンスです。
PR の内容に、BSD ライセンスと矛盾するもの（たとえばGPLライセンスのコードなど）がないことを、どのように確認していますか？

[nmaya]

マクロ言語の仕様について

@hkanou さんとかぶるかもしれませんし、これですべてではないと思いますが、思いついた点を書いておきます。

宣言について

整数型変数は宣言がいりませんが、64ビット整数型変数は宣言がいる、という仕様ですか？
対称性がありませんが、どうでしょうか？

型について

• 64ビット整数型変数に、(32ビット)整数型変数から代入することはできますか？
• 64ビット整数型変数に、(32ビット)整数リテラルから代入することはできますか？
• 64ビット整数型変数に、64ビット整数型変数から代入することはできますか？
• 64ビット整数型変数に、64ビット整数リテラルから代入することはできますか？
  • 64ビット整数のリテラルは存在しますか？
• 「既存の32ビット整数値を受け取るマクロコマンド」に、64ビット整数型変数を渡すことができますか？

既存コマンドの互換性ついて

マクロコマンド全体のドキュメントにおいて、既存のコマンドは64ビットを想定していません。

• 「整数値」は「(32ビット)整数リテラル」または「(32ビット)整数型変数」を表す
• 「整数型変数」は「(32ビット)整数型変数」を表す
• 「整数配列型」は「(32ビット)整数の配列」を表す

今回の変更で、64ビット整数（型変数あるいはリテラル）が追加され、これを受け取れないのであれば、そのことを明記する必要があるか

[m-tmatma]

uptime64 マクロコマンド

Tera Termマクロに int64 型を追加する修正と思われました。 下記の考慮はなされていますでしょうか？

1. データ型
   https://teratermproject.github.io/manual/5/ja/macro/syntax/types.html
   整数が2種類になることについて
2. 定数の形式
   https://teratermproject.github.io/manual/5/ja/macro/syntax/formats.html
   16進数表記への対応
3. マクロコマンドにint64を渡した時の挙動
   (例) fileseek：int64 型により2GBの制限が解除されるのか？ 等

考慮はできていません。

[m-tmatma]

ライセンスについて

PR には Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> とあります。 Tera Term は BSD ライセンスです。 PR の内容に、BSD ライセンスと矛盾するもの（たとえばGPLライセンスのコードなど）がないことを、どのように確認していますか？

Anthropicの立場
Anthropicは、Claudeが生成したコードについて著作権を主張しません。生成されたコードは、プロンプトを入力したユーザー（またはその組織）に帰属するか、著作権の保護対象外（パブリックドメイン相当）とみなされます。
つまり Co-Authored-By: Claude Sonnet 4.6 という表記があっても、ClaudeやAnthropicがそのコードにBSDと矛盾するライセンス条件を付与することはありません。

結論：現時点では「確認できている」とは言えない。
Claude（およびClaude Code）は、生成したコードがGPLなど他ライセンスと矛盾しないことを自動的・確実に保証する仕組みを持っていない。
具体的には：

Anthropicは著作権侵害を避けるよう設計しているが、逐語的な再現を100%防ぐ保証はない
生成時に「これはGPL実装を参考にした」といった出典追跡をしていない
Co-Authored-Byの記載は貢献の明示であり、ライセンスの保証ではない

[m-tmatma]

マクロ言語の仕様について

@hkanou さんとかぶるかもしれませんし、これですべてではないと思いますが、思いついた点を書いておきます。

宣言について

整数型変数は宣言がいりませんが、64ビット整数型変数は宣言がいる、という仕様ですか？ 対称性がありませんが、どうでしょうか？

はい。
整数型が省略できるという仕様であれば、対称性を確保するのは無理だと思います。

型について

• 64ビット整数型変数に、(32ビット)整数型変数から代入することはできますか？

はい

• 64ビット整数型変数に、(32ビット)整数リテラルから代入することはできますか？

はい

• 64ビット整数型変数に、64ビット整数型変数から代入することはできますか？

はい

• 64ビット整数型変数に、64ビット整数リテラルから代入することはできますか？

  • 64ビット整数のリテラルは存在しますか？

いいえ、64ビット整数リテラルは定義していません。

• 「既存の32ビット整数値を受け取るマクロコマンド」に、64ビット整数型変数を渡すことができますか？

渡せるが、上位ビットは切り捨てられます。

既存コマンドの互換性ついて

マクロコマンド全体のドキュメントにおいて、既存のコマンドは64ビットを想定していません。

• 「整数値」は「(32ビット)整数リテラル」または「(32ビット)整数型変数」を表す
• 「整数型変数」は「(32ビット)整数型変数」を表す
• 「整数配列型」は「(32ビット)整数の配列」を表す

今回の変更で、64ビット整数（型変数あるいはリテラル）が追加され、これを受け取れないのであれば、そのことを明記する必要があるか

[m-tmatma]

PR の内容に、BSD ライセンスと矛盾するもの（たとえばGPLライセンスのコードなど）がないことを、どのように確認していますか？

FOSSID などで確認したわけではないです。

[m-tmatma]

受けた指摘に対応するため 64bit の整数型を別途設けるのではなく 32bit 変数をやめて 64bit 変数に一本化しました。
#1343

[nmaya]

あるかどうかわかりませんが、(32ビット)整数型変数が一回りすることを想定しているコードが動かなくなりませんか？
互換性を破壊していませんか？

[m-tmatma]

整数型変数は宣言がいりませんが、64ビット整数型変数は宣言がいる、という仕様ですか？ 対称性がありませんが、どうでしょうか？

32bit の変数に関して互換性を担保しようとすると、64bit 整数型を明示的に宣言がいるという仕様は
受け入れる必要があります。

[nmaya]

32bit の変数に関して互換性を担保しようとすると、64bit 整数型を明示的に宣言がいるという仕様は
受け入れる必要があります。

本当にそうでしょうか？
2つ考えてみましたが、このような案は成立しませんか？

案1

x = 1 ; int32
y = 2147483648 ; int32を超えるのでint64型になる
z = 9223372036854775808 ; int64 を超えるので代入エラー（代入以前に、int64の範囲外のリテラルな時点でエラー？）
x = 2147483648 ; int32型に対して、int64リテラルの代入なので、代入エラー（値としては収まらないが、それ以前に型エラー）
x = y ; int32型に対して、int64型の代入なので、代入エラー（型エラー）
y = x ; int64型に対して、int32型の代入なので、代入エラー（値としては収まるが、それ以前に型エラー）
y = 1 ; int64型なので、int64型のまま

案2

C# のような書き方
https://araramistudio.blogspot.com/2020/03/cs-literal.html

x = 1 ; int32
y = 2147483648L ; Lサフィックスがあるのでint64リテラル
zz = 1L ; Lサフィックスがあるのでint64リテラル
z = 9223372036854775808L ; int64 を超えるので代入エラー（代入以前に、int64の範囲外のリテラルな時点でエラー？）
x = 2147483647L ; int32型に対して、int64リテラルの代入なので、代入エラー（値としては収まるが、それ以前に型エラー）
x = 2147483648L ; int32型に対して、int64リテラルの代入なので、代入エラー（値としては収まらないが、それ以前に型エラー）
x = 1L ; int32型に対して、int64リテラルの代入なので、代入エラー（値としては収まるが、それ以前に型エラー）
x = y ; int32型に対して、int64型の代入なので、代入エラー（型エラー）
y = 1 ; int64型に対して、int32リテラルの代入なので、代入エラー（値としては収まるが、それ以前に型エラー）
y = x ; int64型に対して、int32型の代入なので、代入エラー（値としては収まるが、それ以前に型エラー）

変換用の関数

案1・案2と併用可と思われる

x = 1 ; int32
y = 2147483648 ; int64
z = int64(1) ; int32（変数またはリテラル）をint64型に変換して返す
x = int32(z) ; int64（変数またはリテラル）をint32型に変換して返す（値として収まる）
x = int32(y) ; int32を超えるので代入エラー（値として収まらない）

[nmaya]

言語を拡張するということについて

すでに存在する（使われている）言語仕様の拡張を検討をしているので、影響範囲を見落としたまま進めることは難しいです。
誰かが既に書いているコードが動かなくなることは可能な限り避けないと、ユーザが困ったりプロジェクトへの負担が増えたりします。
また、将来性がある選択肢があるならそれを選びますし、これまでの構文との一貫性があるかどうかも検討すべきです。（たとえば、以前に /* */ 形式のコメントを追加でサポートしたときに、「; で1行ずつコメントになるタイプの言語なのに一貫性がない」と指摘されたことがあります）