<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="gmail_quote">28.11.2013 15:19, Rainer Gerhards
<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 class="HOEnZb">
<div class="h5"><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>
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. 64
bits do not use more registers on 64bit architecture (x86_64,
namely), it is still just one register. As far as I understand, it
is 8 byte long on stack, also, because registers are used for
stack manipulation. 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>
</body>
</html>