Fortran - Nice to have feature in upcoming Fortran compilers...

Author

Nice to have feature in upcoming Fortran compilers...

nobat@hotmail.com

2005-05-19, 4:01 pm

Interoperability with C is now a part of ISO standard. It would be nice
to have an automatic Fortran interface generator. A utility that parse
C file headers and then generates corresponding ISO-conform binding
module(s). In one scenario such a utility would be an integrated part
of a commercial Fortran compiler.
In the best scenario, it would be an open-source community-based effort
(like SWIG)

Nobat

David Flower

2005-05-20, 8:57 am

Here are two items from my wish list; one specific, and one general:

A method of specifying global COMMON, together with associated
intrinsics for spawning programs.

A change in the approach to extensions. Consider the following
statement, not present as far as I know in any FORTRAN standard:
INTEGER*2 I
(Purists may prefer the F90 format, but there's a lot of this sort of
code out there).
This standard should state that this statement EITHER:
- Declares a fixed-point variable which occupies 2 bytes of memory and
has values in the inclusive interval(-32768,32767
OR:
- Causes the compiler to generate an error.
This approach could beneficially be applied to intrinsics

Richard E Maine

2005-05-20, 3:59 pm

In article <1116574385.814976.172520@z14g2000cwz.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

> Here are two items from my wish list; one specific, and one general:
>
> A method of specifying global COMMON, together with associated
> intrinsics for spawning programs.

I'm not sure what you mean by global COMMON. Because of the tied
mention of spawning programs, I think maybe you are talking about
sharing a COMMON between multiple processes.

I'd also like to see something for spawning programs; tried to sneak
something in at the last minute in f2003, but it was too late. There
are proposals for it in the next standard, but I don't know their status.

As for sharing memory between programs - wouldn't be shocking to see
something, but I'd be mildly surprised to see it done with COMMON. I
realize that there are old extensions using COMMON for this purpose.

> A change in the approach to extensions. Consider the following
> statement, not present as far as I know in any FORTRAN standard:
> INTEGER*2 I
> (Purists may prefer the F90 format, but there's a lot of this sort of
> code out there).
> This standard should state that this statement EITHER:
> - Declares a fixed-point variable which occupies 2 bytes of memory and
> has values in the inclusive interval(-32768,32767
> OR:
> - Causes the compiler to generate an error.
> This approach could beneficially be applied to intrinsics

I'm not quite sure that I understand what you are asking for. I think
this is the general proposal, but you only give an example instead of
actually saying what the general proposal is. I'm having trouble
deducing the general proposal from the one example. Possibilities that
occur to me include

1. Perhaps you are arguing for more adoption of common extensions (such
as integer*2) into the language.

2. Perhaps you are arguing for requiring compiler diagnostics for all
extensions.

or

3. I haven't a clue what you are asking for..

I can sort of read elements of either 1 or 2 in what you wrote, but I'm
thinking that 3 is the most likely.

If you did mean 1, then that's pretty much an eternal debate - exactly
which common extensions to adopt into the language. I suspect it will
continue to be debated. I'll defer detailed comment about the particular
integer*2 syntax; that one isn't my personal favorite, but I have pushed
for a simple way to specify cases like that using other syntax.

If you meant 2, that's already pretty much in the standard, at least as
far as it applies to syntax extensions. If your compiler doesn't have
the ability to diagnose integer*2 as an extension, then it is broken
(though you might have to turn on a switch to ask for such diagnosis).

Oh. A variant of 3 just occurred to me. Perhaps you are asking for
features to be adopted into the language as a kind of optional feature,
where the compiler is required to be able to recognize what feature is
being requested, even if the compiler doesn't support using the feature.
The compiler has to either implement it or diagnose it as an optional
feature that the compiler doesn't do. There are a few things like that
now. Perhaps you are asking for more.

--
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

David Flower

2005-05-20, 3:59 pm

3 is the closest.

What I am asking is a guarantee that one compiler's extension will not
be interpreted differently by another. I'm not worried if it generates
a pile of error messages, or even crashes the compiler.

Bit I do not want the compiler silently to produce a program that does
something different

Richard E Maine

2005-05-20, 3:59 pm

In article <1116601066.055600.147130@g43g2000cwa.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

> What I am asking is a guarantee that one compiler's extension will not
> be interpreted differently by another.

That's pretty much impossible for the standard to do with any
generality. Well.... without a *MAJOR* change that isn't going to
happen. The only way to do that is to essentially say that extensions
are not allowed.... which isn't going to happen in Fortran.

You can do it for a specific list of extensions by adopting them into
the standard and then making their implementation optional. That was
sort of the afterthought that had occurred to me. That would work.

But I don't see how you can do it in general, particularly if you
include all kinds of extensions instead of just syntax ones. Syntax
extensions are at least compile-time detectable and already required to
be so. Some extensions are in run-time areas where it isn't going to be
plausible to require diagnosis. And there are some features of the
standard that are specifically crafted to allow multiple implementation
strategies. If a code depends on the use of a particular implementation
strategy, you could call some features of the implementation an
"extension". If you dictate that those must work only one way, then you
just destroyed the whole point of the specification.

--
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

Gordon Sande

2005-05-20, 3:59 pm

David Flower wrote:
> 3 is the closest.
>
> What I am asking is a guarantee that one compiler's extension will not
> be interpreted differently by another. I'm not worried if it generates
> a pile of error messages, or even crashes the compiler.
>
> Bit I do not want the compiler silently to produce a program that does
> something different
>

Surely that outcome is guaranteed if you use exactly no vendor
extensions. Lacking that you could insist that your new vendor
be totally compatible with your old vendor, otherwise you will
not switch. Again no extensions by you makes it easy for the
vendors to meet the requirement. Otherwise you may have a short
list of vendors.

Even then you have the problem that there are thins that the vendors
are allowed to do differently within the standard. I/O comes to mind.

Vendor extensions are a bet by you on the vendor.

I am always guaranteed to break even at Los Vegas by my betting
strategy. Namely, no betting! ;-)

glen herrmannsfeldt

2005-05-20, 3:59 pm

David Flower wrote:

(snip)

> A change in the approach to extensions. Consider the following
> statement, not present as far as I know in any FORTRAN standard:
> INTEGER*2 I
> (Purists may prefer the F90 format, but there's a lot of this sort of
> code out there).
> This standard should state that this statement EITHER:
> - Declares a fixed-point variable which occupies 2 bytes of memory and
> has values in the inclusive interval(-32768,32767
> OR:
> - Causes the compiler to generate an error.

As far as I know, the standard doesn't have any requirements like that
on any data type, so I would not expect one for non-standard types.

C89, and I believe C99 allow twos complement, ones complement,
and sign magnitude signed int representation, and I believe that Fortran
also allows those. A two byte integer might only go to -32767.

The PDP-10 (TOPS-10) Fortran compiler accepts REAL*4 for single
precision (36 bits) and REAL*8 for 72 bit floating point, though
it is not byte addressable. It only has one INTEGER size.

-- glen

FJRA

2005-05-21, 3:56 pm

Hi, about a Nice to have feature in upcoming Fortran compilers... as
far as I know, getarg, and the corresponding iarg, narg, etc, are not
part of the standard. Are they going to be some time? Because, I think
some compilers have these routines (not all the routines, but some
subset) incorporated into their extensions, but maybe they don't work
in the same way. If anyone knows how to make the work they do with
standard instructions, please tell me. Thanks.

Richard Maine

2005-05-21, 3:56 pm

"FJRA" <a19980403@pucp.edu.pe> writes:

> Hi, about a Nice to have feature in upcoming Fortran compilers... as
> far as I know, getarg, and the corresponding iarg, narg, etc, are not
> part of the standard. Are they going to be some time?

Yes, approximately. Lots of other people wanted this also. The same
functionality is in f2003. The exact spelling is different from
iargc and friends, but the same functionality (and a little more)
is there. The spelling was made slightly different specifically
because there are many small differences between current versions.
It is impossible for the standard to be the same as all existing
implementations.

Therefore, the standard version was made slightly different from
existing implementations. This allows cokmpilers to support their
existing version and the new standard one at the same time so that
existing codes don't have to be changed, but new ones can use the
standard version.

As long as the spelling was changing anyway, a few small bits of
extra functionality were added, but those were not the main reason
for the spelling change.

You can esentially get the f2003 version in current compilers by
downloading Lawson Wakefield's f2kcli package from
<http://www.winteracter.com/f2kcli>.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

owl

2005-05-21, 8:57 pm

Richard Maine wrote:
>
> "FJRA" <a19980403@pucp.edu.pe> writes:
>
>
> You can esentially get the f2003 version in current compilers by
> downloading Lawson Wakefield's f2kcli package

A point & click access (a la native win app*) would be nicer still,
instead of suggesting a retro C throwback to the seventies.

---
* along the lines of Mr. Sans_GUI advocacy who apparently killed his
ambitious product by also coupling it with *FOO*ls.

Anton Haumer

2005-05-22, 3:57 pm

Nice to have: Pointers and pointer arithmetic like in C ...

Toni

Gary L. Scott

2005-05-22, 3:57 pm

Anton Haumer wrote:
> Nice to have: Pointers and pointer arithmetic like in C ...
>
> Toni

Some here might call that a deficiency of C ... However, with the F2k3
C interoperability features, you may get some of this by default. You
already have "pointers" though, unless you're just asking for
"addresses" and address manipulation.

--

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

glen herrmannsfeldt

2005-05-22, 8:56 pm

Gary L. Scott wrote:
> Anton Haumer wrote:

[color=darkred]
> Some here might call that a deficiency of C ... However, with the F2k3
> C interoperability features, you may get some of this by default. You
> already have "pointers" though, unless you're just asking for
> "addresses" and address manipulation.

I do agree that in many cases C's pointer arithmetic makes programs
less readable. Many times it is used to do things that Fortran can
easily do in other ways.

But I also believe that Fortran pointers, at least as of F95, are a
little more restrictive than they could be. The inability to point
to pointers, for example, or arrays of pointers. (Except through
structures.)

-- glen

Jan Vorbrüggen

2005-05-23, 3:58 pm

> But I also believe that Fortran pointers, at least as of F95, are a
> little more restrictive than they could be. The inability to point
> to pointers, for example, or arrays of pointers.

I don't want pointers to naked pointers - pointing to a data structure
that contains (only) a pointer is easier to read, and should be just as
efficient.

I had understood that the array of pointers had a syntactical problem
with some kind of ambiguity...but my memory is drawing a blank here.

Jan

Michael Metcalf

2005-05-23, 3:58 pm

"Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:3fdq6kF73t36U1@individual.net...
>
> I had understood that the array of pointers had a syntactical problem
> with some kind of ambiguity...but my memory is drawing a blank here.
>

They have a storage problem, as the storage pattern would, potentially, be
ragged. It's an implementation difficulty (see end of 6.13 in M&R or MR&C).

Regards,

Mike Metcalf

NuclearWizard

2005-05-23, 3:58 pm

I would love a "more consistent/generic" type-kind declaration to
include intrinsic _and_ derived types. Basically I would like TYPE and
KIND to be allowed attributes for entity-oriented variable
declarations. For example, I would like this to be allowed,

TYPE(real), KIND(sp) :: a

where "real" is some integer type-key referring to the real type and
"sp" is some integer kind-key referring to the single precision kind
(probably 4), instead of the current specification

REAL(sp) :: a

This would greatly facilitate reusable code as the most minor
changes---the TYPE changes from "real-->whatever" and the KIND changes
from "sp-->whatever" would change the type-kind of the code. It's
really just a syntax issue and the only downside I believe is
readability---that is there is the possibility for some poor
programmers to use statements like

TYPE(2), KIND(4) :: a

because they know 2 is the type-key for real numbers on _their_
compiler. But poor programming will always be an issue, better for us
just to create the most logical language, easily parsed by machines but
understood by humans. I would suggest that the named constants REAL,
INTEGER, COMPLEX, LOGICAL, and CHARACTER be required to exist by the
standard and _possibly_ that unnamed constants (like 2 and 4) would not
be allowed in TYPE( ) or KIND( ) attribute specifications.

Ron Shepard

2005-05-23, 3:58 pm

In article <1116853523.012540.106430@f14g2000cwb.googlegroups.com>,
"NuclearWizard" <william.wieselquist@gmail.com> wrote:

> TYPE(real), KIND(sp) :: a
[...]
> This would greatly facilitate reusable code as the most minor
> changes---the TYPE changes from "real-->whatever" and the KIND changes
> from "sp-->whatever" would change the type-kind of the code. It's
> really just a syntax issue and the only downside I believe is
> readability [...]

I have wanted something like this when I change between real and
complex versions of codes. However, I think your last point
probably nixes the whole thing. After all, in your example above
"real" could really mean some kind of integer, or logical, or
character, or perhaps even a derived type, and at that point, the
code is more confusing.

Isn't there something about parameterized declarations in F2003? If
so, how is it done there?

$.02 -Ron Shepard

Michael Metcalf

2005-05-23, 3:58 pm

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
news:ron-shepard-9C9712.10015523052005@comcast.dca.giganews.com...
>
> Isn't there something about parameterized declarations in F2003? If
> so, how is it done there?
>

Here's an example from "Fortran 95/2003 Explained":

type matrix(real_kind,n,m)
integer, kind :: real_kind
integer, len :: n,m
real(real_kind) :: value(n,m)
end type matrix

where the actual kind type parameter and the extents of 'value' can be
defined dynamically.

Regards,

Mike Metcalf

Richard E Maine

2005-05-23, 3:58 pm

In article <1116853523.012540.106430@f14g2000cwb.googlegroups.com>,
"NuclearWizard" <william.wieselquist@gmail.com> wrote:

> I would love a "more consistent/generic" type-kind declaration to
> include intrinsic _and_ derived types. Basically I would like TYPE and
> KIND to be allowed attributes for entity-oriented variable
> declarations. For example, I would like this to be allowed,
>
> TYPE(real), KIND(sp) :: a

The type(real) part of that has been proposed for the next standard
(along with type(any-other-intrinsic-type-name). It makes for
improved consistency with derived types. My opinion is that it is likely
to happen. It is a very small syntactic change, easy to do in the
standard, easy to implement, and with no impact on existing code. Thus,
very little cost. Benefits are small, but positive, and the cost is
small enough that the cost/benefit looks good. I think it will fly.

I'd be more dubious of the proposed KIND(sp) syntax. That looks to me
like it has problems with generalization. Thus I'd say it was in the
opposite direction - that it would foster an inconsistency between
intrinsic and derived types where they are currently consistent.

Recall that derived types can have multiple kind type parameters and
that the name KIND is not reserved. Looks to me like your proposed
syntax requires reserved words if you start to extend it to arbitrary
names for kind type parameters. The current syntax separates type
parameters from attributes in such a way that there is never a conflict.

> I would suggest that the named constants REAL,
> INTEGER, COMPLEX, LOGICAL, and CHARACTER be required to exist by the
> standard

I'd agree on the general principle, but I'd think these poor choices for
the names (unless I misunderstand what they are). I think you are
proposing these as the names for constants for the default kinds. I'd
think it confusing to have a constant for real's default kind be named
REAL. It isn't, after all a constant for the type, but just for the
default kind for the type.

There are a couple of proposals floating around for standard named
constants for kinds. One of them is mine. Details of the proposals vary.

> and _possibly_ that unnamed constants (like 2 and 4) would not
> be allowed in TYPE( ) or KIND( ) attribute specifications.

I'd say that would be very complicated to describe on the standard and
also very unlikely to pass. In terms of the standard, you'd be
introducing a whole new class of expression... and I'm not even sure
what the properties of this class of expression are. Remember that kind
numbers are given by initialization expressions; they aren't restricted
to named or literal constants. This isn't going to be easy to precisely
define for the general case, unless you completely throw out the whole
thing and start over.

If one was going to start over, I think the solution would be to have
kind parameters not be numeric at all. Then you wouldn't need
complicated and arbitrary restrictions to avoid "nastiness". Others have
also proposed similar things.

But you aren't likely to find acceptance of anything along that line
now. There is far, far too large a body of code that does use literal
kind numbers... not to speak of other forms of expressions for kind
numbers. Compatibility with existing code is a big deal in the standard,
and it needs strong justification for breaking. Seems to me like the
basic justification here is "I see a lot of people using what I think to
be a poor style; I want to make that style nonstandard so that they will
have to change." If that's not the essence of the justification, then I
don't know what it would be. (Explaining why you think it poor style
would be just a detail, which doesn't change the basic form of the
justification).

I don't think anything even vaguely close to this has a chance. A
motion for a proposal like that probably wouldn't get a second; heck, it
probably wouldn't find anyone to move it in the first place. Just a
non-starter in my opinion. Realize that I even agree with you that using
explicit kind numbers is questionable style. But the standard doesn't
tend to have what would otherwise be arbitrary restrictions just to
enforce a style.

If you want to introduce a non-numeric concept of kinds, and also make
it so that existing code and the new stuff can coexist for compatibility
and transition... then at least it might be worth proposing (people have
at least mentioned such possibilities). I'd think it a big job and you'd
probably have an uphill battle to justify the costs. I doubt it would
succeed, but it would at least be worth the try if you wanted to. In
contrast with just disallowing literal constants, which I think is a
non-started. All in my opinion, of course.

(Yes, I noticed that you said "possibly" and that I gave an awfully long
and strongly phrased reply for something mostly mentioned as an aside.
But I had a lot to say about it.)

--
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

Richard E Maine

2005-05-23, 3:58 pm

In article
<ron-shepard-9C9712.10015523052005@comcast.dca.giganews.com>,
Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In article <1116853523.012540.106430@f14g2000cwb.googlegroups.com>,
> "NuclearWizard" <william.wieselquist@gmail.com> wrote:
>
> [...]
>
> I have wanted something like this when I change between real and
> complex versions of codes. However, I think your last point
> probably nixes the whole thing. After all, in your example above
> "real" could really mean some kind of integer, or logical, or
> character, or perhaps even a derived type,

No it can't. Fortran is almost free of reserved words. But this is one
of the very few exceptions (and this one is only a partial exception).

The intrinsic type names cannot be used as derived type names. They are
reserved in that context. I say it is only half an exception because you
may, for example, use REAL as a variable name or the name of any other
thing - just not the name of a derived type.

That requirement is already in the language (as of f90, when derived
types were added).

> Isn't there something about parameterized declarations in F2003? If
> so, how is it done there?

Suppose that matrix is a user-defined type with a kind parameter named
kind (you could use any name, but that one is sort of the obvious
choice) and a length parameter named, say size, just to show that the
name doesn't have to be len or length. You could have declarations like

type(matrix) !-- uses default values for kind and size,
!-- assuming that you defined defaults.
!-- Note that it is up to *YOU* to define what defaults
!-- you might want and that the default value of kind for
!-- your matrix type doesn't have to have anything to do
!-- with default real (though that would be one choice).
type(matrix(kind=whatever,size=whatever_
else))
!-- Spelled out in gory detail.
type(matrix(whatever, whatever_else))
!-- positional form.
type(matrix(size=:))
!-- Deferred or assumed.
!-- (Can't do that for kind type parameters).
!-- Can be used with dummy arguments, allocatables,
!-- and pointers.

The keyword "type" (and the parens that go with it) is only for a type
declaration statement... although that happens to be the place where
type specifiers (that's what the things inside of the parens here are
called) will most often be used. There are a few other places where you
can use them, and you don't use the TYPE() bit in those other places -
just the part inside.

--
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

NuclearWizard

2005-05-23, 8:57 pm

> I'd be more dubious of the proposed KIND(sp) syntax. That looks to me

> like it has problems with generalization. Thus I'd say it was in the
> opposite direction - that it would foster an inconsistency between
> intrinsic and derived types where they are currently consistent.

Okay, I can agree with that. Instead of TYPE(A), KIND(B); what about
TYPE(A,B) for a type declaration where A is a type-name (number) and B
is an optional kind-name (number)?

the[color=darkred]

I guess I wasn't clear about how I would use these. I have written a
decent number of routines that I like to have overloaded so they may be
used on multiple type-kinds. As long as the operators used in the body
of a routine (the algorithm) are appropriate for all of the overloaded
type-kinds I can use the same code body for all routines. But I can't
use the same declarations. Consider a sorting routine for real,
complex, and integer variables,

CALL Sort(X)

X could be of type real with two kinds (single and double precision),
complex with two kinds, or integer with kinds corresponding to 1, 2, 4,
and 8 byte-representations. Here is a mock-up of how I coded this
module to maintain the fewest pieces of code (declarations _and_
executable):

MODULE Sort

INTERFACE Sort
MODULE PROCEDURE Sort_Rsp
MODULE PROCEDURE Sort_Rdp
MODULE PROCEDURE Sort_Csp
MODULE PROCEDURE Sort_Cdp
MODULE PROCEDURE Sort_I1
MODULE PROCEDURE Sort_I2
MODULE PROCEDURE Sort_I4
MODULE PROCEDURE Sort_I8
ENDINTERFACE

CONTAINS

SUBROUTINE Sort_Rsp(X)
USE KindsModule,ONLY: KND=>Rsp
INCLUDE 'Sort_R.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Rdp(X)
USE KindsModule,ONLY: KND=>Rdp
INCLUDE 'Sort_R.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Csp(X)
USE KindsModule,ONLY: KND=>Csp
INCLUDE 'Sort_C.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Cdp(X)
USE KindsModule,ONLY: KND=>Cdp
INCLUDE 'Sort_C.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I1(X)
USE KindsModule,ONLY: KND=>I1
INCLUDE 'Sort_I.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I2(X)
USE KindsModule,ONLY: KND=>I2
INCLUDE 'Sort_I.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I4(X)
USE KindsModule,ONLY: KND=>I4
INCLUDE 'Sort_I.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I8(X)
USE KindsModule,ONLY: KND=>I8
INCLUDE 'Sort_I.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

ENDMODULE

So I need three separate header files:

Sort_R.hdr = REAL(KND),INTENT(INOUT) :: X
Sort_C.hdr = COMPLEX(KND),INTENT(INOUT) :: X
Sort_I.hdr = INTEGER(KND),INTENT(INOUT) :: X

I feel like a step in the right direction, in terms of facilitating the
reuse of code, would be to have some statement (like TYPE(A,B)) that I
can use in one header file

Sort.hdr = TYPE(TYP,KND),INTENT(INOUT) :: X

and then define the appropriate TYP and KND for each routine. Thus the
module above would be:

MODULE Sort

INTERFACE Sort
MODULE PROCEDURE Sort_Rsp
MODULE PROCEDURE Sort_Rdp
MODULE PROCEDURE Sort_Csp
MODULE PROCEDURE Sort_Cdp
MODULE PROCEDURE Sort_I1
MODULE PROCEDURE Sort_I2
MODULE PROCEDURE Sort_I4
MODULE PROCEDURE Sort_I8
ENDINTERFACE

CONTAINS

SUBROUTINE Sort_Rsp(X)
INTEGER,PARAMETER :: TYP=REAL
USE KindsModule,ONLY: KND=>Rsp
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Rdp(X)
INTEGER,PARAMETER :: TYP=REAL
USE KindsModule,ONLY: KND=>Rdp
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Csp(X)
INTEGER,PARAMETER :: TYP=COMPLEX
USE KindsModule,ONLY: KND=>Csp
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_Cdp(X)
INTEGER,PARAMETER :: TYP=COMPLEX
USE KindsModule,ONLY: KND=>Cdp
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I1(X)
INTEGER,PARAMETER :: TYP=INTEGER
USE KindsModule,ONLY: KND=>I1
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I2(X)
INTEGER,PARAMETER :: TYP=INTEGER
USE KindsModule,ONLY: KND=>I2
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I4(X)
INTEGER,PARAMETER :: TYP=INTEGER
USE KindsModule,ONLY: KND=>I4
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

SUBROUTINE Sort_I8(X)
INTEGER,PARAMETER :: TYP=INTEGER
USE KindsModule,ONLY: KND=>I8
INCLUDE 'Sort.hdr'
INCLUDE 'Sort.bdy'
ENDSUBROUTINE

ENDMODULE
[color=darkred]
> I'd agree on the general principle, but I'd think these poor choices
for
> the names (unless I misunderstand what they are). I think you are
> proposing these as the names for constants for the default kinds.

Basically, I just like the way kinds "work" and just want a similar
convention for types. Consider the following implementation of types I
tried to describe, where Y may equal the exact words (no quotes)
"REAL", "COMPLEX", "INTEGER", "LOGICAL", and "CHARACTER":

INTEGER,PARAMETER :: X = Y

such that a subsequent type declaration

TYPE(X,KIND=Z) :: a

would declare variable a to have the same type as the declaration

TYPE(Y,KIND=Z) :: a

or

Y(KIND=Z) :: a

I know the last thing people want to see is a bunch of code in these
posts, but I was having trouble illustrating my point.

Richard E Maine

2005-05-23, 8:57 pm

In article <1116880694.510339.278360@g49g2000cwa.googlegroups.com>,
"NuclearWizard" <william.wieselquist@gmail.com> wrote:
[elided]

and I replied

[color=darkred]
> Basically, I just like the way kinds "work" and just want a similar
> convention for types. [explains]

Oh. That was the possibility that vaguely occurred to me when I
mentioned the possibility that I might misunderstand what they are.

This general area has been often discussed, with several different
terminologies. Look for discussions of topics like "generic
programming", "templates", and a few other keywords.

I quite agree that it is an area ripe for further work. It is less
clear which of several general approaches to it would be best.

I seriously doubt, however, that you'd find much consensus on an
approach that involves representing types as integers similar to the way
in which kinds can now be represented as integers.

I am personally more of the opinion that it was a mistake to do kinds as
integers. I like the concept of kinds, but I just wish they weren't
integers. There probably isn't universal agreement on this point.

Anyway, back to a positive note. I want to reiterate that I agree with
the general area of need. My only qualm is about the specific
identification of this concept with a named integer constant.

Do note that there would, in any case, be a *LOT* more to such a
proposal that defining a few named constants. Diddling with typing tends
to have major interactions all over the language.... enough interactions
that people (even experts) tend to overlook some of them at first.

--
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

NuclearWizard

2005-05-24, 3:56 am

Thanks for the topic keywords ("generic programming" and "templates").
It is always great to learn new vocabulary to surf with.
-Will

David Flower

2005-05-24, 8:57 am

I don't know whether this is an old idea, so apologies if it is.

Most compilers have a few hard-wired values for kind type parameters,
with others being meaningless; further there is no standard specifying
what each kind type parameter value means.

Why not allow a compiler option to define an otherwise undefined kind
type parameter ?

Come to think of it, this would probably be consistent with the
standard.

Paul Van Delst

2005-05-24, 3:59 pm

so other's replies may have answered the question you're
asking. My response is "Yeah, well, good luck with that." :o)

> Bit I do not want the compiler silently to produce a program that does
> something different

The best way I've found to do that is to use the "check the standard" compiler switches
most f90/95 compilers have. Something like "-Mstandard" or "--f95" or "-stand f95" (pgf90,
lf95, and ifort).

If I get any standard compliance warnings/messages then I either fix them or send the code
back.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Richard E Maine

2005-05-24, 3:59 pm

In article <1116920633.203113.139180@g14g2000cwa.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

> I don't know whether this is an old idea, so apologies if it is.
>
> Most compilers have a few hard-wired values for kind type parameters,
> with others being meaningless; further there is no standard specifying
> what each kind type parameter value means.
>
> Why not allow a compiler option to define an otherwise undefined kind
> type parameter ?

I'm not sure I understand what you mean here. At first, I thought that
you were suggesting that compilers allow users to specify what kind
numbers correspond to the available representations. To do this with
complete generality would seem like an awful lot of bother for little
return. There exist limited cases of this. For example, the NAG compiler
allows you to select between two kind numbering schemes (their default
sequentially numbered kinds, vs the byte-count scheme).

But on rereading your suggestion, the "otherwise undefined" bit caught
my eye. It makes me thing that you are suggesting a user be able to
essentially write a derived type and declare it to be, for example a
kind of real for some otherwise unused kind number.

That would certainly be nonstandard today in terms of the user code;
there isn't a syntax for such a thing and user codes are explicitly
forbidden from using REAL as a derived type name. As to whether a
compiler could implement such a thing as an extension (or
correspondingly, whether a future standard could add such an
extension)... hmm.

That would take quite a bit of thought to figure out whether I think it
is plausibly doable or not. Maybe. But I have my doubts that it would
be practical to do completely. Intrinsic types require an awful lot of
low-level support that I find it hard to see done without the compiler's
fairly close involvement. For example, literal constants. I could maybe
imagine schemes to handle literal constants at run-time by passing them
as a string to some user procedure. But some cases of literal constants
need to be evaluated at "compile time" (speaking sloppily here); that
complicates life.

I've tended to think more along the line of an alias that could be to
either an intrinsic type or a derived type. In fact, I was pushing for
that for a while in f2003, until it was pointed out to me that it
wouldn't achieve what I hoped (in particular because it wouldn't address
literal constants). So I'm not currently sure what approach to that
issue I most favor.

I'm presuming the issue here is that one wants something that is an
intrinsic type on compilers that support the required range and
precision, but can be easily switched to a suitable derived type on
compilers where a suitable intrinsic kind isn't available. A typical
example might be a 128-bit real - some compilers support them and others
don't.

--
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

David Flower

2005-05-24, 3:59 pm

To illustrate my thinking, consider the following statement:

INTEGER ( KIND=4) I

On most compilers, this is interpreted to mean that I is a 4-byte
signed INTEGER.

However, on Salford FTN95, it is interpreted as meaning that I is an
8-byte signed INTEGER.

So, why not a compiler option that states what:

INTEGER (KIND=42) I

means. After all, plenty of compilers have options that specify the
number of bytes occupied by default INTEGER.

Richard E Maine

2005-05-24, 4:00 pm

In article <1116950953.577721.209010@g49g2000cwa.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

> So, why not a compiler option that states what:
>
> INTEGER (KIND=42) I
>
> means. After all, plenty of compilers have options that specify the
> number of bytes occupied by default INTEGER.

That depends on what you mean by "means". :-)

