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

Walter Spector <w6ws_xthisoutx@xxxxxxxxxxxxx> wrote:

IMO, the Standard should have a KIND available, perhaps residing in
ISO_FORTRAN_ENV, which represents an integer capable of holding the
SIZE of the largest array the implementation supports. (Kinda like
size_t in C.) Same for character string length. Then the intrinsics
should be defined to return results in terms of these types/kinds.

There would be no compatibility issues that I can see. Just programs
that used to be broken would suddenly start working...

And programs that used to work would suddenly be broken. Yes, there are
compatibility issues. You can't just change things like that without
invariably hitting them. My off-hand guess is that the number of working
programs that would break would exceed the number of broken programs
that would start working.

Trivial example

call my_sub (something, size(something))

Of course, my_sub expects a default integer for its second argument.
make it an external procedure with an explicit interface to minimize the
odds of the compiler catching the problem. And, of course, the
application in question doesn't use huge arrays, so it is working just
fine now with 32-bit default integers.

This isn't even an arcane made-up example to illustrate the point.
That's a common programming paradigm. *LOTS* of code does it.

I'm afraid I don't know a good and simple solution. I once thought that
having default integers go to 64 bits would do it. But, as I mentioned
in my previous post, that doesn't seem likely to happen - at least not
rapidly. There is no bar to it in terms of the standard - just in terms
of existing user code that makes nonstandard assumptions. But that
existing code is still a real issue to deal with; it cannot be just
ignored. You proposed fix breaks even existing code that is perfectly
standard conforming.

--
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: For performance, write it in OCaml
    ... Eliminated a "not" in a loop by replacing the array of booleans ... compatibility. ...
    (comp.lang.ruby)
  • Re: Mass delete files and directories
    ... If you look at the code I originally posted you'll see that I have used a Long at that position in the UDT and it works fine here on both my machines, but you said that it does not work on one of your four customer machines, and you also said that you had tried both Boolean and Long at that position with the same result. ... You will still have problems if you try to use any of the three remaining items in the UDT though (the three items immediately following fFlags) because they are two Longs and a String pointer and VB will "pad" the fFlags integer with two padding bytes so that the first of those Longs starts on a LongWord boundary. ... if you plan to use any of those last three entries in the UDT then you would be better off replacing all three of them with a byte array ... He changed the compatibility back to Win98/ME and it ran flawlessly. ...
    (microsoft.public.vb.general.discussion)
  • Re: For performance, write it in OCaml
    ... Eliminated a "not" in a loop by replacing the array of booleans ... compatibility. ... You can make it slightly faster by factoring out the CSE "compatible ...
    (comp.lang.ruby)
  • Re: new/ resize
    ... > Why does the need to resize an array mean that it is no longer neccessary to ... I still believe that quality and robustness is top priority especially ... Don't get me wrong, compatibility is an issue. ... C++ Faq: http://www.parashift.com/c++-faq-lite ...
    (comp.lang.cpp)