<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 1/15/2013 11:02 AM, harold seigel
      wrote:<br>
    </div>
    <blockquote cite="mid:50F5A7B3.1010002@oracle.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      Hi,<br>
      <br>
      Thank you for the comments.  I think there are two remaining minor
      issues.  Let me know if I missed anything.<br>
      <br>
      1. Use int64_t, instead of long, to define jlong?<br>
      <blockquote>I prefer using 'long' to define 'jlong', rather than
        'int64_t', because 'long' is a predefined C++ language type. 
        Type 'int64_t' is a Unix operating system defined type.  This
        would unnecessarily complicate things.  For example, defining
        'jlong' as 'int64_t' would require moving the definition of
        'jlong' from src/cpu/x86/vm/jni_x86.h to files in the
        src/os_cpu/ directories.<br>
        <br>
        Would it be useful to file a new bug to investigate using
        'int64_t' to define 'jlong' ?<br>
      </blockquote>
    </blockquote>
    <br>
    int64_t is part of the c99 standard, so it's not really an operating
    system defined type per se, but I believe you're right in the sense
    that it's not available in any of the standard header files on
    Windows. But as I said I don't really have a problem defining jlong
    based on long/long long if that's easier.<br>
    <br>
    I do think it'd be a useful exercise to see what it would take to
    use int64_t to define jlong, but I'm fine with doing it as a
    separate project.<br>
    <br>
    <blockquote cite="mid:50F5A7B3.1010002@oracle.com" type="cite">
      <blockquote> </blockquote>
      2. Define 32-bit and 64-bit variants of JLONG_FORMAT in
      src/os/posix/launcher/java_md.h ?<br>
      <blockquote> Would it be better to define JLONG_FORMAT as %lld for
        32-bit and %ld for 64-bit for the posix variant, in file
        java_md.h?  I'm unclear what the Windows variant of "%I64d"
        would be.<br>
      </blockquote>
    </blockquote>
    <br>
    Maybe I'm missing something, but I'd say we should define jlong to
    be the exact same (derived) type as int64_t, and JLONG_FORMAT should
    be exactly the same as INT64_FORMAT/PRId64. For all the posix
    platforms I think that should be trivial, and I'd even argue that
    the easiest way to do it would be to use int64_t/PRId64 directly
    assuming all the posix platforms we support have
    stdint.h/inttypes.h. For Windows, judging from
    globalDefinitions_visCPP.hpp, it looks like "signed __int64" and
    "%I64d" is the way to go regardless of 32/64. Does that make sense?<br>
    <br>
    Cheers,<br>
    Mikael<br>
    <br>
    <blockquote cite="mid:50F5A7B3.1010002@oracle.com" type="cite">
      <blockquote> </blockquote>
      Thanks, Harold<br>
      <br>
      On 1/14/2013 2:10 PM, Mikael Vidstedt wrote:
      <blockquote cite="mid:50F4583C.8010004@oracle.com" type="cite">On
        2013-01-12 15:05, David Holmes wrote: <br>
        <blockquote type="cite">Sorry Harold I didn't see this before my
          other reply. Now I understand your problem. We either have to:
          <br>
          <br>
          a) typedef long long jlong on all platforms; or <br>
          b) special case the typedef for jlong on Apple; or <br>
          c) special case the typedef for JLONG_FORMAT on Apple <br>
          <br>
          But even if we do (a) any platform that defines int64_t
          differently to our jlong will mean we still need distinct
          format specifiers. Further unless we know how int64_t is
          defined on a given platform we don't know what format
          specifier to use (%ld or %lld). <br>
          <br>
          Do compilers that provide things like int64_t also define a
          format specifier macro? <br>
        </blockquote>
        <br>
        It's part of the C99 standard (not sure about c++) - the types
        have corresponding format specifier macros called PRI*, defined
        in inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used
        to print the int64_t/uint64_t equivalents of %d, %u and %x
        respectively. Our own internal format macros (SIZE_FORMAT,
        INTPTR_FORMAT etc) are defined as derivatives of these. <br>
        <br>
        In general "long" tends to be a mess... :( <br>
        <br>
        /Mikael <br>
        <br>
        <blockquote type="cite"> <br>
          David <br>
          ----- <br>
          <br>
          On 12/01/2013 12:36 AM, harold seigel wrote: <br>
          <blockquote type="cite">Hi Vladimir, <br>
            <br>
            Thank you for your comments.  Mac OS defines int64_t as
            'long long'. <br>
            So, int64_t needs a different format specifier than jlong,
            which this <br>
            fix now defines as 'long'.  This is because, as shown below,
            the Mac OS <br>
            C++ compiler is picky about format specifiers for values of
            types 'long <br>
            long' and 'long'. <br>
            <br>
                $ gcc lld.cpp <br>
                lld.cpp: In function int main(int, char**): <br>
                lld.cpp:8: warning: format %lld expects type long long
            int, but <br>
                argument 2 has type long int <br>
                lld.cpp:9: warning: format %ld expects type long int,
            but argument 2 <br>
                has type int64_t <br>
            <br>
                $ cat lld.cpp <br>
                #include &lt;stdio.h&gt; <br>
                #include &lt;stdint.h&gt; <br>
            <br>
                int main(int argc, char * argv[]) { <br>
                   long long_val = 5; <br>
                   int64_t int64_val = 8; <br>
                   printf("long_val: %ld\n", long_val); <br>
                   printf("long_val: %lld\n", long_val); &lt;---- Line 8
            <br>
                   printf("int64_val: %ld\n", int64_val); &lt;--- Line 9
            <br>
                   printf("int64_val: %lld\n", int64_val); <br>
                   return 0; <br>
                } <br>
            <br>
            That is why I added JLONG_FORMAT. <br>
            <br>
            Thanks, Harold <br>
            <br>
            On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: <br>
            <blockquote type="cite">Can we just define INT64_FORMAT as
              platform specific and use it <br>
              instead of adding new JLONG_FORMAT? <br>
              <br>
              Thanks, <br>
              Vladimir <br>
              <br>
              On 1/10/13 10:39 AM, harold seigel wrote: <br>
              <blockquote type="cite">Hi, <br>
                <br>
                Please review the following changes to fix bug 7102489.
                <br>
                <br>
                Summary: <br>
                The definition of type jlong differed on Mac OS from the
                other 64 bit <br>
                platforms.  This fix makes it consistent.  In order to
                do this, this fix <br>
                defines new macros, JLONG_FORMAT and JULONG_FORMAT, for
                printing and <br>
                scanning jlongs and julongs. <br>
                <br>
                This fix also does some cleanup.  Methods
                jlong_format_specifier() and <br>
                julong_format_specifer() were removed and some format
                specifiers were <br>
                replaced with appropriate macros. <br>
                <br>
                Open webrev at <a moz-do-not-send="true"
                  class="moz-txt-link-freetext"
                  href="http://cr.openjdk.java.net/%7Ehseigel/bug_7102489/">http://cr.openjdk.java.net/~hseigel/bug_7102489/</a>
                <br>
                <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://cr.openjdk.java.net/%7Ehseigel/bug_7102489/">&lt;http://cr.openjdk.java.net/%7Ehseigel/bug_7102489/&gt;</a>
                <br>
                Bug link at <a moz-do-not-send="true"
                  class="moz-txt-link-freetext"
                  href="http://bugs.sun.com/view_bug.do?bug_id=7102489">http://bugs.sun.com/view_bug.do?bug_id=7102489</a>
                <br>
                <br>
                Thank you, <br>
                Harold <br>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>