There is a *HUGE* difference between the two possibilities

1. Just selecting between one of a small set of pre-defined meanings.
For example, presuming that the compiler already supports integers
of size 1, 2, 4, and 8 bytes, then specify that kind=42 maps to
one of those.

I would call that "selecting between predefined meanings" instead
of "defining the meaning".

This is comparable to the issue of "specifying the number of
bytes occupied by integer". In particular, I know of no
compilers that allow you to arbitrarily specify this. All I know
of is ones that allow you to select from a small set of
predefined possibilities.

2. Defining a meaning not pre-defined by the compiler. For example,
maybe you want kind=42 to mean a 10-byte integer and the compiler
doesn't happen to natively support such a thing.

Possibility 2 is a major matter.

Possibility 1 is relatively minor, but doesn't have much return either.
Code written to be portable shouldn't care what the specific kind values
are. I see no benefit to being able to specify that, for example,
kind=42 means 8-byte integers. Just use a named constant instead of a
literal one. That works now. If you want better ways to determine the
appropriate value for the named constant, then I agree, but that is
miniscule compared to trying to change things in the compiler innards.

The only case where I can see this as being worth the trouble is to
accommodate existing code that is written (against good advice) to
assume specific kind numbers. There are really only a small handful of
kind numbering schemes that you will see hardwired into code like that.
NAG already does allow you to select between the two most common. I see
no benefit to generalizing this so that users can hardwire arbitrary
nonstandard assumptions. Accommodating nonportable practices in existing
code is one thing. Going out of ones way to encourage new nonportable
variants is quite another. It might be different if there were actually
a real reason why it was useful to hardwire 42 as a kind number, but I
just don't see it.

--
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

Gary L. Scott

2005-05-25, 3:59 am

David Flower wrote:
> To illustrate my thinking, consider the following statement:
>
> INTEGER ( KIND=4) I
>
> On most compilers, this is interpreted to mean that I is a 4-byte
> signed INTEGER.
>
> However, on Salford FTN95, it is interpreted as meaning that I is an
> 8-byte signed INTEGER.
>
> So, why not a compiler option that states what:
>
> INTEGER (KIND=42) I
>
> means. After all, plenty of compilers have options that specify the
> number of bytes occupied by default INTEGER.
>
If I were to produce a Fortran compiler, I would make the kind value
represent the number of bits since 80-90 percent of my code requires bit
twiddling moving data back and forth between internal and externally
defined data types. That's more logical than number of bytes, I think.

--

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

David Flower

2005-05-25, 8:57 am

There is a problem with this: consider a one-byte INTEGER, supported by
many compilers; however, some consider it to be in the range (0,255)
whereas others use the range (-128,127). Specifying the number of bits
is therefore inadequate.

Anton Haumer

2005-05-25, 3:58 pm

David Flower schrieb:
>
> There is a problem with this: consider a one-byte INTEGER, supported by
> many compilers; however, some consider it to be in the range (0,255)
> whereas others use the range (-128,127). Specifying the number of bits
> is therefore inadequate.

