In article <1hkyda0.1cl1qayu3sejaN%, (Une bévue) wrote:
y a t'il une limite de longuer pour un path (absolu) sur MacOS X 10.4+ ???
je suis certain que oui, mais laquelle ?
tu parles de la variable d'environnement ou du nom d'un fichier ?
patpro
-- http://www.patpro.net/
Eric Levenez
Le 31/08/06 21:07, dans <1hkyda0.1cl1qayu3sejaN%, « Une bévue » a écrit :
y a t'il une limite de longuer pour un path (absolu) sur MacOS X 10.4+ ???
La valeur du PATH complet d'un fichier donné dépend du système de fichier (HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Bref, il y a de tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 31/08/06 21:07, dans
<1hkyda0.1cl1qayu3sejaN%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
y a t'il une limite de longuer pour un path (absolu) sur MacOS X 10.4+
???
La valeur du PATH complet d'un fichier donné dépend du système de fichier
(HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il
va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long.
La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS
c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256
octets.
Bref, il y a de tout.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 31/08/06 21:07, dans <1hkyda0.1cl1qayu3sejaN%, « Une bévue » a écrit :
y a t'il une limite de longuer pour un path (absolu) sur MacOS X 10.4+ ???
La valeur du PATH complet d'un fichier donné dépend du système de fichier (HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Bref, il y a de tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pere.noel
patpro ~ patrick proniewski wrote:
tu parles de la variable d'environnement ou du nom d'un fichier ?
du nom d'un fichier, je viens de lire la tech Note 2078 : <http://developer.apple.com/technotes/tn2002/tn2078.html>
qui annonce qu'encodé en UTF16 :
For example, a 32-bit based HFSUniStr255 (used for file names in Mac OS X) would occupy 1022 bytes, even though most file names consist of less than 40-50 characters in the BMP.
c'est pour mes malloc en C...
une var d'environnement ca peut-être n fois plus long encore, je suppose ???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc... -- une bévue
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
tu parles de la variable d'environnement ou du nom d'un fichier ?
du nom d'un fichier, je viens de lire la tech Note 2078 :
<http://developer.apple.com/technotes/tn2002/tn2078.html>
qui annonce qu'encodé en UTF16 :
For example, a 32-bit based HFSUniStr255 (used for file names
in Mac OS X) would occupy 1022 bytes, even though most file names
consist of less than 40-50 characters in the BMP.
c'est pour mes malloc en C...
une var d'environnement ca peut-être n fois plus long encore, je suppose
???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour
les noms de fichiers (basename en shell), il va sans doute falloir
passer par realloc...
--
une bévue
tu parles de la variable d'environnement ou du nom d'un fichier ?
du nom d'un fichier, je viens de lire la tech Note 2078 : <http://developer.apple.com/technotes/tn2002/tn2078.html>
qui annonce qu'encodé en UTF16 :
For example, a 32-bit based HFSUniStr255 (used for file names in Mac OS X) would occupy 1022 bytes, even though most file names consist of less than 40-50 characters in the BMP.
c'est pour mes malloc en C...
une var d'environnement ca peut-être n fois plus long encore, je suppose ???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc... -- une bévue
pere.noel
Benoit Leraillez wrote:
Le nom de fichier c'est 256 de mémoire, pour le chemin complet ou full path je ne connaissait pas de limite, y-en-a-t-il-une-?
ah bon, le pb est qu'est-ce qu'on appelle "nom de fichier" ...
si c'est juste le basename, comme tu l'entends, alors si ça correspond à ce que dit Apple dans la TN2078 pour "file name" alors c'est ça :
For example, a 32-bit based HFSUniStr255 (used for file names in Mac OS X) would occupy 1022 bytes, even though most file names consist of less than 40-50 characters in the BMP.
BMPºsic Multilingual Plane
donc, si file name est bien ce que nous pensons alors un full path...
ça peut-être au moins 10 fois ça non ? -- une bévue
Le nom de fichier c'est 256 de mémoire, pour le chemin complet ou
full path je ne connaissait pas de limite, y-en-a-t-il-une-?
ah bon, le pb est qu'est-ce qu'on appelle "nom de fichier" ...
si c'est juste le basename, comme tu l'entends, alors si ça correspond à
ce que dit Apple dans la TN2078 pour "file name" alors c'est ça :
For example, a 32-bit based HFSUniStr255 (used for file names in
Mac OS X) would occupy 1022 bytes, even though most file names
consist of less than 40-50 characters in the BMP.
BMPºsic Multilingual Plane
donc, si file name est bien ce que nous pensons alors un full path...
ça peut-être au moins 10 fois ça non ?
--
une bévue
Le nom de fichier c'est 256 de mémoire, pour le chemin complet ou full path je ne connaissait pas de limite, y-en-a-t-il-une-?
ah bon, le pb est qu'est-ce qu'on appelle "nom de fichier" ...
si c'est juste le basename, comme tu l'entends, alors si ça correspond à ce que dit Apple dans la TN2078 pour "file name" alors c'est ça :
For example, a 32-bit based HFSUniStr255 (used for file names in Mac OS X) would occupy 1022 bytes, even though most file names consist of less than 40-50 characters in the BMP.
BMPºsic Multilingual Plane
donc, si file name est bien ce que nous pensons alors un full path...
ça peut-être au moins 10 fois ça non ? -- une bévue
pere.noel
Eric Levenez wrote:
La valeur du PATH complet d'un fichier donné dépend du système de fichier (HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Bref, il y a de tout.
ol merci beaucoup, ça éclaire ma lanterne je ne gère que des fichiers HFS+
c'est curieux cette limite du path, courte amha, car 256 caractères (en UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets... -- une bévue
Eric Levenez <news@levenez.com> wrote:
La valeur du PATH complet d'un fichier donné dépend du système de fichier
(HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il
va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long.
La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS
c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256
octets.
Bref, il y a de tout.
ol merci beaucoup, ça éclaire ma lanterne je ne gère que des fichiers
HFS+
c'est curieux cette limite du path, courte amha, car 256 caractères (en
UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets...
--
une bévue
La valeur du PATH complet d'un fichier donné dépend du système de fichier (HFS, NFS, SMB...), du programme qui va utiliser ce chemin et des API qu'il va utiliser...
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Bref, il y a de tout.
ol merci beaucoup, ça éclaire ma lanterne je ne gère que des fichiers HFS+
c'est curieux cette limite du path, courte amha, car 256 caractères (en UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets... -- une bévue
blanc
Une bévue wrote:
c'est pour mes malloc en C...
une var d'environnement ca peut-être n fois plus long encore, je suppose ???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc... -
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as pas besoin de modifier ; Soit tu utilises strlen sur la même variable pour en connaître la longueur, et tu fais un alloc en conséquence. Y a pas besoin de réalloc, amha.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Une bévue <pere.noel@laponie.com.invalid> wrote:
c'est pour mes malloc en C...
une var d'environnement ca peut-être n fois plus long encore, je suppose
???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour
les noms de fichiers (basename en shell), il va sans doute falloir
passer par realloc...
-
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as
pas besoin de modifier ;
Soit tu utilises strlen sur la même variable pour en connaître la
longueur, et tu fais un alloc en conséquence.
Y a pas besoin de réalloc, amha.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
une var d'environnement ca peut-être n fois plus long encore, je suppose ???
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc... -
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as pas besoin de modifier ; Soit tu utilises strlen sur la même variable pour en connaître la longueur, et tu fais un alloc en conséquence. Y a pas besoin de réalloc, amha.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
filh
Une bévue wrote:
patpro ~ patrick proniewski wrote:
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc...
Well... en unix posix on a des macros genre _POSIX_MAX_PATH_LEN_ (à vérifier dans la norme).
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Une bévue <pere.noel@laponie.com.invalid> wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour
les noms de fichiers (basename en shell), il va sans doute falloir
passer par realloc...
Well... en unix posix on a des macros genre _POSIX_MAX_PATH_LEN_ (à
vérifier dans la norme).
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de
sécurités, défauts de portabilité, plantages : l'allocation statique.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
pour l'instant j'ai alloué 512 octets pour un abolute path et 128 pour les noms de fichiers (basename en shell), il va sans doute falloir passer par realloc...
Well... en unix posix on a des macros genre _POSIX_MAX_PATH_LEN_ (à vérifier dans la norme).
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pere.noel
JPaul wrote:
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as pas besoin de modifier ; Soit tu utilises strlen sur la même variable pour en connaître la longueur, et tu fais un alloc en conséquence. Y a pas besoin de réalloc, amha.
si, mais je n'avais pas donné l'info idoine, car dans certains cas (l'utilisateur a entré non pas le path d'un fichier mais le path vers l'alias d'un fichier) je dois résoudre l'alias et là le path est différent... -- une bévue
JPaul <blanc@empty.org> wrote:
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as
pas besoin de modifier ;
Soit tu utilises strlen sur la même variable pour en connaître la
longueur, et tu fais un alloc en conséquence.
Y a pas besoin de réalloc, amha.
si, mais je n'avais pas donné l'info idoine, car dans certains cas
(l'utilisateur a entré non pas le path d'un fichier mais le path vers
l'alias d'un fichier) je dois résoudre l'alias et là le path est
différent...
--
une bévue
Soit tu utilises directement un pointeur sur la var d'env, si tu n'as pas besoin de modifier ; Soit tu utilises strlen sur la même variable pour en connaître la longueur, et tu fais un alloc en conséquence. Y a pas besoin de réalloc, amha.
si, mais je n'avais pas donné l'info idoine, car dans certains cas (l'utilisateur a entré non pas le path d'un fichier mais le path vers l'alias d'un fichier) je dois résoudre l'alias et là le path est différent... -- une bévue
pere.noel
Benoit Leraillez wrote:
512 cela peut être light en effet et 128 ça l'ai sûrement. Mais bon quand bévue, bé plus soif ;-)
si je suis ce que dit Apple il faudrait mettre 1024 pour un file name et n X 1024 pour un full path mais je n'ai pas trouvé d'info sur la longueur d'un full path (mis à part ce que dit Éric dans ce thread : 1024 aussi pour un full path) ce qui me paraît bien court !!!
512 cela peut être light en effet et 128 ça l'ai sûrement. Mais bon
quand bévue, bé plus soif ;-)
si je suis ce que dit Apple il faudrait mettre 1024 pour un file name et
n X 1024 pour un full path mais je n'ai pas trouvé d'info sur la
longueur d'un full path (mis à part ce que dit Éric dans ce thread :
1024 aussi pour un full path) ce qui me paraît bien court !!!
512 cela peut être light en effet et 128 ça l'ai sûrement. Mais bon quand bévue, bé plus soif ;-)
si je suis ce que dit Apple il faudrait mettre 1024 pour un file name et n X 1024 pour un full path mais je n'ai pas trouvé d'info sur la longueur d'un full path (mis à part ce que dit Éric dans ce thread : 1024 aussi pour un full path) ce qui me paraît bien court !!!
-- Les gens sans humour manquent de sérieux.
-- une bévue
pere.noel
FiLH wrote:
Well... en unix posix on a des macros genre _POSIX_MAX_PATH_LEN_ (à vérifier dans la norme).
ok, bonne info, merci !
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
ouais surtout que je suis un complet débutant en C ... j'ai remarqué que certains lèvent une erreur quand l'alloc n'est pas OK.
les plantages : je viens de déplacer 20 lignes dans un prog et j'ai droit à un "Bus error" ))) -- une bévue
FiLH <filh@filh.orgie> wrote:
Well... en unix posix on a des macros genre _POSIX_MAX_PATH_LEN_ (à
vérifier dans la norme).
ok, bonne info, merci !
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de
sécurités, défauts de portabilité, plantages : l'allocation statique.
ouais surtout que je suis un complet débutant en C ...
j'ai remarqué que certains lèvent une erreur quand l'alloc n'est pas OK.
les plantages : je viens de déplacer 20 lignes dans un prog et j'ai
droit à un "Bus error" )))
--
une bévue
