Re: ISO_C_BINDING and arrays, optional arguments, etc.

<nmm1@xxxxxxxxx> wrote in message news:iigsjl$fol$1@xxxxxxxxxxxxxxxxxxxxxxx

In article <iiggi0$5qf$1@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
FX <coudert@xxxxxxxxxxxxx> wrote:

Never do this, because no Fortran variable type is interoperable with
_Bool.

Would you care to back this affirmation up? Simple tests show that it
works nicely:

In trivial cases only. If you read the standards more carefully,
you will discover that they are semantically incompatible. Yes,
I know what can be done safely, but I would hate to teach it to
anyone without extensive Fortran, C and interoperability (and
preferably implementation) experience.

Last couple of threads where I drew up some examples I just got
yelled at. In the case of gcc, the C compiler considers zero to
be .FALSE. and everything else to be .TRUE., but the Fortran
compiler considers zero to be .FALSE., one to be .TRUE., and
intentionally abuses you if you put any other value into a LOGICAL
variable. Thus code that read an _Bool value and tells the
Fortran compiler that it's a LOGICAL(C_BOOL) variable may encounter
any kind of mayhem when the optimizer starts composing syllogisms.
On the other hand, reading an _Bool value as an INTEGER(C_INT8_T)
and then testing whether it's nonzero will be safe in gcc. The
way to fix this is for the C compiler to to consider the LSB of
an _Bool variable to be the only significant bit, as the standard
allows, and then to follow suit with the Fortran compiler, but it's
so ingrained in the mindset of the C programmer that zero is .FALSE.
and everything else is .TRUE. that this situation will never happen
no matter how error-prone it is. Time for the yelling, I suppose.
But if you do that I will just have to put another Yes album on
and turn the volume way up so that I can't hear you any more.

A lot of the Fortran interoperability section is a serious error,
because it does not have well-defined properties.

Could you be kind enough to point out maybe a couple of the most
glaring cases?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.

Relevant Pages

  • Re: binary data
    ... C compiler considered only the low bit of an _Bool to contribute ... The logical operators accept zero not zero ... compiler gives the required results for standard conforming code, ...
    (comp.lang.fortran)
  • Re: binary data
    ... the compiler is not necessarily the case. ... C compiler considered only the low bit of an _Bool to contribute ... (That's independent whether you support integer expressions in logical expressions; the implementation itself then depends on this choice.) ... so any Fortran compiler that permits mixing of real ...
    (comp.lang.fortran)
  • Re: Exposing bool to non-MS, non-C++ callers
    ... Am I guaranteed that C++ will interpret a bool as "zero is false and non-zero is true"? ... If the caller supplies the value 3 for my bool variable, will "myVar = false" return true or false? ... The 'bool' has a specific (compiler defined) data type that should only accept a 'true' or 'false' in the C++ world. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: D3/Linux compile question
    ... consider zero a valid array element while the Prime flavors do. ... 02 EQUATE ZERO TO ARRAY ... 07 CRT ARRAY ... Compiler catches line 6 and 13 as subscript out of range. ...
    (comp.databases.pick)
  • Re: bool or BOOL in MFC projects
    ... Also, in the PDP-11 compiler, which was a real piece of trash, if you wrote ... learned it on the PDP-11 and never unlearned all the bad habits they developed. ... so every function implicity returned int. ... bool or BOOL in MFC projects ...
    (microsoft.public.vc.mfc)