JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for COMP-FORTRAN-90 Archives


COMP-FORTRAN-90 Archives

COMP-FORTRAN-90 Archives


COMP-FORTRAN-90@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

COMP-FORTRAN-90 Home

COMP-FORTRAN-90 Home

COMP-FORTRAN-90  2002

COMP-FORTRAN-90 2002

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: /dev/null and scope of UNITs

From:

Richard Maine <[log in to unmask]>

Reply-To:

Fortran 90 List <[log in to unmask]>

Date:

Tue, 8 Jan 2002 08:22:32 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (146 lines)

David Vowles writes:

 > Although your library carefully assigns unit numbers
 > there is no way of ensuring that the end-user does not try to open a
 > unit that your library code has already opened.

Yes, that's a fundamental problem of such schemes. Any of several
schemes can work fine if all the code in a program is consistent
about using them. But random code from other sources isn't likely
to use the same scheme as whatever you come up with.

 > To minimize the risk of
 > clashes in this situation I reserve unit numbers with high values (e.g.
 > 1,000,000 to 1,000,999).

That doesn't seem likely to be particularly good about portability.
Lots of implementations don't accept unit numbers greater than 99.
Perhaps the newest versions of current compilers might be better about
this, but I'm sure there are still many compilers in use with
limitations like that. (The question still seems to come up on
occasion from users who have found that some code won't work because
it used large unit numbers).

Though as long as you define this range in one easy-to-change place
and document it is a system dependency, it could presumably be
tailored to accomodate systems with low limits on unit numbers.

My hack for dealing with the problem of code that doesn't use my
assign_lun procedure is to provide a separate procedure reserve_lun.
If I know that some library I'm using hard-wires 42 as a lun, I can
tnen do "call reserve_lun(42)", which will keep assign_lun from using
that one. I can also just call reserve_lun in a loop to reserve a
range of luns.

This does assume that I can find out a'priori what particular luns the
library uses (or at least a range in which they will lie). This is
only an issue for luns that the library might try to use at some
future time. Like several of the other variants of this kind of
capability, I notice and avoid luns that are currently open when
I invoke assign_lun.

This isn't a perfect solution, but its the one I use.

Below is my version of this capability. Extracted from a file that
also contained several other utility functions of the nature indicated
by the module name. I think the only thing this references that I
didn't include is my error_halt subroutine, whose function should
be obvious from the name and usage.

This code isn't very sophisticated. I've seen other versions that
do some additional checks of the unit number. (I think it was to
make sure that the unit existed). Strictly speaking those might be
needed, and someday I might add them...but this code was written
before that was pointed out to me....and I've never actually run into
a problem from that, so I left the code as is.


!-- sysdepIo.f90
!-- System-dependent. Generic version.
!-- 9 Dec 92, Richard Maine: Version 1.0.
!....elided a bunch of stuff....this copy just has the lun assignments,

module sysdep_io

  !-- General system-dependent support routines.
  !-- System-dependent. Generic version.
  !-- 20 Jun 96, Richard Maine.

  implicit none
  private

  !-- The list of legal logical unit numbers is system-dependent.
  !-- We avoid low-numbered luns to minimize likely system conflicts.
  integer, parameter :: min_lun=10, max_lun=99
  logical, save :: lun_is_free(min_lun:max_lun) = .true.

  !-- Public procedures.
  public assign_lun, release_lun, reserve_lun

contains

  subroutine assign_lun (lun)

    !-- Assign an available Fortran logical unit number.
    !-- Aborts if no lun can be assigned; there are no error returns.
    !-- 15 Jun 90, Richard Maine.

    !-------------------- interface.
    integer, intent(out) :: lun !-- Logical unit number.

    !-------------------- local.
    integer :: iostat
    logical :: used

    !-------------------- executable code.

    do lun = min_lun , max_lun
      if (lun_is_free(lun)) then
        inquire(unit=lun, opened=used, iostat=iostat)
        if (iostat /= 0) used = .true.
        lun_is_free(lun) = .false.
        if (.not.used) return
      end if
    end do
    call error_halt('No luns available in assign_lun')
    return
  end subroutine assign_lun

  subroutine reserve_lun (lun)

    !-- Reserve a specific Fortran logical unit number.
    !-- 15 Jun 90, Richard Maine.

    !-------------------- interface.
    integer, intent(in) :: lun
         !-- Logical unit number. Illegal values are quietly ignored.

    !-------------------- executable code.

    if (lun>=min_lun .and. lun<=max_lun) lun_is_free(lun) = .false.
    return
  end subroutine reserve_lun

  subroutine release_lun (lun)

    !-- Release a Fortran logical unit number for reuse.
    !-- No checking is done to see that the lun is actually closed;
    !-- assign_lun will check that before re-assigning it.
    !-- 15 Jun 90, Richard Maine.

    !-------------------- interface.
    integer, intent(in) :: lun
         !-- Logical unit number. Illegal values are quietly ignored.

    !-------------------- executable code.

    if (lun>=min_lun .and. lun<=max_lun) lun_is_free(lun) = .true.
  end subroutine release_lun

end module sysdep_io

--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
                             | -- Mark Twain

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

December 2023
February 2023
November 2022
September 2022
February 2022
January 2022
June 2021
November 2020
September 2020
June 2020
May 2020
April 2020
December 2019
October 2019
September 2019
March 2019
February 2019
January 2019
November 2018
October 2018
September 2018
August 2018
July 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
April 2015
March 2015
January 2015
December 2014
November 2014
October 2014
August 2014
July 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
July 2013
June 2013
May 2013
April 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
August 2010
July 2010
June 2010
March 2010
February 2010
January 2010
December 2009
October 2009
August 2009
July 2009
June 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager