[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

["emr-gnu at hev dot psu.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322

--- Comment #2 from Eric Reischer <emr-gnu at hev dot psu.edu> ---
I can't point to a specific standard that says, "thou shalt generate output
with these types..."; it's more of a "we probably should be doing this"-type
thing.  If you are compiling Fortran and C on the same system with the same
compiler suite, this is a non-issue.  However, if you are, say, creating an API
that has autogenerated files redistributed (e.g., a base Fortran package and
then autogenerated and distributed C/C++ header files), the types generated
using -fc-prototypes are not safely transportable to another compiler with the
requested variable sizes.

This is probably better demonstrated with another example:

Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
E", you get the following output:

> gfortran -m32 -fc-prototypes -fsyntax-only foo.f90

 long a;
 {...}
 long_long e;
} bar;

-------

In the above, "long_long" is nonstandard and not recognized by most compilers
(it was apparently implemented in some locations as a workaround to a problem
on Windows with gcc compatibility).

What's worse, is if you run the above in 64-bit mode on x86 Linux, you get:

> gfortran -m64 -fc-prototypes -fsyntax-only foo.f90
 long a;
 {...}
 long e;
} bar;

-------

This is most definitely wrong -- "long" will be 64 bits on Linux, but only 32
bits on Windows, so the size type emitted is ambiguous.  Additionally, the
structures will no longer be interoperable, because (again, on Windows) in
C/C++ you'll get a variable "E" that will only store 32 bits, whereas in
Fortran the corresponding variable will be 64 bits, thus offsetting every
variable that comes after it. Probably better to be safe (and definitely more
portable) to leave translation of the types to when the C/C++ files are
actually compiled (which may not be with gcc) by using the stdint.h types.

I will stipulate that, yes, int64_t is not *guaranteed* to be exactly 64 bits,
and size_t is not *guaranteed* to be 32 or 64 bits (based on what architecture
you're running).  But preserving the explicitly-specified data types across the
language translation is the point here.  An entirely separate argument could be
had for INTEGER*4, INTEGER*8, etc., but in this case, since you're explicitly
requesting C_INTxx_T, you're getting something else entirely out of the
prototype-generation subsystem.