Fortran - getting env. variables in gfortran...

Author

getting env. variables in gfortran...

icksa1@gmail.com

2006-04-13, 7:03 pm

Hi:
I'm trying to compile a code in gfortran that needs to know the values
of several environment variables...I was wondering if there was a
function, like getenv, that would return the values, something like...

path = getenv("PATH") or
call getenv("PATH",path)

Thanks

Steven G. Kargl

2006-04-13, 7:03 pm

In article <1144944470.258669.271360@i39g2000cwa.googlegroups.com>,
icksa1@gmail.com writes:
> Hi:
> I'm trying to compile a code in gfortran that needs to know the values
> of several environment variables...I was wondering if there was a
> function, like getenv, that would return the values, something like...
>
> path = getenv("PATH") or
> call getenv("PATH",path)
>

troutmask:kargl[207] gfortran -o a a.f90
troutmask:kargl[208] setenv UPSIDE down
troutmask:kargl[209] ./a
upside = down
troutmask:kargl[210] cat a.f90
program a
character(len=40) up
call getenv("UPSIDE", up)
print *, 'upside = ', up
end program a

Note, if you don't find an intrinsic procedure listed in the
gfortran documentation, then check the old g77 manual. Gfortran
has (or should have) implemented all of the procedures available
in g77. Unfortunately, gfortran documentation is lagging
behind.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

George N. White III

2006-04-14, 8:04 am

On Thu, 13 Apr 2006, icksa1@gmail.com wrote:

> Hi:
> I'm trying to compile a code in gfortran that needs to know the values
> of several environment variables...I was wondering if there was a
> function, like getenv, that would return the values, something like...
>
> path = getenv("PATH") or
> call getenv("PATH",path)

Be careful what you ask for.

Rather than ask: "how can I do XXX in gfortan/ifort/icc/...?" it is
generally better to ask: "is there a well documented, well engineered, and
portable library that provides the functionality I need across a
reasonable set of platforms?". This should lead you to consider using:

subroutine pxfgetenv( name, lenname, value, lenval, ierror )

c subroutine pxfgetenv() is described in section 4.6.1. the
c character length conventions are described in section 2.3.2.4.
c
c name [in] environment variable to be matched.
c lenname [in] length of name. if 0, trim trailing spaces.
c value [out] value of the variable.
c lenval [out] length of value. if 0, name was matched but no value.
c ierror [out] return code. 0 for success.
c EINVAL if not in the environment list.
c ETRUNC if value required truncation.
c -1 for other errors.
c

Google for "pxfgetenv" gives pages of hits (curiously, "libpxf" gets
none). SGI's http://techpubs.sgi.com is a good place to read the IRIX man
pages.

Gfortran almost certainly implements "getenv" functionality in some
idiosyncratic, undocumented, and potentially unsafe (in the sense of not
checking that the buffer is long enough to hold "$PATH") way. Walter
Spector recently asked on this list for expressions of interest in his
implementation of the POSIX bindings for Fortran, libpxf.

Ron Shepard also implemented some of the pxf functions. I've used his
library wqith g77 on OS/2, Win16, and NeXtStep, assorted unixes, and
linux. Now I'm using it with g95 on linux.

--
George N. White III <aa056@chebucto.ns.ca>

Steven G. Kargl

2006-04-14, 7:05 pm

In article <Pine.LNX.4.64.0604140812380.20173@cerberus.cwmannwn.nowhere>,
"George N. White III" <aa056@chebucto.ns.ca> writes:

> Gfortran almost certainly implements "getenv" functionality in some
> idiosyncratic, undocumented, and potentially unsafe (in the sense of not
> checking that the buffer is long enough to hold "$PATH") way.

Undocumented? Surely, you're joking. The SOURCE CODE is available
for your perusal.

http://gcc.gnu.org/viewcvs/trunk/li.../env.c?view=log

Unsafe? Well, check the SOURCE CODE.

Very few compilers (with the exceptions of f2c, g77, gfortran, openwatcom,
and g95) provide the SOURCE CODE for their runtime libraries.

The gfortran manual is missing the documentation of the
API for getenv, which I've already stated is available in
the g77 manual.

> Ron Shepard also implemented some of the pxf functions. I've used his
> library wqith g77 on OS/2, Win16, and NeXtStep, assorted unixes, and
> linux. Now I'm using it with g95 on linux.

Without knocking Ron, have you checked the safety of his source code.
Where can one find his code?

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Ron Shepard

2006-04-14, 7:05 pm

In article <e1ogod$hlv$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

>
> Without knocking Ron, have you checked the safety of his source code.
> Where can one find his code?

ftp://ftp.tcg.anl.gov/pub/libpxf

I have not worked on this in several years, but I think the answer
to the question isn't so much about the implementation but rather
the API. The posix API is very well designed (within f77) to handle
all possible errors, whereas the f2c style getenv() interface
wasn't. If the API is limited and inflexible, then the code can't
be "fixed" even if you have the source.

$.02 -Ron Shepard

Steven G. Kargl

2006-04-14, 7:05 pm

In article <ron-shepard-BC8CB6.12033914042006@comcast.dca.giganews.com>,
Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:
> In article <e1ogod$hlv$1@gnus01.u.washington.edu>,
> kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
>
> ftp://ftp.tcg.anl.gov/pub/libpxf

Thanks for the pointer.

> I have not worked on this in several years,

ftp> ls
227 Entering Passive Mode (146,137,86,42,94,28)
150 Here comes the directory listing.
-rw-r--r-- 1 0 101 84397 Dec 15 1994 libpxf.tar.Z

:-)

After 30 to 45 minutes of google, I've finally located at pdf copy
of the libpxf standard. I doubt anyone actively working on gfortran
will attack the 146 page stnadard anytime soon.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Brooks Moses

2006-04-14, 7:05 pm

Steven G. Kargl wrote:
> After 30 to 45 minutes of google, I've finally located at pdf copy
> of the libpxf standard. I doubt anyone actively working on gfortran
> will attack the 146 page stnadard anytime soon.

Would you mind posting a pointer to where you finally found it? I'd be
interested.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Steven G. Kargl

2006-04-14, 7:05 pm

In article <44403018.3020209@cits1.stanford.edu>,
Brooks Moses <bmoses-nospam@cits1.stanford.edu> writes:
> Steven G. Kargl wrote:
>
> Would you mind posting a pointer to where you finally found it? I'd be
> interested.
>

http://ieeexplore.ieee.org/iel1/289....pdf?isnumber=\
4710&prod=STD&arnumber=182910&arSt=&ared=&arAuthor=

Note, I wrapped the line at the ''. You'll need to unwrap it.
The google search was "pxf fortran bindings"

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Walter Spector

2006-04-15, 4:07 am

"Steven G. Kargl" wrote:
> ...
> After 30 to 45 minutes of google, I've finally located at pdf copy
> of the libpxf standard. I doubt anyone actively working on gfortran
> will attack the 146 page stnadard anytime soon.

Note that about 50 pages of it is simply "rationale".

Having implemented almost all of it, I can safely say that it isn't
that hard. (Except for the routines in §8.5 and 8.6 - which require
specific interfacing into the I/O lib of the compiler in use. Signals
are a little tricky too.)

I agree with Ron and George - it is very nice to write against a well-
defined API. PXF does have its warts. No doubt about it. But that
doesn't mean it shouldn't be used at all.

I do wish there was any kind of activity to update/replace it. There
are a few typos. Some of the examples in the rationale don't work.
And there are some badly needed routines to round out the package.
Not to mention a f90 module to contain interface blocks.

And for the zillionth time I will opine that F2003 C Interop is not
going to solve the worlds problems. In fact, I think it may lead to
new portability nightmares.

Walt

Steven G. Kargl

2006-04-15, 4:07 am

In article <444083C1.432753E7@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
> "Steven G. Kargl" wrote:
>
> Note that about 50 pages of it is simply "rationale".

Well, I just found the document. I haven't had the time to
read it.

> Having implemented almost all of it, I can safely say that it isn't
> that hard. (Except for the routines in §8.5 and 8.6 - which require
> specific interfacing into the I/O lib of the compiler in use. Signals
> are a little tricky too.)

Any chance you own the copyright to your code? Any chance that you
might consider assigning a copyright to the FSF or making the code
public domain? gfortran (and g95) would provide libpxf much faster
if these projects did not need to re-invent the wheel. I downloaded
Ron's library and it does not build on FreeBSD (and I'm guessing it
doesn't build on linux) with some (major) modifications. Also, Ron's
library is a only a minor subset of the POSIX standard.

> I agree with Ron and George - it is very nice to write against a well-
> defined API. PXF does have its warts. No doubt about it. But that
> doesn't mean it shouldn't be used at all.

It's simply a question of time and availability of the standard.

> I do wish there was any kind of activity to update/replace it. There
> are a few typos. Some of the examples in the rationale don't work.
> And there are some badly needed routines to round out the package.
> Not to mention a f90 module to contain interface blocks.

The pdf file I found is of a 1992 IEEE POSIX standard against
Fortran 77. A newer standard would be a Good Thing or provisions
within F2008 for an interface to the operating system would be
nice.

> And for the zillionth time I will opine that F2003 C Interop is not
> going to solve the worlds problems. In fact, I think it may lead to
> new portability nightmares.

You might be correct with respect to the portability nightmare,
but I can assure you that gfortran will have F2003 C Interop well
before PXF support (unless someone steps forward very quickly).
Also, note that gfortran targets numerous
processors, architectures, and OS's. It will never out perform
a compiler written for a specific OS, but it will be portable.
If gfortran had libpxf, the gfortran developers would try to make
it as portable as possible.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Ron Shepard

2006-04-15, 7:01 pm

In article <e1q2hi$tqt$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

> Also, Ron's
> library is a only a minor subset of the POSIX standard.

Yes, this is something I should have said before too. It is the
subset that I needed at the time. However, it is also the subset
(including environment variables and command-line arguments) that
has been the subject of hundreds of posts here to RSB over the past
15 years; if that standard had been more popular it would have been
a workable solution to many people for a good fraction of an entire
programming career and who, in the meantime, either reinvented their
own solutions or are still waiting for f2003 to be implemented.

$.02 -Ron Shepard

George N. White III

2006-04-16, 8:03 am

On Sat, 15 Apr 2006, Ron Shepard wrote:

> In article <e1q2hi$tqt$1@gnus01.u.washington.edu>,
> kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
>
> Yes, this is something I should have said before too. It is the
> subset that I needed at the time. However, it is also the subset
> (including environment variables and command-line arguments) that
> has been the subject of hundreds of posts here to RSB over the past
> 15 years; if that standard had been more popular it would have been
> a workable solution to many people for a good fraction of an entire
> programming career and who, in the meantime, either reinvented their
> own solutions or are still waiting for f2003 to be implemented.

I take a long-term view. If I need something that is in the POSIX
standard, my Fortran code will use the POSIX interface. If the platform
doesn't have an implementation, I can write cover functions for the
functions provided by the compiler or port Ron's library. The important
thing is that I don't have to diddle with the Fortran sources when I move
to a new platform. Some people who want to use my code do complain
because I didn't adopt the conventions used by their platform/compiler,
but there are many more Fortran programs in the world than there are
compilers. It makes much more sense to make the changes to one library
for each compiler than to make essentially the same changes to many
Fortran programs.

The short-term view is that I want to get this program working today and I
don't care if I will have to redo it in 2 years.

--
George N. White III <aa056@chebucto.ns.ca>

Steven G. Kargl

2006-04-16, 10:03 pm

