On 08/30/2016 08:00 AM, Janne Blomqvist wrote: > On Mon, Aug 29, 2016 at 1:15 PM, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: >> Hi Janne, Andre, Jerry and All, >> >> I am perfectly happy to adopt Janne's suggestion for >> st_set_(dtio_)nml_var. Do the changes to the IO structures have any >> impact? These are in: >> >> fnode, st_parameter_dt & gfc_unit >> >> I don't think that these should be visible but I want expert opinion >> before making that assumption :-) > > fnode and gfc_unit are private to libgfortran, so these can be changed > in any way you see fit. > > st_parameter_dt, however, is more complex. It is allocated by the > frontend on the stack, with some empty space to be used as scratch > space by the library (the st_parameter_dt.u member). So you're free to > do whatever you want with the private part, as long as you keep the > size of the u.p struct smaller than u.pad (which should happen > automagically unless you have mangled check_st_parameter_dt somehow). > Otherwise I don't think you should go and touch st_parameter_dt. > > This design is somewhat unfortunate, in that it quite severely > restricts the recursion depth of any function potentially doing I/O. > Say, you have a recursive function that writes something if some > condition is met. Any function potentially doing I/O bumps up the > stack by almost 1kB.. I'm thinking a simpler design for handling the > large number of optional I/O specifiers could be something like having > 3 arguments, an array of keys, an array of values, and a scalar > telling how many elements the key/value arrays have. That way only the > specifiers that are actually specified would need to have space > allocated and be transferred. And then instead of a having the > frontend allocate a large scratch space on the stack, the library > could use a TLS variable to look it up. > > But anyway, talk is cheap, and I'm unlikely to have time to implement > the above any time soon... :( >
Yes, and others have talked about this. I am not ready to make the plunge there yet either. So, we have touched sr_parameter_dt carefully and not to exceed pad. I have been down this road many times. Jerry
