Win32APIで最大長さMAX_PATHの固定長なバッファを取る関数って、このMAX_PATHはバイト数なのか文字数なのかどっちなのだろう… これ文字数だとすると結局固定長とは限らなくなる気がするんだけどどうなんだろ・・・バイト数だと小さすぎる気もするし
2014-03-05 15:07:30@rofi バイト数だったと思います。ファイルシステムとしてはそれ以上も可能で、突破する方法もあるのだけど。MAX_PATH を超えたファイル名に対応していないシステムがそれに触れた瞬間死ぬとかつらいことがたくさん起きてつらい感じだったりしますね・・・
2014-03-05 15:10:14@rofi 基本的にはANSI版の*バイト数*。Unicode版にも同様の*文字数*制限があるけど、それとは別に\\?\プレフィックス付の絶対パス表記にすることで32,767文字まで拡張されるから。
2014-03-05 15:13:26oO( Windows シェルが扱えるファイル名の長さは極端に制限されている。具体的には MAX_PATH "要素" (長さではなく、末尾 null 文字含む) の C 文字列で指せるもののさらに一部。 )
2014-03-05 15:15:10@rofi 基本的には対象バッファの要素数です。なので文字数。余談ですが、shlwapi.hあたりにある Path○○系関数群は、Win8でPathCch○○が追加され、MAX_PATH移譲の長さのパスも扱えるようになりました。(コア部分は以前から長いパス形式に対応してました)
2014-03-05 15:17:39@haxe Aはバイト数でWは文字数なんです…? 文字数っていい方してしまうと、UNICODEだとサロゲートペアとか他にも合成文字があったりして、結局固定長ではなくなってしまう気がするのですが・・・どうなんでしょ
2014-03-05 15:18:37@a4lg あー、やっぱり要素数ですか… となると、AはMAX_PATHバイト、WはMAX_PATH * 2バイトって考えていいんですよね・・・?
2014-03-05 15:19:06@a4lg @rofi 「ディレクトリ\ディレクトリ\…\ファイル名」のファイル名部分の文字数ね。昔はフルパスでもMAX_PATHで収まってたけど。
2014-03-05 15:19:17@overthestardust 文字数という言い方をしてしまうとサロゲートペアとか合成文字とか存在するのでバッファが固定ではなくなってしまう気がするのです… MSDNを見てたらPathCch***なんて関数があったので使おうとしたらWin8とかだったので(
2014-03-05 15:20:36@hasegawayosuke @a4lg あれ、そこなんです…? http://t.co/dzDJucS2oA これとかの場合、バッファ全体がMAX_PATHっぽいんですが
2014-03-05 15:21:58聞いている感じ、固定長でMAX_PATH以上あるいことを要求されてるWIn32APIの関数の場合、要素数がMAX_PATH(AはMAX_PATHバイト、WはMAX_PATH*2バイト)って感じかなー
2014-03-05 15:24:01じゃあ http://t.co/PgMT8pyR5H のように、MAX_PATH と MAX_PATH でパスが渡された場合出力どうなるんだろ…(出力先もMAX_PATH以上が要求されてるがMAX_PATH*2ではない
2014-03-05 15:25:10"In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters." http://t.co/rGdRbKDY8b
2014-03-05 15:28:34