compare C: signed / unsigned

Toni

Paul Van Delst

2005-05-25, 3:58 pm

. Are you advocating that unsigned integers be distinguished from regular old
signed integers in Fortran (should the former capability exist) via the kind mechanism? If
so, how does that fit in with the "KIND == # of bytes" specification that you also seem to
prefer.

To be clear, I'm not taking you to task... I'm just trying to figure out your point.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

David Flower

2005-05-25, 3:58 pm

Someone had suggested KIND=<number of bytes>, and I was pointing out
that that was insufficient. And some compilers do use unsigned one-byte
integers.

Charles Russell

2005-05-25, 8:57 pm

David Flower wrote:
> Someone had suggested KIND=<number of bytes>, and I was pointing out
> that that was insufficient. And some compilers do use unsigned one-byte
> integers.
>
To simplify portable handling of binary data, it would be nice to have
an unsigned 8-bit byte type guaranteed by the standard.

Richard E Maine

2005-05-25, 8:57 pm

In article <Wp6le.30473$J25.177@bignews6.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> To simplify portable handling of binary data, it would be nice to have
> an unsigned 8-bit byte type guaranteed by the standard.

I seriously doubt that you are going to get such a guarantee. Of course,
I could be wrong, but it would be a pretty significant change from
historical philosophy of the standard to require a specific size for
something so hardware-related as that. It would make Fortran essentially
unimplementable on many of the architectures that used to be quite
common. Not that I personally expect to see new architectures that
couldn't do an 8-bit type, but it would still seem quite unprecedented
for the Fortran standard to make such a thing as a hard requirement.