In article <Pine.LNX.4.64.0604160909200.20148@cerberus.cwmannwn.nowhere>,
"George N. White III" <aa056@chebucto.ns.ca> writes:
> On Sat, 15 Apr 2006, Ron Shepard wrote:
>
>
> I take a long-term view. If I need something that is in the POSIX
> standard, my Fortran code will use the POSIX interface. If the platform
> doesn't have an implementation, I can write cover functions for the
> functions provided by the compiler or port Ron's library. The important
> thing is that I don't have to diddle with the Fortran sources when I move
> to a new platform. Some people who want to use my code do complain
> because I didn't adopt the conventions used by their platform/compiler,
> but there are many more Fortran programs in the world than there are
> compilers. It makes much more sense to make the changes to one library
> for each compiler than to make essentially the same changes to many
> Fortran programs.

If the POSIX standard is to be implemented in a compiler, then I would
expect the entire 146 page standard to be implemented (not a small
selection of routines). This means that the changes aren't confined
to the library of the compiler. Perhaps, you need to re-read 0.README
from Ron's library.

"These routines provide support for the fortran binding to
posix operating systems as defined in IEEE STD 1003.9-1992
POSIX FORTRAN 77 Language Interfaces. A fully-conforming
implementation is not possible using an external library
alone; compiler support and runtime I/O library support is
also required."

As to portability, I'd guess that g77/gfortran is much more
portable than Ron's libpxf code. In my sample of 1 operating
system, which comes bundled with g77, I can easily compile
gfortran. I can't get Ron's code to build. :)

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Gary L. Scott

2006-04-16, 10:03 pm

George N. White III wrote:
> On Sat, 15 Apr 2006, Ron Shepard wrote:
>
>
>
> I take a long-term view. If I need something that is in the POSIX
> standard, my Fortran code will use the POSIX interface. If the platform
> doesn't have an implementation, I can write cover functions for the
> functions provided by the compiler or port Ron's library. The important
> thing is that I don't have to diddle with the Fortran sources when I
> move to a new platform. Some people who want to use my code do complain
> because I didn't adopt the conventions used by their platform/compiler,
> but there are many more Fortran programs in the world than there are
> compilers. It makes much more sense to make the changes to one library
> for each compiler than to make essentially the same changes to many
> Fortran programs.
>
> The short-term view is that I want to get this program working today and
> I don't care if I will have to redo it in 2 years.
>
Even better (than this horrid posix standard) would be to incorporate an
operating system binding for the most commonly needed functions into the
Fortran standard (processes, threads, priorities, interprocess
communication, etc).

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary L. Scott

2006-04-16, 10:03 pm

Gary L. Scott wrote:

> George N. White III wrote:
>
> Even better (than this horrid posix standard) would be to incorporate an
> operating system binding for the most commonly needed functions into the
> Fortran standard (processes, threads, priorities, interprocess
> communication, etc).
>
A P.S., inclusion in the Fortran standard that is likely to be the only
way such facilities would ever be properly maintained, updated, looked
after. These separate standards have a history of not being widely
supported and dieing on the vine over time. GKS is another example.
I'd love to see an update of GKS to include basic, modernized GUI
support (it has basic workstation control concepts that could be
expanded upon). But then again it would be a huge amount of work to
catch up to GINO and Winteracter.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

George N. White III

2006-04-17, 8:02 am

On Sun, 16 Apr 2006, Gary L. Scott wrote:

> Even better (than this horrid posix standard) would be to incorporate an
> operating system binding for the most commonly needed functions into the
> Fortran standard (processes, threads, priorities, interprocess communication,
> etc).

What's horrid? The standard is a relatively automatic mapping between
POSIX functions and Fortran 77.

Fortran has traditionally run on systems that aren't POSIX, so it would be
hard to embed POSIX bindings in the Fortran standard. The problem is
that the POSIX bindings (IEEE STD 1003.9-1992 POSIX FORTRAN 77
Language Interfaces) never became popular. I think there are several
reasons:

