Quote:Edoapra Jan 20th 5:56 pm
I am not sure I am following you. On LP64 we use the Integer = long trick for the Fortran to C interface since we do use 64-bit integers in Fortran on LP64 (by using the -i8 compiler options). I do not see any int appearing in this sequence
src/c/pdspev_c.c: reduce_maps( *n, mapA, *n, mapZ, 0, mapZ, &nn_proc, proclist );
^
this is int
Conversion from (literal of type int, according to clause 6.4.4.1) to (long) is not one of the "integer promotions" (clause 6.3.1.1) and will not occur automatically when there is no prototype for the function being called (clause 6.5.2.2)
That last clause contains the following rule
Quote: If the function is defined with a type that does not include a prototype, and the types of
the arguments after promotion are not compatible with those of the parameters after
promotion, the behavior is undefined
The type of the indicated argument after promotion is "int", the type of the parameter is "typedef long Integer", and the result is undefined behavior.
That undefined behavior manifested as the caller writing four bytes and the callee reading eight, including garbage. Since that parameter controls pointer arithmetic, a segmentation fault resulted.
Note that on my system the parameters were eight byte aligned, so the caller reserved four padding bytes for alignment purposes, and the remaining arguments were at the expected location. A platform using four byte alignment would cause the location of the other arguments to be shifted, in addition to corruption of the argument passed as literal 0.
This affects a number of files in peigs, as shown in my first post (all those function calls that have a literal zero argument are broken).
|