<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Some replies inline:</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 06/09/2022 15:08, Manuel
      Bleichenbacher wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAA7F5jKb2H=D0dDa2EuDSzg4wb6Qm4TGpFpzJNbskxf1--rdtw@mail.gmail.com">
      
      <div dir="ltr">
        <div>I think there are only a few cases:</div>
        <div><br>
        </div>
        <div>
          <div>Case 1: extern int i;</div>
          <div>It is a declaration and should generate the lookup for a
            symbol "i" (plus a method to get the value). It is already
            implemented like this.<br>
          </div>
        </div>
      </div>
    </blockquote>
    I agree this is the most idiomatic way to do things.<br>
    <blockquote type="cite" cite="mid:CAA7F5jKb2H=D0dDa2EuDSzg4wb6Qm4TGpFpzJNbskxf1--rdtw@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          Case 2: int i = 4;</div>
        <div>It can be skipped as it never appears in a header file that
          can be consumed by multiple compilation units (as it would
          generate an error). It's simply not relevant for jextract,
          which generates code to access an existing library.<br>
        </div>
        <div><br>
        </div>
        <div>Case 3: int i;</div>
        <div>It is the same as case 2 (implicitly initializes to 0).</div>
      </div>
    </blockquote>
    <p>I also agree that these two seem suspicious. While in a
      standalone application, an header containg symbols like these
      might make sense, in a library, this most likely does not make any
      sense, as it will create storage in all clients importing the
      headerfile.</p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CAA7F5jKb2H=D0dDa2EuDSzg4wb6Qm4TGpFpzJNbskxf1--rdtw@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        Case 4: int __declspec(selectany) i = 4;<br>
        <div>This is a special case *and most likely Microsoft
          specific). In theory, the behavior could be replicated, i.e. a
          variable or constant is allocated in native memory and
          properly initialized. Since it's a rare case, I'd rather skip
          it.</div>
      </div>
    </blockquote>
    <p>Yes, this seems to be special and unique to Windows. But, I'd
      rather gate on presence of "extern", than to obscure __declspec.</p>
    <p><br>
    </p>
    <br>
    <blockquote type="cite" cite="mid:CAA7F5jKb2H=D0dDa2EuDSzg4wb6Qm4TGpFpzJNbskxf1--rdtw@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Case 5: static int i = 4;</div>
        <div>It is a mixture between case 2 and 4. It's unlikely to
          appear in header files although it does not generate an error.
          The behavior could be replicated but I would spend time on
          more important things and skip it for now.</div>
        <div><br>
        </div>
        <div>Case 6: static int i;</div>
        <div>It is the same as case 5 (implicitly initializes to 0).<br>
        </div>
      </div>
    </blockquote>
    <p>These seem easier, since declaration says "static".</p>
    <p><br>
    </p>
    <p>It seems to me that all this boil to two rules:<br>
    </p>
    <p>* we should only generate global var accessor for "extern"
      variables<br>
      * we should skip static symbols (this is covered by [1])</p>
    <p>Maurizio</p>
    <p>[1] - <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract/pull/70">https://github.com/openjdk/jextract/pull/70</a><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CAA7F5jKb2H=D0dDa2EuDSzg4wb6Qm4TGpFpzJNbskxf1--rdtw@mail.gmail.com"><br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 3:29 PM
          Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <p>Hi,<br>
              I think there's more to it.</p>
            <p>On Linux, if I do the following:</p>
            <p>```<br>
              $ cat foo.h<br>
              int i = 4;<br>
              ```<br>
            </p>
            <p>and:</p>
            <p>```<br>
              $ cat foo.c<br>
              #include "foo.h"<br>
              ```<br>
            </p>
            <p>And then I compile into a shared lib, the obtained foo.so
              does have a symbol for "i" (rightfully so):<br>
            </p>
            <p>```<br>
              $ objdump -T foo.so<br>
              <br>
              foo.so:     file format elf64-x86-64<br>
              <br>
              DYNAMIC SYMBOL TABLE:<br>
              0000000000000000  w   D  *UND*    0000000000000000
              __cxa_finalize<br>
              0000000000000000  w   D  *UND*    0000000000000000
              _ITM_registerTMCloneTable<br>
              0000000000000000  w   D  *UND*    0000000000000000
              _ITM_deregisterTMCloneTable<br>
              0000000000000000  w   D  *UND*    0000000000000000
              __gmon_start__<br>
              0000000000004020 g    DO .data    0000000000000004 i<br>
              <br>
              ```</p>
            <p>E.g. the above header contains a *definition*, so the
              compiler will create storage for it (and add it to the
              shared library), and "i" can be looked up in the shared
              lib. Conversely, a global marked as "extern" might or
              might not be present in the shared library (depending on
              whether it's defined in one of the associated C/CPP
              files).<br>
            </p>
            <p>Maurizio<br>
            </p>
            <p><br>
            </p>
            <div>On 06/09/2022 13:57, Manuel Bleichenbacher wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div>There are two indications that it's definition and
                  not a declaration:</div>
                <div><br>
                </div>
                <div>- absence of "extern" keyword</div>
                <div>- presence of initialization ( = { 0x... )</div>
                <div><br>
                </div>
                <div>If it was compiled as C/C++ code, it would allocate
                  memory in the current compilation unit while a
                  declaration would just refer to something outside the
                  compilation unit.</div>
                <div><br>
                </div>
                <div>Definitions are rare in header files as they
                  usually lead to duplicate symbol errors at link time.
                  But through the magic of __declspec(selectany), this
                  is avoided. </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at
                  12:11 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
                  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex"><br>
                  On 05/09/2022 16:32, Manuel Bleichenbacher wrote:<br>
                  > extern "C" const GUID __declspec(selectany)
                  GUID_DEVINTERFACE_USB_DEVICE<br>
                  >     = { 0xA5DCBF10L, 0x6530, 0x11D2, { 0x90,
                  0x1F,  0x00,  0xC0, <br>
                  >  0x4F,  0xB9,  0x51,  0xED } };<br>
                  ><br>
                  I guess the problem here is the lack of "dllexport",
                  right?<br>
                  <br>
                  But, while dllexport is common, some libraries can
                  still export symbols <br>
                  using a .def file [1].<br>
                  <br>
                  So, I'm not sure this belongs in the same category as
                  "static inline", <br>
                  as it is not possible, just by looking at the header,
                  to understand <br>
                  whether the symbol will be present or not?<br>
                  <br>
                  [1] - <br>
                  <a href="https://urldefense.com/v3/__https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=msvc-170__;!!ACWV5N9M2RV99hQ!IZ9OZ1GPWyZCLxdiYrnGJewYmhC_BCpH8sxH4Lo2jBtSsuMJPH_j3-vIXRO1emIKo2SMrT3Sj1AqI3daPLx2VOq6oGrpPgb-Xw$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=msvc-170</a><br>
                  <br>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>