[Lognorm] [rsyslog] liblognorm
Rainer Gerhards
rgerhards at hq.adiscon.com
Thu Nov 28 12:19:37 CET 2013
On Thu, Nov 28, 2013 at 12:10 PM, Pavel Levshin <pavel at levshin.spb.ru>wrote:
> 28.11.2013 15:00, Rainer Gerhards:
>
>
>> ahh... excellent point, I have to admit I overlooked it. es_size_t has
>> the advantage (IMHO) that it is 32 bits and saves us the overhead of
>> passing 64 bits around. I cannot see any reasonable case where we have
>> >2gig messages. How about using uint32_t instead (or just plain int,
>> but...).
>>
>>
>>
> I'm not sure. Size_t is universally portable, but uint32_t is also
> sufficient for all current architectures, which I could think of. Is there
> someone running liblognorm at 16 bit CPU?..
>
even there uint32_t should be 32bit unsigned, right?
>
> 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.
Rainer
>
>
> --
> Pavel Levshin
>
> _______________________________________________
> Lognorm mailing list
> Lognorm at lists.adiscon.com
> http://lists.adiscon.net/mailman/listinfo/lognorm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.adiscon.net/pipermail/lognorm/attachments/20131128/3451dee4/attachment.html>
More information about the Lognorm
mailing list