Now if you compromise on the word "guarantee", the odds might be much
better. The standard can make non-binding recommendations to facilitate
portability. An example is the recommendation in f2003 that the file
storage unit be an 8-bit octet (octet being standard-speak for it). Such
recommendations do serve as a push for vendors because a vendor that
fails to follow the recommendation is likely to have to justify that
failure to customers. But if the justification is sufficiently good to
convince the customers (this hardware can't do 8-bit things, and there
are good reasons for that....), then the vendor isn't stuck with being
unable to deliver a compiler that meets the standard.

There is a "BITS" proposal adopted at the last meeting that might fit
the bill (except for the "guaranteed" part). I haven't seen the version
of the proposal that was adopted, so I don't know its details, but it
was supposedly a modification of the "TYPELESS" proposal, which I have
seen. Speculation: perhaps the main mod might have been to change the
name from TYPLESS to BIT; I would personally think that to be a
significant improvement in the proposal and to more accurately reflect
what it does.

--
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

Gordon Sande

2005-05-25, 8:57 pm

Charles Russell wrote:
> David Flower wrote:
>
> To simplify portable handling of binary data, it would be nice to have
> an unsigned 8-bit byte type guaranteed by the standard.

Perhaps some variant on TRANSFER would do the job. UNSIGNED is an
obvious spelling for such an intrinsic.

