public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Vehreschild <vehre@gmx.de>
To: GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
	GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: [RFC, Fortran, (pr66775)] Allocatable function result
Date: Thu, 09 Jul 2015 10:25:00 -0000	[thread overview]
Message-ID: <20150709122518.08388506@vepi2> (raw)

Hi all,

I need your help on how to interpret the standard(s) or how to implement
handling an allocatable function's result, when that result is not allocated by
the function. Imagine the simple (albeit artificial) case:

integer function read_input()
  ! Do whatever is needed to read an int.
  read_input = ...
end function

integer function getNext()
  allocatable :: getNext
  if (more_input_available ()) getNext = read_input()
end function

where the function getNext () returns an (automatically) allocated result when
more_input_available() returns .true.. Otherwise getNext () returns an
unallocated object, i.e., the result's allocation status is .false.. I don't
want to argue about this design's quality (considering it poor myself). I
suppose that this code is legal, right?

Unfortunately gfortran can not handle it currently. The issue here is shown in
the pseudo code of:

integer, allocatable :: res
res = getNext ()

The pseudo code does this:

 	integer(kind=4) * D.3425;

        if (res != 0B) goto L.6;
        res = (integer(kind=4) *) __builtin_malloc (4);
        L.6:;
        D.3425 = getnext ();
        *res = *D.3425; // Oooops! D.3425 is NULL, when more_input_available ()
		        // is .false.

That is there is a classic null-pointer dereference.

I am curious why the memory allocated (or not) by the function is not reused for
the allocatable object on the lhs? I propose to generally handle an assignment
of a scalar allocatable(!) function result to a scalar allocatable(!) variable
like this (shortened a bit for brevity):

 	TYPE * res, D.3415, D.3417;

        D.3415 = get_next ();
        // Swap new result and old contents of res.
        D.3417 = D.3415;
        D.3415 = res;
        res = D.3417;
        // Deallocate old content of res to prevent memory leaks.
        if (D.3415 != 0B)  __builtin_free (D.3415);

Note there is no initial malloc of res! Would this do any harm, besides
preventing memory loss, saving an allocation and be cleaner to read on the
pseudo code side. Does it violate the standard somehow? Any ideas on
alternatives to prevent the null-pointer dereference in the initial code?

Suggestions, issues, objections???

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

             reply	other threads:[~2015-07-09 10:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 10:25 Andre Vehreschild [this message]
2015-07-09 17:50 ` Steve Kargl
2015-07-09 18:59   ` Andre Vehreschild
2015-07-09 19:41     ` Steve Kargl
2015-07-10  9:44       ` Andre Vehreschild
2015-07-10 13:41         ` Steve Kargl
2015-07-10 16:20           ` Mikael Morin
2015-07-10 16:44             ` Andre Vehreschild
2015-07-10 18:57             ` Steve Kargl
2015-07-11 10:37               ` Andre Vehreschild
2015-07-11 11:06                 ` Mikael Morin
2015-07-11 11:58                 ` Dan Nagle
2015-07-13 17:27                   ` Mike Stump
2015-07-11 10:54               ` Mikael Morin
2015-07-11 10:58                 ` Andre Vehreschild
2015-07-11 15:37                 ` Steve Kargl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150709122518.08388506@vepi2 \
    --to=vehre@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).