Si je veux allouer un tableau de char (en C) qui est garanti pour être suffisamment grande pour contenir tout valide absolu chemin+nom de fichier, la taille est-il besoin de l'être.
Sur Win32, il y a la MAX_PATH définir. Quel est l'équivalent pour Unix/linux?
Il y a un PATH_MAX mais c'est un peu problématique. Selon "l'homme realpath' description:
Ne jamais utiliser cette fonction. Il est interrompu par la conception depuis l' il est impossible de déterminer une taille appropriée pour la sortie de la mémoire tampon. Selon POSIX un tampon de taille PATH_MAX suffit, mais PATH_MAX n'a pas besoin d'être défini constante, et peuvent être obtenues à l'aide de pathconf(). Et en demandant pathconf() n'est pas vraiment utile, puisque, d'une part, POSIX avertit que le résultat de pathconf() peuvent être énormes, et inadapté pour mallocing de la mémoire. Et d'autre part pathconf() peut retourner -1 pour indiquer que PATH_MAX n'est pas délimitée.
Les autres réponses pour l'instant, tout semble sur le point droit sur les *nix côté des choses, mais je vais ajouter un avertissement à ce sujet sur Windows.
Vous avez menti (par omission) par la documentation.
MAX_PATH est en effet défini, et probablement même s'applique à des fichiers stockés sur FAT ou FAT32. Cependant, aucun nom de chemin d'accès peut être préfixé par \\?\ de raconter l'API Windows pour ignorer MAX_PATH et de laisser le pilote de système de fichiers sur son propre esprit. Après cela, les définitions obtenir floue.
Ajouter au mélange le fait que les noms de chemin d'accès sont en fait des caractères Unicode (bien, UT-16) et que, lorsque la "ANSI" API est utilisée la conversion vers et depuis l'intérieur de l'Unicode nom dépend d'un tas de facteurs, y compris la page de code, et vous avez une recette pour la confusion.
Une bonne description des règles pour Windows est à MSDN. Les règles sont beaucoup plus compliqué que ce que j'ai résumé ici.
Edit: j'ai changé d' \\.\ de \\?\ dans le ci-dessus grâce à l'observation de KitsuneYMG.
Windows les chemins et les espaces de noms sont compliqués. Certains pourraient même dire qu'ils sont trop compliqués. Une source de complexité, c'est que le Win32 (et maintenant Win64) de l'API est un sous-système qui fixe sur le haut de la Windows NT système natif.
Un chemin sans préfixe est compatible avec toute la gamme la plus large de plates-formes Windows. Si elle est restreinte à des caractères ASCII 7 bits, il est compatible avec DOS 16 bits depuis la version 2.0 (à chaque fois que les sous-répertoires ont été introduites, ce qui pourrait en fait avoir été dans le DOS 3; mais le DOS 1.0 avait répertoires racine et l' \ personnage avait pas de signification particulière).
L' \\?\ préfixe cause l'équilibre du nom de chemin d'accès pour être passé sur verbatim approprié pilote de système de fichiers, qui est ce qui produit l'effet de l'abandon de la restriction à l' MAX_PATH caractères. Si le long nom de chemin d'accès est également sur un partage réseau, vous pouvez utiliser une extension de nom UNC avec le préfixe \\?\UNC\server\share\ , au lieu de la normale nom UNC \\server\share\. L'utilisation de ce préfixe limite la portabilité pour Win32 et, plus tard, les plates-formes Windows, mais si vous avez besoin de support pour Windows 16 bits sur un matériel d'ancienne génération, qui n'est pas un gros problème.
L' \\.\ préfixe est un animal différent. Il permet d'accéder à l'appareil des objets au-delà de l'ensemble de spécialement nommé dispositifs qui sont mappées automatiquement par Windows comme spécial des noms de fichiers dans chaque dossier. Ces noms spéciaux comprennent CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, et LPT9. Notez que tous ces noms sont spéciaux de savoir si ou non une extension est utilisée, ou dans un mélange de majuscules ou en minuscules. Mais il est possible que vous ayez 10 ou plusieurs ports COM installé. Cela se produit très rapidement, si vous jouez avec les modems USB ou port série USB, adaptateurs, puisque chaque unique USB port série sera affecté à une distincte COMn nom. Si vous avez besoin d'accéder à la 50e port série, vous pouvez le faire seulement avec le nom de l' \\.\COM50 parce que COM50 est pas un nom spécial comme COM1 est.
La page MSDN j'ai cité ci-dessus a eu la distinction droit, j'ai simplement tapé le mauvais préfixe dans ma réponse originale à cette question.
Eh bien, sur Linux, au moins, il y a:
PATH_MAX (définie en limits.h)
FILENAME_MAX (définie en stdio.h)
deux de ceux-ci sont définis à l' 4096 sur mon système (x86 Linux).
Mise à jour: : Quelques infos de la glibc manuel sur ce
Chacune des macros suivantes est défini dans les limites.h uniquement si le système est fixe, limite uniforme pour le paramètre en question. Si le système permet aux différents systèmes de fichiers ou des fichiers à avoir des limites différentes, alors la macro n'est pas défini; utilisation pathconf ou fpathconf pour trouver la limite qui s'applique à un fichier particulier
FILENAME_MAX est une partie de l'ISO C standard, il fonctionne sous UNIX et Windows. Cependant, la bibliothèque C de GNU de documentation contient les mises en garde suivantes:
"Contrairement à PATH_MAX, cette macro est définie, même si il n'y a aucune limite imposée. Dans ce cas, sa valeur est généralement un très grand nombre. C'est toujours le cas sur le système GNU.
Note d'utilisation: Ne pas utiliser FILENAME_MAX que la taille d'un tableau dans lequel stocker un nom de fichier! Vous ne pouvez pas peut-être en faire un tableau qui de grands! L'utilisation de l'allocation dynamique."
Vous pouvez utiliser pathconf() à la figure au moment de l'exécution, mais il y a aussi un PATH_MAX préprocesseur de définir, en <limits.h>.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