Mixing unsigned variables in with an arithmetic oriented language
like Fortran would seem to be inviting confusion. Having to wrap
all the special values in an UNSIGNED intrinsic would make it rather
clear when the unsigned mode is in use. Defining how to mix UNSIGNED
with the arithmetic operators and logic intrinsics would take a fair
bit of effort.

It strikes me as in the same style as C interoperation. Vs. - critical
for those who need it but likely to leave many wondering what the fuss
is. And when used it is likely to be fairly localized. The bother is
that the various extensions are all over the map. BYTE, MEMORY as a
reserved identifier, PEEK and POKE intrinsics.

Gary L. Scott

2005-05-25, 8:57 pm

David Flower wrote:
> There is a problem with this: consider a one-byte INTEGER, supported by
> many compilers; however, some consider it to be in the range (0,255)
> whereas others use the range (-128,127). Specifying the number of bits
> is therefore inadequate.
>
That applies to any integer regardless of size. I always preferred an
attribute (actually lots of attributes) like:

integer, signed :: myint1
integer(b8), unsigned, lsb=2.54 :: myint2

or

integer, bits=8, signbit=32, lsb=1.0, scale=2.0 :: myint2

with default values...

--

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

Richard E Maine

2005-05-27, 4:01 pm

In article <jExle.35000$J25.25646@bignews6.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Richard E Maine wrote:
> It would make Fortran essentially
>
> I was under the impression that you could do it in software on any
> hardware, though perhaps inefficiently. If this imposed a burden on
> hardware vendors to make it efficient, there would be precedents. At
> one time it was asserted that the fortran language itself was unfairly
> biased in favor of IBM hardware.

