Alors si je fais :
 

Pas de pb. Mais si j'écris :

j'ai une erreur comme quoi le type est incompatible, je peux faire un cast mais bon, si je peux éviter et comprendre mon erreur ...

pointeur != tableau attention.
 
y a un topic sur ce genre d emanip un peu plus bas dans le forum.

vi, ça je sais bien, c'est vrai dans les 2 cas, mais je ne vois pas bien pourquoi l'erreur n'arrive que dans un seul cas. Vais essayer de trouver cet autre topic, merci.

En fait, le pointeur de pointeur de pointeur n'existe pas.
Concrètement, tu as droit à short *, short **, mais en aucun cas à short ***.
on utilise dans ce cas void * [N] qui te permet de rajouter les dimensions attendues.

 
n'importe quoi ....
short*** est parfaitement supporté

Retourne à tes standards ...
Il est peut-être supporté par certains compilateurs( dont tu me donneras les versions et OS), mais :  
1) ce n'est pas standard
2) dans ce cas, ce n'est absolument pas portable.

c'est quoi qui n'est pas (censé être) standard ?
plus de deux niveau de déréférencement ?
ou de coupler ça avec un short ?

Ben, oui, désolé, ce n'est pas standard (cc hp-ux, solaris, aix, ...).

Fortune !
 
et tu dis quoi quand tu vois
 

Je dis que le compilateur fait bien son travail et qu'il corrige les conneries que tu écris.
Cela n'a cependant strictement aucun rapport avec short ***.
Passe un coup de lint, et tu verras ...

mince si lint le dit ... faudrait voir à prévenir tout le monde alors

j'ai une question con, t'en fais quoi du short*** que tu récupères, vu que tu sais plus les dimensions ?

 
c'est pas une preuve de non-conformité...

non mais honnêtement, pourquoi selon toi ça serait pas standard ?

Disons que l'on tente, dans la mesure du possible d'écrire du code portable, propre, et aux normes implicites du C.
Maintenant, chacun est libre de faire ce qu'il veut avec son compilo.
Je dis juste que si ça marche avec le votre ou gcc, tant mieux.
Mais méfiez-vous, ce n'est absolument pas standard (comme les écritures à la C99).
Il me semble cependant qu'avant de ternir l'image du C, le mieux est de prendre de bonnes habitudes.
Quant à lint, oui, si lint le dit, ton code est pourri.

Selon moi, ce n'est pas standard pour les raisons suivantes :  
- les compilateurs "standard" constructeurs répondent à des certaines nomres dont je ne me souvient pas les noms et peuvent être pour cela casse-couille.
- je me suis déjà cassé les dents dessus. Sur de l'aix, ou du solaris et hors gcc, ça ne se compile pas.
C'est dommage, car bien pratique.
Il faut cependant bien que les compilateurs aient des limites.

c'est que ces compilos sont ptet à certains point de vue un peu bouseux alors... (et qu'ils partagent un source commun pour certaines parties)

 
mouef.

ça fait bizarre de voir un ~Taz mais qui se plante royalement ...

quant au morceau de code que j'ai filé, la comète, il est purement standard

Vous en faites ce que vous voulez.
Mais allez dire à même à SUN/HP/IBM (et à leurs clients) que leurs compilos partagent le même code bouseux et merdiques.
Quant à ton morceau de code, désolé, il n'est pas standard :  
- la casse majuscule/minuscule (GetBuffer) est typiquement une winauberie. Tous les noms de fonctions sont obligatoirement en minuscules, le caractère '_' peut être utilisé comme séparateur,
- si la fonction est locale, on rajoute "static" devant, sinon on la préfixe d'un code mnémotechnique sous peine de duplication de noms à l'édition de liens,
- pour retourner un pointeur, code ça en macros,
- je te donne la réponse à ton problème, et visiblement, tu ne comprends pas.

il parlait pas de ce code la  !

putain, t'es chiant de déblatérer autant, ça tiendra jamais dans une seule fortune
 
