[Lognorm] [rsyslog] liblognorm

[Pavel Levshin]

28.11.2013 15:19, Rainer Gerhards
>
>
>     For external interface, I'd vote for size_t.
>
>
> 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...
>
> Can you give me a good argument (besides standards) why size_t would 
> be good here? Or better said: does not hurt.
>

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.

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.


--
Pavel Levshin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.adiscon.net/pipermail/lognorm/attachments/20131128/c40737bb/attachment-0001.html>