Well, in the earliest days, it wasn't a standard at all, but a (small)
set of implementations, the first ones being on IBM hardware, so in
some sense that is a pretty safe statement. It isn't clear that all the
things that one hears are actually true (particularly when it comes to
subjective matters like "unfairly biased"). I was a bit young in '54 to
even be able to say "unfairly biased", so I've no first-hand data.

Of course, the first standards weren't started from scratch, so there
were almost bound to have been some elements of inheritance from early
implementations. How well the abstraction was done in the early
standards, I won't judge too much, though I'll note that it apparently
was done well enough so that there were quite a lot of implementations
on quite a lot of machines with, among other things, wide variation in
word sizes (not to speak of machines where the concept of a word was a
bit vague).

If it had been too tied to IBM hardware, we probably wouldn't be
discussing it right now. There are still lots of machines around that do
the old IBM floating point format, and Fortran even runs on them. But in
terms of Fortran, that's a pretty small niche today. (Some might
consider all of the Fortran market to be a niche - if so, that's a niche
of a niche).

Heck, at the moment, one might say that the Fortran standard is biased
against the old IBM floating point. There is a whole chapter ("clause"
in ISO-speak) on IEEE stuff that doesn't "fit". Sure that is all
optional, but I'd still call that a bias in that it looks bad if a
vendor has to say that they are omitting a whole chapter of the
standard, even if the standard itself allows that.

Oh, my "essentially" was to cover the case of "many things are possible
if you want to emulate the whole machine in software". I tossed it off
with a single word because I don't think it realistic. Yes, it can be
done. No, I don't think it is going to happen.

In my opinion, the odds of actually mandating an integer of exactly 8
bits are low. They clearly aren't zero, but I think they are low.
Indeed, in my personal opinion, an attempt to make it an absolute
mandate would be counterproductive to compromise on a recommendation.
Taking a "mandate or nothing" position would likely result in nothing.
(I'm not saying that you are taking such a position).

--
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

glen herrmannsfeldt

2005-05-27, 4:01 pm

Richard E Maine wrote:

(previously snipped question about a guaranteed unsigned eight bit
data type)

> In article <jExle.35000$J25.25646@bignews6.bellsouth.net>,
> Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

[color=darkred]

(see [*] below)
[color=darkred]
> Well, in the earliest days, it wasn't a standard at all, but a (small)
> set of implementations, the first ones being on IBM hardware, so in
> some sense that is a pretty safe statement. It isn't clear that all the
> things that one hears are actually true (particularly when it comes to
> subjective matters like "unfairly biased"). I was a bit young in '54 to
> even be able to say "unfairly biased", so I've no first-hand data.

The five digit statement numbers were 15 bits in early Fortran,
restricted to a maximum of 32767, but later increased. Though
the 704 had a 36 bit word, it seems that integers were still
limited to +/-32767. (It is a sign magnitude machine.)

(snip)

> If it had been too tied to IBM hardware, we probably wouldn't be
> discussing it right now. There are still lots of machines around that do
> the old IBM floating point format, and Fortran even runs on them. But in
> terms of Fortran, that's a pretty small niche today. (Some might
> consider all of the Fortran market to be a niche - if so, that's a niche
> of a niche).