1) the majority of Fortran programs don't require more than getargs, so
there has been relatively little interest in the other elements of the
binding.

2) 3rd party implementations need a C interface, which is not required to
be documented and can change with new compiler versions

3) the underlying OS calls are not fully standardized, and many programs
must be portable to non-POSIX environments.

What might have helped is a parameterization of the interface to OS
functions so implementations of the above bindings can be made robust. You
need a standard that spells out the actual bindings, but this leaves you
with the possibility that implementing the bindings requires information
that is not readily available and that each new compiler version may
require a different implementation. This parameterization could take the
form of a cfortan.h header on platforms with IEEE POSIX 1003.1 (the C
interface) and ANSI C to the system. I think this header provides most of
the information needed for a portable interface to the system. In
practice, Fortran vendor A may not want to write headers for a C compiler
sold by a competitor.

For the majority of Fortran programs, portablity to non-POSIX environments
is more important than access to every POSIX capability. The fact remains
that IEEE STD 1003.9-1992 provides an interface to a the subset
of POSIX that is available on the most widely used systems and that is
clearly better (e.g., the size of string buffers is passed to the
interface) than the ad-hoc interfaces compiler vendors see fit to provide.

Are there examples where a vendor's binding is better than the one
specified in IEEE STD 1003.9-1992? In my experience, converting from
vendor to IEEE STD 1003.9-1992 has been very mechanical, so using vendor
bindings is only good for the vendor and people who get paid for porting
code from compiler A to compiler B.

--
George N. White III <aa056@chebucto.ns.ca>

Ron Shepard

2006-04-17, 7:03 pm

In article
<Pine.LNX.4.64.0604170823190.944@cerberus.cwmannwn.nowhere>,
"George N. White III" <aa056@chebucto.ns.ca> wrote:

> On Sun, 16 Apr 2006, Gary L. Scott wrote:
>
>
> What's horrid? The standard is a relatively automatic mapping between
> POSIX functions and Fortran 77.

When I read the above comment, I thought he was referring to the
POSIX standard itself, not just to the fortran 77 interface. I
understand this point of view, and I've heard many other people here
complain about it, I just think it was shortsighted. The POSIX
standard is a low-level interface to operating system functionality.
Some programmers don't want a low-level interface, they want a
high-level interface. My feeling is that given a good, robust,
flexible low-level interface, you can always write whatever
task-specific high-level interface you want to suite your needs.
Given a specific high-level interface, you cannot always adapt it to
your needs. If you are a real programmer, the low-level interface
is what you want, if you are a user, then a high-level interface is
what you want. Most fortran programmers are both, or at least
somewhere in between, so it is a difficult market to target this
kind of software.

Given the POSIX standard itself, which was already mature in 1990, I
agree that the fortran interface is relatively straightforward. It
is difficult to see how it could have been done much better within
f77 (i.e. fixed-length character strings, no user-defined data
structures, etc.). F90, f95, or even f03, it is a different matter,
I think a much better interface could be designed now than then.
But remember in 1990 and 1991 that f90 still had not yet been
approved , and there had been a decade of foot-dragging and sabotage
by various vendors who were trying to kill the fortran language and
support only C and its offspring. Among other purposes, the f77
POSIX API was one way to try to save the language from its death by
starvation. It was a way to give programmers a standard way to
access command line arguments, access environment variables, to do
character-based I/O to filesystems, and other similar everyday tasks
that had been needed over the past decade and which even the various
F8x documents were not addressing.

$.02 -Ron Shepard

Walter Spector

2006-04-17, 7:03 pm

"Steven G. Kargl" wrote:
> ...
> If the POSIX standard is to be implemented in a compiler, then I would
> expect the entire 146 page standard to be implemented (not a small
> selection of routines). This means that the changes aren't confined
> to the library of the compiler. Perhaps, you need to re-read 0.README
> from Ron's library.
>
> "These routines provide support for the fortran binding to
> posix operating systems as defined in IEEE STD 1003.9-1992
> POSIX FORTRAN 77 Language Interfaces. A fully-conforming
> implementation is not possible using an external library
> alone; compiler support and runtime I/O library support is
> also required."