1) chacun est libre de choisir ses identifiants, du moment que c'est en accord avec la grammaire
2) on mets static si on veut. c'est là une habitude de bon design, pas une obligation
3) c'est crade et personne ne t'oblige à faire ça.
4) c'est toi qui comprends pas que short *** est tout à faire valide
 
 
si t'es si malin, trouve nous un référence poure appuyer ta clownerie

désolé je voulais pas être vexant.
 
Taz parlait de ce qu'il avait posté, pas du code de cricri_.
 
la question est de savoir si le standard du C interdit plus de deux niveau de déférencement à la déclaration d'un pointeur.
 
mais franchement, ça me semble plus être une restriction d'implémentation historique. (après tout le monde en a)

tiens je l'avais vu celle là
alors alors, c'est quoi la taille d'un void ?

tout simplement parce qu'il y a une instruction assembleur pour le double déréférencement, pas plus. limitation limitante, mais compréhensible

LOL et j'ai faillit louper ce fil ^^
 
@vivelec : tu debarque de 1975 ou quoi ??
Le standard à evoluer depusi tu sais et  
franchement c'est ni avec Taz ni avec moi qu'il
faut prendre ce ton hautain et trop sur de soi.

Essaye ca :
 

Attends, un forum, c'est avant tout fait pour partager son expérience et non pour donner des leçons.
Chacun est d'ailleurs libre de déblatérer à sa guise.
Je dis simplement que je n'ai jamais vu un short *** passé sur un compilo et ce n'est pas faute d'avoir essayé dans ma jeunesse.
Maintenant, si ça marche chez toi, très bien, je ne demande qu'à connaître ton compilateur et ton OS.
 
En résumé, intellectuellement parlant, un short *** voire plus est tout à fait compréhensible.
Simplement, à la compilation, ce n'est pas une écriture acceptée par tous les compilateurs, donc non portable.
C'est d'ailleurs visiblement, la cause du problème initial.
Quant aux normes, il y en a tellement (parfois contradictoires) qu'il est souvent difficile de s'y retrouver.
Le mieux est donc de se référer aux normes "implicites" et donc, au bon usage du C.

non, c'est portable, c'est du C ANSI minimum, du K&R certainement
 
après j'y peut quoi si t'as travailler avec des compilateurs mêmes pas foutu de compiler du C
 
y a pas de norme implicite : la norme ANSI c'est la plus répdandue, tu va pas commencer à nous faire le rabat joie parce que tu utilises les produits pourris de je sais pas quelle boîte. on y peut quoi nous si tu fais du C avec des compilateurs pas C

 
alors :
Linux Mandrake 9.2,9.1 et 10.0 avec gcc 3.3.1
Windows 2k avec mygwyn 3.3, visual studio 6 et 7
 

Non cf ma réponse
 

 
Non à la norme ANSI qui va bien voir à la norme C99

Encore une fois, faites ce que vous voulez, mais je vous déconseille simplement ce genre d'écriture.
Quant au ton hauntain et trop sûr de moi, si tu le dis, peut-être, mais je ne vois pas où et dans ce cas-là désolé.
Pour finir, le C a peu évolué depuis 75 ...

 
euh .... et le C99 c'est pour la Mére Denis peut etre ??

On ne va pas polémiquer, mais les "n'importe quelles boites" et "produits pourris" que j'ai cités, ont la part belle du monde unix : solaris (sun), hp-ux (hp) et aix (ibm).
Quant aux normes implicites du C, si elles existent.

ah bon ? ben tu ferais mieux te renseigner un peu alors. rien que les changements du C99 sont conséquents pour être étudier avec soin. Quant au C ANSI, rien que l'apparition d'une bibliothèque standard, c'est vrai que c'est peu.

La C99 n'est pas encore admise dans le mode industriel et je doute qu'elle le soit de sitôt.
A bon entendeur ... au cas où tu aurais un code à livrer pour un client.

 
et oui j'en ai   et ca leur plait bien en plus

ah bon, et le noyau Linux, c'est du bidon ?

Le C ANSI appartient principalement au monde unix.
Passe sous VMS et il n'est plus vraiment question de C ANSI.