As I understand it, VS Fortran is still the newest Fortran compiler
for IBM mainframe hardware. A newer compiler might implement the IEEE
floating point supported by newer hardware.

> Heck, at the moment, one might say that the Fortran standard is biased
> against the old IBM floating point. There is a whole chapter ("clause"
> in ISO-speak) on IEEE stuff that doesn't "fit". Sure that is all
> optional, but I'd still call that a bias in that it looks bad if a
> vendor has to say that they are omitting a whole chapter of the
> standard, even if the standard itself allows that.

> Oh, my "essentially" was to cover the case of "many things are possible
> if you want to emulate the whole machine in software". I tossed it off
> with a single word because I don't think it realistic. Yes, it can be
> done. No, I don't think it is going to happen.

That is what IBM started doing with Java, until IEEE floating point
was added. Java requires IEEE floating point.

> In my opinion, the odds of actually mandating an integer of exactly 8
> bits are low. They clearly aren't zero, but I think they are low.
> Indeed, in my personal opinion, an attempt to make it an absolute
> mandate would be counterproductive to compromise on a recommendation.
> Taking a "mandate or nothing" position would likely result in nothing.
> (I'm not saying that you are taking such a position).

Note that even C, often considered to be closer to the hardware, and
commonly used for implementing low level parts of operating systems,
such as device drivers, doesn't guarantee an 8 bit data type.
unsigned char is guaranteed to be at LEAST eight bits, but can
be more. I believe that there are some with a 64 bit unsigned char.

[*] There is an interesting problem that occurs when the word size
is not a multiple of eight bits. Consider reading and writing
magnetic tape, or almost any communication with the eight bit world.
There needs to be a way to write and read back the native word size,
and also to write and read back eight bit bytes. The PDP-10 could
write 36 bit words to tape, and read them back again. It could also
read and write eight bit bytes. I believe the I/O hardware had to
know which mode it was in. Text data is five ASCII characters
per 36 bit word.

-- glen

Charles Russell

2005-05-28, 3:58 pm

glen herrmannsfeldt wrote:

> Note that even C, often considered to be closer to the hardware, and
> commonly used for implementing low level parts of operating systems,
> such as device drivers, doesn't guarantee an 8 bit data type.
> unsigned char is guaranteed to be at LEAST eight bits, but can
> be more.

Is there no way then to read a binary file or binary stream in 8-bit
units? It would not so much matter if the byte was read into an
unsigned integer that could hold larger values, as long as the old 8-bit
code would still work. I'm surprised that C programmers don't call for
this in order not to break old code.

Richard Maine

2005-05-28, 8:57 pm

Charles Russell <SPAMworFREEwor@bellsouth.net> writes:

> glen herrmannsfeldt wrote:
>
>
> Is there no way then to read a binary file or binary stream in 8-bit
> units?

There is no way to do it on hardware that doesn't support such
things. Not that much hardware like that exists today.

> I'm surprised that C programmers don't
> call for this in order not to break old code.

They don't complain because, in point of fact, it works. Just because
something doesn't have an "ironclad guarantee" in the standard doesn't
mean that it can't work. And I quote the "ironclad guarantee" part
because, standard or no, if the hardware actually doesn't support it,
then it isn't going to happen. Important as I think standards are,
they aren't everything. I think you are making far too big an issue
out of the issue of a guarantee.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Charles Russell

2005-05-29, 3:57 pm

Richard Maine wrote:
Important as I think standards are,
> they aren't everything. I think you are making far too big an issue
> out of the issue of a guarantee.

Isn't the purpose of a standard to guarantee portability? Though the
notion of portability can vary from "I can adapt my code to market it on
any platform" to "I can run my code unmodified on any box where I can
scrounge a user account, now or in the future."

Richard E Maine

2005-05-29, 3:57 pm

In article <KVlme.42956$CR5.27700@bignews1.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Richard Maine wrote:
> Important as I think standards are,
>
> Isn't the purpose of a standard to guarantee portability?

No. The purpose of a standard is to facilitate portability. There is a
*HUGE* difference, which is exactly my point.

A standard can't guarantee portability. It can't guarantee that
hardware support exists at all. Nor can a voluntary standard guarantee
that it will be followed.

A standard that requires impractical things will, in my opinion,
be detrimental to portability because it will just result in
acceptance of nonconformance to the standard.

--
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

glen herrmannsfeldt

2005-05-31, 9:09 am

Charles Russell wrote:
> glen herrmannsfeldt wrote:
>
[color=darkred]
> Is there no way then to read a binary file or binary stream in 8-bit
> units? It would not so much matter if the byte was read into an
> unsigned integer that could hold larger values, as long as the old 8-bit
> code would still work. I'm surprised that C programmers don't call for
> this in order not to break old code.

For a C implementation with a byte oriented file system, I would still
expect single characters to be stored in a char variable, independent
of the number of bits allocated to that variable.

In Fortran 66 the only standard way to work with characters was to store
them one per INTEGER variable, and read and write them with A1 FORMAT.
Inefficient use of memory, but it worked pretty reliably.

But you asked about binary files, not text files. C allows different
treatment for binary and text files. The expectation is that if you
write something out in binary mode, and read it back in you will get the
same value, independent of the bits/char or the file system. Consider,
though, a file system without an 8 bit unit? For the PDP-10/TOPS-10
system, which there may actually be a C compiler for, the processor and
file system store 36 bit words. Text files store five ASCII characters
per word, with one bit left over. For binary files there must be a way
to read/write 36 bit words, and also to read/write byte oriented data,
such as 9 track tape.

-- glen

Sponsored Links