[J3] surprisingly PURE

Tue Apr 21 00:10:06 EDT 2020

Hi Vipul,

Thanks for the comments.

Unfortunately your simple constraint doesn’t work, as an intervening pointer assignment, structure constructor, *or call to another pure procedure* makes it ineffective. As worded, it does not even forbid Robert’s example, though that is fixable.

I remain of the opinion that, if reasonably possible, it is the thing that creates the “bad pointer” that should be forbidden. Once you allow bad pointers to be created, there are so many ways that the problematic usage can be obscured that it becomes very complicated to stop bad things from happening.

I will note that, although if it were still the year 2008, i.e. during the development and integration of the “data pointer initialisation” feature into the language, a big hammer might well have been very appropriate, it is less appropriate now. Now, we are in the business of fixing defects, and one guideline for fixing defects is that the smallest change that solves the problem should be chosen. This helps to avoid annoying people who already used the feature, possibly safely, but yet would be hit by a too-big hammer.

OTOH, it might well be that we really do need to use a “big hammer” to solve enough of the problem. I feel that this is quite likely, actually.

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Vipul Parekh via J3
Sent: Tuesday, April 21, 2020 10:19 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Vipul Parekh <parekhvs at gmail.com>
Subject: Re: [J3] surprisingly PURE

On Mon, Apr 20, 2020 at 1:35 AM Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> > wrote:

..

Perhaps the most obvious fix is to disallow a local variable in a PURE subprogram from having a data pointer component that is default-initialised to a target that is not a local variable of the subprogram. That might be too big a hammer ..

C1589a A nonallocatable nonpointer local variable of a pure subprogram, or of a BLOCK construct within a pure subprogram, shall not have a default-initialized ultimate component that is a data pointer component, if the data pointer component has an initial-data-target that is not a local variable of the subprogram.

I note there is possibly another example, using allocation. ..

One could prohibit this second example by changing “ultimate component” in C1589a to “component at any level of component selection”. However, that does looks like a hammer that is too big, and so since it is the allocation that is doing the bad thing, perhaps we should consider a constraint on the allocation instead. (Wordsmithing such a constraint left as an exercise to the reader.) ..

Hi Bob, Malcolm, and everyone,

Since the context is PURE procedures which is of rather high importance in modern programming, especially parallel computing, will not proceeding with the biggest hammer one can come up with be the better approach?

What would be the issue with something like the following as C1589a?  Note constraint C1594 already imposes quite a few heavy demands on processors, so I would like to think something like this will not be any further onerous on compilers than the standard as-is.  So it will be good to read the feedback from those working on processor implementations.

C1589a A local variable of a pure subprogram, or of a BLOCK construct within a pure subprogram, shall not be used in a variable-definition context (19.6.7) if the variable is a derived type where the type has a default-initialized ultimate component at any level of component selection that is a data pointer component and such a data pointer component has an initial-data-target that is not a local variable of the subprogram.

Regards,

Vipul Parekh

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our  <https://www.nag.co.uk/content/privacy-notice> Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200421/c065f189/attachment-0001.htm>