Dear group, Consider this situation: a program can run either interactive or automatic: In interactive mode, you can fix errors and try again. So if something fails, an optional stat argument passes the error up the call procedure(s), user gets notified, fights his frustration and tries again. In automatic mode, as there is trouble, we print a confusing message and quit. This codes as: if(interactive) then call do_some_work(stat) else call do_some_work() endif Not so nice- the same situation occurs in do_some_work and lotsa places. Now, do_some_work cannot access interactive, as this causes circular module dependencies. Besides, i find it quite nice and consistent that my routines behave as allocate et al. So I remembered that my NAG f95 seems to pass optional arguments as null pointers: program tst integer, pointer :: p integer, target :: q nullify(p) q=0 print *, "call tstsub()" ; call tstsub() print *, "call tstsub(q)" ; call tstsub(q) print *, "call tstsub(p)" ; call tstsub(p) p => q print *, "call tstsub(p=>q)" ; call tstsub(p) contains subroutine tstsub(arg) integer, intent(in), optional :: arg print *, "Arg present: ", present(arg) end subroutine tstsub end program tst and hey! - it worked: [klaus@platon klaus]$ a.out call tstsub() Arg present: F call tstsub(q) Arg present: T call tstsub(p) Arg present: F call tstsub(p=>q) Arg present: T [klaus@platon klaus]$ Great- I can associate or nullify stat at least once for each subroutine, or can I? I doubt it is very portable, my f90 texts say nothing about how optionals are to be implemented. Besides- maybe this is a compiler bug? What if I wanted this routine to know I passed a nullified pointer? OK- the dummy arg is not a pointer, so cannot be "NULL". (If I make arg a pointer, the actual arg must be a pointer to and gets detected as present even if nullified). Hm. Comments? Klaus -- [log in to unmask] - www.ramstock.de Am Krag 12g, 55286 Wörrstadt phone +49 6732 963434 - fax +49 6732 963435 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%