Rons comment is slightly pessimistic. No compiler support is needed. However
to properly implement the calls in §8.5 and 8.6, there would definately
be some, but not a lot of, work in the associated run-time libs. I'd suspect
the needed bits are usually there under the hood anyway. But each environment
needs to be looked at seperately.

As to your previously asked question:

My Personal Edition of PXF is an original work, written by me, and not
based on any other code. I have not decided how I want the copyright
notice to read. I'd like it to be loose enough to meet most folks needs.
(But certain parts of the GPL rub me the wrong way...)

It is curious that your copy of the Standard is 146 pages long. My copy
is 180 pages. The main body of it is 117 pages, and the rest is Rationale.

As to portability, realize that it is a POSIX Standard for POSIX-like
systems. The calls are roughly 1:1 with their C-callable equivalents.
As one veers away from unix-like environments, this obviously would change.
I developed my package using cygwin on Windows. Cygwin supports just about
everything required by PXF. But if someone wanted PXF functionality on a
Very Different OS, obviously only subsets would be practical. Still, it
provides a framework for those subsets.

Walt

Steven G. Kargl

2006-04-17, 7:03 pm

In article <4443BDD2.D39B49DC@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
>
> As to your previously asked question:
>
> My Personal Edition of PXF is an original work, written by me, and not
> based on any other code. I have not decided how I want the copyright
> notice to read. I'd like it to be loose enough to meet most folks needs.
> (But certain parts of the GPL rub me the wrong way...)

The GPL also rubs me the wrong way. I prefer a 2 clause BSD license
if I'm going to give code out. The only time I use the GPL is for
contributions to gfortran (where typically I'm editing an already GPL'd
file).

> It is curious that your copy of the Standard is 146 pages long. My copy
> is 180 pages. The main body of it is 117 pages, and the rest is Rationale.

I posted the URL. The title of the doc is

IEEE Standard for Information
Technology--POSIX FORTRAN 77
Language Interfaces--Part 1: Binding for
System Application Program Interface
(API)

Hmm, it says "Part 1". Perhaps, the remaining pages are "Part 2".

> As to portability, realize that it is a POSIX Standard for POSIX-like
> systems. The calls are roughly 1:1 with their C-callable equivalents.
> As one veers away from unix-like environments, this obviously would change.
> I developed my package using cygwin on Windows. Cygwin supports just about
> everything required by PXF. But if someone wanted PXF functionality on a
> Very Different OS, obviously only subsets would be practical. Still, it
> provides a framework for those subsets.

Having implemented several of gfortran's nonstandard intrinsics procedures
for compatibility with g77, I certainly understand the above observation.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Richard E Maine

2006-04-17, 7:03 pm

Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:

> http://ieeexplore.ieee.org/iel1/289....pdf?isnumber=\
> 4710&prod=STD&arnumber=182910&arSt=&ared=&arAuthor=
>
> Note, I wrapped the line at the ''. You'll need to unwrap it.
> The google search was "pxf fortran bindings"

Thanks for the link. It worked for me. I had looked before at one time
or other, but hadn't located a copy. I don't know whether my failure was
because of my googling skills, inadequate time spent, lack of
availability then (it was a while ago - I forget how long), or whatever.

While I am no big fan of that standard (for reasons discussed before -
and no, I don't feel like rehashing them), it is still handy to have a
convenient electronic copy. I've got an old paper copy of a draft
version (which was horrid; though I dislike the final standard, it is
hugely improved over that draft). And I saw the final standard
somewhere, but I don't off-hand recall where I stashed my copy, assuming
that I actually have one. Anyway, having a pdf is far more convenient; I
should be able to file this somewhere that I can find it. So thanks
again.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links