Re: Strange Porting Problem CVF to IVF, requesting help and ideas.

David Flower <DavJFlower@xxxxxxx> wrote:

Surprisingly,
LOC, despite having its origins early in the history of the language,
is not standard, but most compilers support it.

I'm surprised that you are suprised at this not being in the standard.
But then, it is probably a different perspective. You have to understand
(well, you certainly don't "have" to, but if you don't, then many, many
things in the standard will be a mystery to you) the architecture
neutrality of the language standard.

The LOC function inherently involves a major assumption about
archtecture. It is an assumption that is false for many architectures,
both past and present (and likely future). The Fortran standard has a
long and consistent history of avoiding such architecture-dependent
assumptions. (So do many other language standards, although Fortran is
more architecturally neutral than most. Even the C standard doesn't say
nearly as much about architecture as most of its day-to-day users think
it does.)

In particular, LOC returns an integer. I might add that it is an integer
of default size, although early standard Fortran only acknowledged a
single size of integer (and only a single size was available on some
important architectures, speaking of architectural neutrality). The
architectural assumption involved is that an address can be stored in an
integer. There have been many architecures where this is not so. One
common example from the past was in the segmented addresses of some
systems running on the x86 family; it took two integers to store an
address. An example from today is so-called 64-bit systems, where
addresses take 64 bits, but default Fortran integers are still 32 bits.

I might add that there is major user resistance to changing default data
sizes to 64 bits on "64-bit systems". There is too much code that thsi
would break. True, such code is making assumptions not guaranteed by the
standard, but that doesn't change the fact that the code exists - lots
of it. There was a time when I personally thought that we would
graadually transition to default integers commonly being 64 bits, at
least on systems large enough to have 64-bit address spaces. This would
have simplified some things by quite a bit. But I realize now (and have
for quite a few years) that the huge amount of code that this would
break is going to at least majorly delay such a transition, and possibly
essentially stop it, instead getting people used to using non-default
sizes where they are needed.

Note that the F2003 C interop stuff includes a feature that has the
important functionality of LOC. This new feature is the function C_LOC.
In spite of the "C_" part of the name, this feature can be used even in
contexts that have nothing to do with C, and I expect such uses to
become common because there is useful functionality here. The
fundamental difference between C_LOC and the old nonstandard LOC is that
C_LOC returns a result of a special type (C_PTR) instead of an integer.
This allows C_LOC to be used in a way that is far more portable across
architectures than the old nonstandard LOC.

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

Relevant Pages

  • Re: isodigit
    ... There are some sign-magnitude DSPs, for example, ... much ignored rather than carefully designed into the language. ... computer architectures. ... the Standard C language; generally, ...
    (comp.std.c)
  • Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
    ... > the language, they type something into their interpreter. ... No it doesn't serve as a "standard", ... > thing that could happen to Python is an ANSI standard. ... architectures for 5 or 10 years- maybe longer depending on circumstance. ...
    (comp.lang.lisp)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: subroutine stack and C machine model
    ... They could have standardized that the language would be ... getting the facts wrong anyway. ... And the answer, for the Schildt books, is that they consistently produced ... to C start with the standard. ...
    (comp.lang.c)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)