<html>
    <head>
      <base href="http://bugzilla.gdcproject.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Setting Tsize_t, Tptrdiff_t in d-target.cc is not working"
   href="http://bugzilla.gdcproject.org/show_bug.cgi?id=167#c4">Comment # 4</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Setting Tsize_t, Tptrdiff_t in d-target.cc is not working"
   href="http://bugzilla.gdcproject.org/show_bug.cgi?id=167">bug 167</a>
              from <span class="vcard"><a class="email" href="mailto:ibuclaw@gdcproject.org" title="Iain Buclaw <ibuclaw@gdcproject.org>"> <span class="fn">Iain Buclaw</span></a>
</span></b>
        <pre>(In reply to Johannes Pfau from <a href="show_bug.cgi?id=167#c3">comment #3</a>)
<span class="quote">> Yes, I hit this issue with 8bit AVRs (pointers/size_t is 16 bit on AVR
> although registers are 8bit). Maybe a clean solution is to split
> Target::init / Target::init2 and use Target::sizetsize in Type::init?
> However, overwriting Type::tsize_t seems to work for now.
> </span >

Adding more inits won't help.  Moving the isLP64 logic (and subsequent setting
of Type::tsize/tptrdiff would.


<span class="quote">> A related question: in d-codegen.cc::build_offset
> tree ofs = fold_convert (Type::tsize_t->toCtype(), byte_offset);

> shouldn't this use tptrdiff_t? I think this code could break if wordsize and
> pointer size are different.
> However, simply changing this to tptrdiff_t breaks the build. I guess we'd
> really need a unsigned tptrdiff_t.</span >

Yah, there has been an agreement for quite some time now that size_t/ptrdiff_t
types don't really mean their C equivalents in the truest sense.  Both should
be the same size.  So if in doubt, just use POINTER_SIZE to determine the
correct size_t/ptrdiff_t type in D.

We still have __builtin_machine_[u]int and __builtin_pointer_[u]int for C ABI
reasons.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>