<<< DISK$DATA:[NOTES$LIBRARY]VAX_VMS.NOTE;1 >>> -< SIG VAX/VMS >- ================================================================================ Note 1297.0 get AP 31 replies DECUSF::QUIVOGNE_L 7 lines 17-APR-1991 14:41 -------------------------------------------------------------------------------- J'aimerais savoir s'il est possible et, le cas echeant comment, de recuperer l'adresse de l'AP dans un programme et, plus specifiquement le nombre d'arguments passes a une routine (l'equivalent de .NARG en MACRO quoi...) Cordialement - LQ ================================================================================ Note 1297.1 get AP 1 of 31 DECUSF::FOUCHET_F "François FOUCHET" 4 lines 17-APR-1991 15:57 -< Si ca existe pas, je veux bien l'ecrire >- -------------------------------------------------------------------------------- Ca doit bien exister dans une RTL quelconque. Ca peut se faire rapidement en macro, en creant une routine du genre GET_NUMBER_OF_ARGS, laquelle recupere la valeur de Saved AP dans le Call Frame, et retourne le nombre d'arguments. Si personne n'a ca, je veux bien l'ecrire. ================================================================================ Note 1297.2 get AP 2 of 31 DECUSF::QUIVOGNE_L 2 lines 17-APR-1991 16:05 -< ... >- -------------------------------------------------------------------------------- Yep !! (et merci...) mais j'aimerais savoir si quelqu'un connait la RTL en question que je n'ai pas trouvee... ================================================================================ Note 1297.3 get AP 3 of 31 DECUSF::SMANS_M "Michel Smans, C.I.R.C., Lyon" 22 lines 17-APR-1991 16:36 -< merci Jean-yves! >- -------------------------------------------------------------------------------- voici un "brico" que JY Collot m'a "pondu" il y a quelques annees (ca marche toujours!) $ create narg.mar $SFDEF .ENTRY NARG,0 MOVZBL @SF$L_SAVE_AP(FP),R0 RET .END ^Z $ mac narg et au link prendre narg.obj appel en fortran par ex: subroutine toto(a,b,c,d) nargum=narg() if ( nargum.lt.4 ) ... enjoy ! ( et merci encore a Jean-Yves) ================================================================================ Note 1297.4 get AP 4 of 31 DECUSF::FOUCHET_F "François FOUCHET" 2 lines 17-APR-1991 16:52 -< Too late >- -------------------------------------------------------------------------------- J'arrive trop tard !!! J'ai pose a peu pres la meme chose dans VMS:GET_NUMBER_OF_ARGS.MAR ... ================================================================================ Note 1297.5 get AP 5 of 31 DECUSF::QUIVOGNE_L 3 lines 17-APR-1991 17:25 -< mersibocouhatoudeu >- -------------------------------------------------------------------------------- Merci a tout deux (je regarde les deux programmes pour que personne ne pense avoir perdu son temps!!). Et, y'aurait une magouille avec une RTL ? (juste par curiosité) ================================================================================ Note 1297.6 get AP 6 of 31 DECUSF::FOUCHET_F "François FOUCHET" 4 lines 17-APR-1991 20:37 -< Voir BASIC par exemple >- -------------------------------------------------------------------------------- Je pense que les langages qui verifient le nombre d'arguments passe a l'appel d'une routine/fonction (BASIC par exemple) doivent implementer ca. Vu la complexite du code, le mieux c'est peut etre de se le coller dans une librairie personnelle. ================================================================================ Note 1297.7 get AP 7 of 31 DECUSF::QUIVOGNE_L 2 lines 18-APR-1991 09:23 -< OUETAP >- -------------------------------------------------------------------------------- Mais, en fin de compte, l'AP (et les registres en general), c'est stocké ou ? ================================================================================ Note 1297.8 get AP 8 of 31 DECUSF::JOUVIN_M "Michel Jouvin - CECM/CNRS Vitry" 1 line 18-APR-1991 10:28 -< Dans les registres... >- -------------------------------------------------------------------------------- ================================================================================ Note 1297.9 get AP 9 of 31 DECUSF::FOUCHET_F "François FOUCHET" 33 lines 18-APR-1991 11:08 -< Page culturelle >- -------------------------------------------------------------------------------- Effectivement, AP (Argument pointer) est UN des registres machine du VAX. Les 15 autres sont R0 a R11, FP (Frame Pointer), SP (Stack Pointer) et PC (Program Counter). Il existe un autre registre, partiellement modifiable, qui est PSW (Processor Status Word), qui est compose des 16 premiers bits de PSL (Processor Status Longword). Pour info, AP pointe sur une structure decrivant les arguments passes a une routine. Le premier mot (celui pointe par AP) contiend le nombre d'arguments passes (seul le premier byte est utilise). Les autres mots contiennent soit : - une valeur pour les arguments passes "by value". - soit l'adresse de l'argument pour les arguments passes "by reference". - soit l'adresse du descripteur de l'argument pour ceux passes "by descriptor". FP pointe une structure cree par chaque instruction CALLS ou CALLG. Il contiend la sauvegarde de certains registres (AP,FP,PC), plus ceux specifies dans le masque de registres a sauvegarder lors de l'appel d'une routine (specifie dans le .ENTRY de la routine). Le mot pointe par FP est l'adresse de la procedure chargee de gerer les erreurs detectees pendant son execution (condition handler). SP pointe sur la pile courament utilisee. PC pointe sur la prochaine instruction a executer. PSW contiend les bits Z,V,N,C habituels, plus des flags. L'ensemble de ces registres est accessible en MACRO (ou en BLISS). Ils sont modifiables sans privileges. Il existe par contre d'autres registres, appelles registres priviligies, qui ne sont accessibles qu'en mode KERNEL, et dont le nombre et l'utilisation depend du CPU utilise. VAX Hardware Reference Manual explique tout ca tres bien ... ================================================================================ Note 1297.10 get AP 10 of 31 DECUSF::BERENGUIER_A "Alain, ALCATEL BUSINESS SYST" 104 lines 18-APR-1991 13:33 -< Un runtime Nargs >- -------------------------------------------------------------------------------- Comme il est dit dans une des reponse precedentes, tous les languages implementer sous VMS qui offrent une possibilite de passer un nombre variable de parametres, offre le moyen dans la routine appelee de tester le nombre de parametre recu. Si le language ne le permet pas ( Send a SIR ). J'avais ecrit une routine assembleur qui me permettait cela du temps ou le pascal VAX n'avait pas cette possibilite. - C'est un avantage enorme, lorsque vous upgrader une runtime utilisee dans plusieurs programmes, ( que vous ne voulez pas recompiler, ni reecrire ). - Obtenir le nombre d'arguments n'est quand meme pas aussi simple que cela, il faut quand meme voir ce qu'effectue en code genere l'appel a votre routine. - Voici ci-dessous le module assembleur que j'avais ecrit à l'epoque. ----------------------------------------------------------------------------------- .TITLE NARGS Return number of arguments .IDENT /UT-1.0-0/ ;*******************************************!*************************** ; LANG: MACRO-32.. VERSION : 1.0-0 29/01/86 ; BUT: Return number of arguments ;----------------------------------------------------------------------- ; NAM: NARGS CMP: VAX....... PGM: All ; SYS: VMS-3.7 - ( Tout compil dont VAX-11 Pascal V2.5-307 ) ;---------- ; ENT: Explicite : Neant ; Implicite : Le frame-pointeur et le registre Ap de la routine ; appelante ; dont on deduit : le nombre de parametres ; quemandes a l'appellant. ;---------- ; RTN: En fonction ( R0 ) le nombre de parametres recus par la ; fonction appellante ( nombre d'arguments ). ; ; Implicite : Neant. ;---------- ; FNC: ; This routine returns the number of arguments given to its caller. ; This routine is called by a procedure having optional arguments ; and needing to know how many arguments it is passed. ; ; Calling sequence: ; ; Number_of_arguments := NARGS ; ; ;---------- ; Side effects: ; Neant si la procedure appelante a la forme : ; ; Function Compress ( ; Var Line : Varying [ Len ] of Char ; Var ..... (* et seulement des vars *) ; ) : A_Type ; Extern ; ; ; ; sinon imprevisible ( structure de stack ) ::=> ; ; Soit PRG le programme ( ou la routine ) appellant RTM, la routine ; avec des arguments optionnels ( celle qui appelle NARGS ). ; Si PRG appelle RTM par un Call_S, le resultat est ok, sinon ; ( appel via un Call_G ) le resultat depend de la preservation ; du registre AP par RTM avant le call a NARGS. ; Remarquez que le compilateur Pascal Vax V2.. utilise le registre ; AP pour recopier dans le stack les parametres passer par "value" ; et ceci avant toute instruction Pascal. Pour eviter cette ; utilisation on doit passer tous les parametres en Var. ; L'Utilisateur de la presente Runtime ( NARGS ), compilera le ; module RTM avec l'option Machine_Code pour se confirmer la ; non utilisation de AP. ( En pascal Vax V3, il semble que l'on ; puisse se passer de cette runtime avec l'attribut Truncate et ; la fonction Present ). ; ;---------- ; REV: .......... ;---------- ; CAL: Neant ;---------- ; VER DATE OBJ AUT ; . . . . . . . . . . . . ; 1.0-0 29/01/86 Creation Berenguier Alain ;*********************************************************************** ;-- ; .PSECT $CODE, PIC,REL,SHR,EXE,RD,NOWRT,2 ; Old_Fp = 4 * 3 ; Cond_Hand, Mask+Psw , Old_Ap Old_Ap = 4 * 2 Nar_Off = 4 * 5 ; -ditto- + Fp, Pc ; .ENTRY NARGS,^M<> Movl L^Old_Fp(FP) ,R0 ; La precedente trame Bbs #29 ,4(R0) ,1$ ; Call_G ou Call_S Movl L^Old_Ap(FP) ,R0 ; Call_G => Nbr_arg vue par le Movzbl (R0) ,R0 ; precedent AP , si non detruit ! RET ; 1$: Movzbl L^Nar_Off(R0) ,R0 ; Call_S => Nbr_Arg / Stack. RET ; .END -------------------------------------------------------------------------------- ================================================================================ Note 1297.11 get AP 11 of 31 DECUSF::FOUCHET_F "François FOUCHET" 7 lines 18-APR-1991 14:29 -< CA NE MARCHE PAS VRAIMENT >- -------------------------------------------------------------------------------- A .10 : J'ai pas bien compris pourquoi vous faites le distingo CALLS/CALLG, etant donne que, dans les 2 cas, AP pointe toujours sur l'argument list. D'autre part, votre 4*5 pour Nar_Off ne vous fait surement pas tomber la ou il faut, mais en plein sur la sauvegarde du premier registre a sauver, dont la valeur depend de la routine appellee. Enfin, il n'y a pas de risque que AP soit detruit dans le Call Frame, meme par CALLG. ================================================================================ Note 1297.12 get AP 12 of 31 DECUSF::QUIVOGNE_L 8 lines 18-APR-1991 16:35 -< re-question >- -------------------------------------------------------------------------------- Dans la serie j'insiste... Si j'ai bien compris, vos programmes MACRO vont chercher via FP le saved-AP. Mais, l'AP lui-meme (et tous les registres en general), ils doivent bien etre stocke dans P1 (me trompe-je) et y'a bien un offset qui donne leur position. Non ? (sans vouloir etre lourd...) merci d'avance - LQ ================================================================================ Note 1297.13 get AP 13 of 31 DECUSF::WERZ_P "Pascal WERZ, MagneTech, Orsay." 16 lines 18-APR-1991 16:47 -------------------------------------------------------------------------------- > saved-AP. Mais, l'AP lui-meme (et tous les registres en general), ils > doivent bien etre stocke dans P1 (me trompe-je) et y'a bien un offset Que nenni! ce sont les registres des processeurs VAX! A ce titre, il n'ont pas d'adresse car ils sont physiquement dans le cpu, pas dans la mémoire. Il représente une partie du contexte de votre process. Il sont inaccessibles directement par la plupart des langages évolués. Et attention: le nombre d'argument pointé par AP est le nombre de longword (4 bytes) passés en arguments. Dans le cas d'un passage par valeur d'un argument D_FLOAT ou G_FLOAT, celui-ci compte pour 2, pour un H_FLOAT il compte pour 4, etc... Passer des D_FLOAT arrive facilement en C! Ce n'est donc pas tout à fait le nombre d'argument, donc. Dans le cas de passage par référence, une addresse compte pour un LongWord (ce qu'elle est d'ailleurs). pw ================================================================================ Note 1297.14 get AP 14 of 31 DECUSF::QUIVOGNE_L 6 lines 18-APR-1991 17:14 -< ... >- -------------------------------------------------------------------------------- AAAAAAH bon ! Ceci signifierait-il que le contexte des process est physiquement dans la CPU (J'ai l'impression d'avoir mal compris...) ? (Si cette question naive vous semble impliquer qu'il y a vraiment tout a expliquer, laissez tomber !!!!!!!) ================================================================================ Note 1297.15 get AP 15 of 31 DECUSF::QUIVOGNE_L 9 lines 18-APR-1991 17:46 -< -->PCB-->Hard PCB-->AP >- -------------------------------------------------------------------------------- TOUJOURS LE MEME... je viens de lire qu'a l'adresse CTL$GL_PCB, on lisait l'adresse du PCB qui pointait lui meme sur le hardware PCB qui contient R0,R1,...AP, etc... Qu'est-ce donc qu'il faut comprendre parce que meme avec ca, je ne retrouve pas mes petits (arguments...). ================================================================================ Note 1297.16 get AP 16 of 31 DECUSF::BACH_J "Jean-Pierre BACH - Telecoms Paris" 27 lines 18-APR-1991 17:51 -< Gaffe aux optimisations des compilos >- -------------------------------------------------------------------------------- A .14: Le contexte DU process ACTIF (celui qui est en train d'executer votre routine NARG), je crois bien qu'il y en a une partie dans la CPU... A commencer par le PC qui pointe l'instruction courante, et quelques autres registres non privilégiés (R0 à R14) et privilégiés. Pas confondre le process actif (un par CPU, max) et les process "bloqués". Remarque générale: Je conseille à tous d'utiliser les formes proposées par les langages DEC (même si ces formes sont pas normalisées et pas transportables). Au moins si ça ne marche pas, vous pourrez faire des SPRs. Les bricos qui permettent de récupérer AP fonctionnent généralement bien. GERARD_G m'en avait fait un il y a des années lorsque j'avais transporté des trucs innommables en Fortran et qui eux-mêmes contenaient un brico révu pour une autre bécane et intransportable... Ca doit fonctionner dans 98% des cas. Pour les 2% se méfier de ce que le compilateur peut avoir envie de générer entre la ligne de déclaration de votre sous-programme et la première instruction exécutable (votre appel à NARGS). Je crois me souvenir d'une vieille version de VAX C qui traitait la clause "register" à peu près ainsi (j'ai jamais su pourquoi d'ailleurs): MOVE AP ds un autre registre MOVE l'argument déclaré "register" dans AP (!!) Utiliser AP comme registre de travail et récupérer les autres arguments grâce à l'autre registre (!!) ==> pour utiliser un brico comme NARGS, un rapide coup d'oeil au MACHINE_CODE peut être bien utile. Et gaffe aux changements de release des compilos. ================================================================================ Note 1297.17 get AP 17 of 31 DECUSF::JOLIN_R "Rémi JOLIN - T.A.T." 6 lines 18-APR-1991 18:19 -< Ca existe en direct en Pascal. >- -------------------------------------------------------------------------------- Avec vax pascal, si vous avez defini une procedure dont les arguments ont l'attribut [truncate], vous pouvez tester la presence d'un argument par present(argument). Il faut que l'argument en question soit defini truncate, sinon, ca rend toujours vrai.. ================================================================================ Note 1297.18 get AP 18 of 31 DECUSF::QUIVOGNE_L 2 lines 18-APR-1991 18:23 -< c...l >- -------------------------------------------------------------------------------- J'ose plus dire en quoi je suis vu que je vais m'attirer les sarcasmes les plus divers....Merci mais je suis pas en PASCAL (dommage...) ================================================================================ Note 1297.19 get AP 19 of 31 DECUSF::ROUGEVIN_P "Pierre R.B. Banque du Phenix" 32 lines 18-APR-1991 19:48 -< qques precisions >- -------------------------------------------------------------------------------- > je viens de lire qu'a l'adresse CTL$GL_PCB, on lisait l'adresse du PCB > qui pointait lui meme sur le hardware PCB qui contient R0,R1,...AP, > etc... > > Qu'est-ce donc qu'il faut comprendre parce que meme avec ca, je ne > retrouve pas mes petits (arguments...). Ce que vous avez lu (dans IDS, je presume?) est parfaitement correct et les reponses precedentes (les R0,R1,... sont des REGISTRES internes au processeurs et n'ont donc evidemment pas d'adresse) sont correctes elles aussi ... L'explication de ce paradoxe apparent est simple : il ne faut pas oublier que le VMS est un systeme multitache... Lorsque le scheduler interrompt une tache, pour que celle ci puisse repartir plus tard proprement il faudra lui retablir le contexte qu'elle avait au moment ou elle a ete interrompue. Il faut donc sauvegarder sers registres generaux (R0 a R13), son PC et son PSL, ses 4 stack pointer (un par mode...) et ses 'memorymanagement registers'(P0BR,P0LR,P1BR,P1LR) Ou sauvegarder tout cela ? Mais dans le hardware PCB justement ! Ainsi les R0,R1,etc qu'il y a dans VOTRE hardware PCB sont les valeurs qu'avaient vos registre au moment ou votre process a repris la CPU. Les valeurs COURANTES de ces registres sonts dans les registres (dans la CPU) et pas ailleurs ! Si ca vous interesse, sachez que ces operations de sauvetage/restitution entre les registres et le hardware PCB sont faites d'un seul coup par les instructions (privilegies, accessibles seulement en mode Kernel) LDPCTX (LoaD Process ConTeXt) et SVPCTX (SaVe Process ConTeXt). A noter d'ailleurs que cette derniere (SVPCTX) omet de sauver les memory management register car on considere qu'ils ne varient 'pas souvent' pour un process donne... Ceci repond il a vos questions ? ================================================================================ Note 1297.20 get AP 20 of 31 DECUSF::QUIVOGNE_L 1 line 19-APR-1991 10:23 -< ...OUI... >- -------------------------------------------------------------------------------- Oui, tout-a-fait, merci beaucoup... ================================================================================ Note 1297.21 get AP 21 of 31 DECUSF::LELEGARD_T "Thierry Lelegard, Digital CSC" 20 lines 22-APR-1991 15:50 -------------------------------------------------------------------------------- Comme le precisait une des reponses precedentes, le registre AP est souvent utilise comme registre temporaire par les compilateurs dès qu'il savent qu'AP ne sera plus utile en tant que pointeur d'arguments pour tout le reste de la routine. Personnellement, en C, j'utilise souvent une bidouille du genre: num_args = *((int*)&first_arg - 1); ou first_arg est le premier argument declare de la procedure. En clair, on prend l'adresse du premier parametre est on va lire 4 octets en arriere. Attention, prendre l'adresse d'un parametre formel ne pointe pas forcement dans l'argument-list suivant les langages (exemple: Ada). Horrible mais efficace... -Thierry Lelegard ================================================================================ Note 1297.22 get AP 22 of 31 DECUSF::FAUCONNET_A "Alain, SIG Graph & messagerie" 6 lines 22-APR-1991 16:51 -< VARARGS en C >- -------------------------------------------------------------------------------- (Salut Thierry) Il y a en C quelque chose d'assez standard qui s'appelle varargs pour faire ce genre de choses. Ca existe dans tous les compilateurs dignes de ce nom (meme celui de Sun [le "gratuit", je ne connais pas l'autre], c'est dire). Voir la doc VAX C RTL pp REF-348 et suivantes. Je peux poster un bout de code d'exemple si cela interesse quelqu'un. ================================================================================ Note 1297.23 get AP 23 of 31 DECUSF::MARCHAL_J "Jean-Francois MARCHAL - APCOR/COM" 5 lines 22-APR-1991 17:04 -< question supplementaire >- -------------------------------------------------------------------------------- Dans le meme ordre d'idee, existerait-il un brico appelable en Fortran qui permette de savoir si un argument a ete omis a l'appel (donc d'adresse nulle, ce qui a des effets facheux a l'execution quand on le manipule) ================================================================================ Note 1297.24 get AP 24 of 31 DECUSF::SMANS_M "Michel Smans, C.I.R.C., Lyon" 1 line 22-APR-1991 17:45 -< c'est pas un brico, %LOC le fait! >- -------------------------------------------------------------------------------- ================================================================================ Note 1297.25 get AP 25 of 31 DECUSF::LELEGARD_T "Thierry Lelegard, Digital CSC" 46 lines 24-APR-1991 09:45 -< varargs.h n'est pas standard >- -------------------------------------------------------------------------------- Re .-2 : Salut Alain varargs.h n'est pas standard, c'est stdarg.h qui est standard. Seul varargs.h contient va_count() pour la bonne et simple raison que la plupart des implementations de C sont incapables de fournir le nombre d'arguments reellement passes a une fonction. Le "VAX Calling Standard" fait figurer explicitement le nombre d'arguments en tete de l'argument-list. Par contre, les implementations sur 680x0, par exemple, ne contiennent pas en general l'informnation. L'appelant empile les parametres et l'appelé les dépile, a charge pour lui de savoir combien il y en a. Si la fonction admet explicitement un nombre d'arguments variable (commme printf), il faut se baser sur le contexte pour savoir combien il y en a (par exemple en fonction du nombre de '%' dans le format du printf). Comme c'est stdarg.h qui est standard, c'est lui qui est inclus par les autres headers standards comme stdio.h. Et comme stdarg.h et varargs.h definissent des macros communes du style va_arg, chacun des deux headers commence par "un-definir" consciencieusement les definitions de l'autre. Ainsi, si on fait : #include #include le deuxieme include fait un: #include qui supprime les definitions de varargs.h et entre autres va_count. Il faut donc toujours faire : #include #include Comme je trouve les programmes qui se comportent differement en fonction de l'ordre des includes trop bancals et que de toute maniere l'utilisation de varargs.h (et non stdarg.h) est non portable, je prefere aller carrement piocher dans l'argument-list (en plus, ca evite un call a vaxc$va_count). -Thierry ================================================================================ Note 1297.26 get AP 26 of 31 DECUSF::FAUCONNET_A "Alain, SIG Graph & messagerie" 3 lines 24-APR-1991 11:23 -< va_count est une extension - oups >- -------------------------------------------------------------------------------- Exact. En reprenant mes sources j'ai vu que je n'utilisais que va_start, va_arg et va_end dans le programme que j'ai compile sur tout et n'importe quoi ================================================================================ Note 1297.27 get AP 27 of 31 DECUSF::COLLOT_JY 35 lines 25-APR-1991 12:35 -< %loc en fortran ? Oui, mais... >- -------------------------------------------------------------------------------- Au risque de contredire mon camarade Michel SMANS, je ne suis pas trop d'accord à propos de l'utilisation de %LOC pour savoir, en FORTRAN, si un argument a été omis ou non. Du moins, pas dans tous les cas. Exemples : 1. CALL SUB (A,,B) Subroutine Sub(X,Y,Z) Integer X,Y,Z If (%loc(Y).eq.0) Then ... Là, c'est ok, ça marche, car "omis" signifie ici qu'on a quand même le bon nombre d'arguments, avec rien (c'est-à-dire 0) dans certains. Cependant, si ma subroutine était : Subroutine Sub(X,Y,Z) Character*(*) X,Y,Z ça planterait avec un magnifique ACCESS VIOLATION avant même d'avoir exécuté la première ligne de la subroutine. Je ne connais personnellement pas de solution, dans ce cas, d'ailleurs... 2. Call SUB (A,B) Subroutine Sub (X,Y,Z) If (%loc(Z).eq.0) Then ... Ici, l'utilisation de %loc est insuffisante, car, en fait, %loc va aller voir dans la pile d'argument ce qu'il y a dans le quatrième longword de la structure pointée par AP. Et, comme cette structure ne fait que 3 longwords, rien ne prouve que l'on ait 0 dans le quatrième. C'est même improbable. Donc, dans ce cas, il faut utiliser une routine comme la mienne ou celle de F.FOUCHET, ou n'importe quelle autre équivalente. ================================================================================ Note 1297.28 get AP 28 of 31 DECUSF::LESUEUR_E "Emmanuel le SUEUR - SOGIDEC/YLYS " 5 lines 25-APR-1991 15:08 -< Use a descriptor >- -------------------------------------------------------------------------------- Dans le cas d'un argument de type "Passed-length string descriptor" (character *(*)) je pense que la seule solution ... est de déclarer cet argument explicitement comme un descripteur (integer x (2) par exemple). ================================================================================ Note 1297.29 get AP 29 of 31 DECUSF::FOUCHET_F "François FOUCHET" 8 lines 7-MAY-1991 17:57 -< Enjoy >- -------------------------------------------------------------------------------- > Dans le meme ordre d'idee, existerait-il un brico appelable en Fortran > qui permette de savoir si un argument a ete omis a l'appel (donc > d'adresse nulle, ce qui a des effets facheux a l'execution quand on le > manipule) Ca existe maintenant dans VMS: sous le doux nom de IS_ARG_DEFINED.MAR C'est une fonction qui retourne SS$_WASSET (9) si l'argument est defini, SS$_WASCLR (1) sinon. ================================================================================ Note 1297.30 get AP 30 of 31 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 1 line 8-MAY-1991 13:11 -< not a jolly goude aidieu >- -------------------------------------------------------------------------------- c'est pas drole: les 2 status sont des status de succes. ================================================================================ Note 1297.31 get AP 31 of 31 DECUSF::FOUCHET_F "François FOUCHET" 1 line 13-MAY-1991 12:08 -< On peut toujours modifier ... >- --------------------------------------------------------------------------------