Meanwhile, Ada has Interfaces.Fortran for actually interfacing with the language and doing it correctly. Fools will tell you C is the backbone of civilization and everything interfaces with it, but this is yet another example of how they're wrong.
So Programmer/s have written function prototypes for the Fortran functions, but they have omitted the length parameter in that prototype. That is the reason behind this. It should have never worked to begin with but the way it was handled on the FORTRAN side things meant for single length strings it did not crash. GCC probably could have just made the change they wanted, but they don't want to break existing code right away that is technically already broken.
It boils down to some programmer/s doing the following.
int foo(char str);
instead of
int foo(char str, int len); // The correct prototype.
The prototype is you saying there is a function that exists with this name, return type and parameters. The compiler will then construct calls with what you have defined as the function prototype. Then when linking the linker just looks at the name of the called function and replaces it with the address/memory position of the function.
That's always the excuse with C, I know.
>The same thing would happen in most languages if a programmer declared their FFI incorrectly.
If the Ada Interfaces.Fortran didn't work, that would be a compiler issue, but that's only because Ada does things right.
>It boils down to some programmer/s doing the following.
I read the article, you know.
Is that a language problem with ada? That's all the C programmers did here.
I wouldn't know how GNAT behaves in this case, but I figure it would at the least be much harder to do by mistake, as has been done with C for years.
>Instead of using the Fortran_Character type defined in Interfaces.Fortran you could just define your own that does not follow Fortran's string calling convention.
The Ada compiler is aware of what's being done when you interface with another language. You must tell it how the procedure is from a different language and you're also able to specify the representation of Ada data types to conform. I wouldn't be surprised to learn that GNAT is capable of checking on the Fortran side of things as well, for interfacing like this.
>Is that a language problem with ada? That's all the C programmers did here.
I don't believe Ada has this issue, but I'd wager it at the least makes it harder to make. In any case, I have no personal experience interfacing Ada with Fortran.
My point, however, is that this is a very common issue with C programming, where people don't know what they're doing and things break constantly. The C language is not designed for interfacing with other languages, in part because it wasn't designed much at all.