Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1240816

fp.bugs 3876 javah generates long return value in stub even if return is short


    • Subcomponent:
    • CPU:
    • OS:


      From: ###@###.### (Steve Schoettler)
      This does not look like form output to me.

      Summary: javah generates long return value in stub file even if return value
      is short
      Result: the java program gets garbage data back from the native method
      Workaround: edit the stub file to change long to short, or change the java
      declaration so the native method returns int
      Platform: Windows NT 3.51/Intel, using JDK 1.0, and the Visual C++ 4.0 tools.

      If the java source says
        public native short getType()

      The javah generated .h file says:
        _declspec(dllexport) short H..._getType(...)

      The javah generated .c stub file says:
        extern long H..._getType(...)

      If the native C implementation of the getType function is defined
        long H..._getType(...)
      then you get a linker error (functions differ by only return type)

      If the native C implementation is defined
        short H..._getType(...)
      then there are no compile or link errors, but the java program doesn't
      return the correct value.

      If you hand-edit the javah-generated .c stub file to say
        extern short H..._getType(...)
      and recompile then everything works fine.

      So, I looked in src/win32/java/main/javah.c, version 1.19, and sure enough
      there's a big switch statement that combines a bunch of types and outputs
      "extern long" (line 760) into the .c stub file, whereas the .h file
      generating code has a specific case for short (line 212). I could see how
      this might be a problem for little-endian machines like Intel and not for
      other platforms.

      This could be a bug for some of the other types in the switch statement
      (boolean, byte, short, char), but I haven't tested those.

      Steve Schoettler
      B Mobile


          Issue Links



              • Assignee:
                apalanissunw Anand Palaniswamy (Inactive)
                bhagen Benjamin Hagen (Inactive)
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: