<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 28, 2013 at 12:40 PM, Pavel Levshin <span dir="ltr"><<a href="mailto:pavel@levshin.spb.ru" target="_blank">pavel@levshin.spb.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="gmail_quote">28.11.2013 15:19, Rainer Gerhards
      <div class="im"><blockquote type="cite"><br>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          For external interface, I'd vote for size_t.
          <div>
            <div><br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Yeah, I know this problem for many years. I've been totally
          fine with size_t when we moved vom 16 to 32 bits. With 64
          bits, I have a bit of concern as general use in cases like
          this. Thinking performance wise-manipulating 64 bits requires
          a lot of space in registers and cache lines. Especially when
          we know we will never have string that long (can you envision
          a 4GB syslog message that is run through lognorm -me not...).
          But I agree that the "clean" solution would is size_t --- I am
          undecided myself... <br>
          <br>
        </div>
        Can you give me a good argument (besides standards) why size_t
        would be good here? Or better said: does not hurt.<br>
        <br>
      </blockquote>
      <br></div>
      I can think only of going back to 16 and 8 bits. Sometimes, I'm
      working with microcontrollers, where int32_t is too big, and
      int16_t is standard int. This is not to say that I'll use
      liblognorm on these platforms.<br>
      <br>
      Nevertheless, strlen() and sizeof() are returning size_t. There is
      an implicit conversion anytime you are using different type.</div></div></blockquote><div><br></div><div>Yup - I had *excpected* (not verified) that the optimizer just throws away the upper 32 bits.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="gmail_quote"> 64
      bits do not use more registers on 64bit architecture (x86_64,
      namely), it is still just one register. </div></div></blockquote><div><br></div><div>I am not sure about GCC, but I think I read that some compilers use the hardware split registers to store two 32 bit int's into a single 64Bit register, thus effectively freeing more registers. Again, not sure about gcc. A<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="gmail_quote">As far as I understand, it
      is 8 byte long on stack, also, because registers are used for
      stack manipulation. </div></div></blockquote><div><br></div><div>that would be a very convincing argument, as then it really doesn't matter at all (and even may be counter productive). On the other hand, this sounds like a bit of a waste performance wise.<br>
<br></div><div>Rainer<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="gmail_quote">Therefore, this size does not matter as long
      as it is not used in heap/dynamic variables.<br>
      <br>
      <br>
      --<br>
      Pavel Levshin<br>
      <br>
    </div>
  </div>

<br>_______________________________________________<br>
Lognorm mailing list<br>
<a href="mailto:Lognorm@lists.adiscon.com">Lognorm@lists.adiscon.com</a><br>
<a href="http://lists.adiscon.net/mailman/listinfo/lognorm" target="_blank">http://lists.adiscon.net/mailman/listinfo/lognorm</a><br>
<br></blockquote></div><br></div></div>