https://bugzilla.balabit.com/show_bug.cgi?id=187 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|NEW |RESOLVED --- Comment #5 from Balazs Scheidler <bazsi@balabit.hu> 2012-07-27 07:46:23 --- I think bumping the default limit to 64k should suffice, no real need to make this absolutely unbounded, as this is the first actual request to increase the size. The patches below make this runtime configurable from the API side, even though it is not (yet) a configuration setting. Instead of alloca/scratch-buffers it uses a gcc extension, if that proves unportable we can always change that. I don't like allocating too much data from the stack, but I think 64k should be safe. The default stack limit on my x86_64 laptop is 8MB, I remember that being around 2MB on x86. commit bf69c41f696e7d94e424a40f5979bd5efcb33179 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Fri Jul 27 07:42:18 2012 +0200 msg-format: make sd_param_value maximum length adjustable via API Although this option is not (yet) introduced in the configuration file, the unit tests also try to cover the 'too-long-sdata' case, which is inpractical in case the new 64k default is to be overflown. It might make sense to make this value actually controllable by the configuration file, but for now I think it is enough to simply bump the default limit to 64k. This patch also fixes the test_msgparse unit test so it passes again. Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> commit ab9c013f7f06cbb024cae52905659450ddbdfaf1 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Wed Jul 25 18:39:45 2012 +0200 syslog-format: increase the limit for SDATA value length to 64k Reported-By: Sergey <cloun-rulez@yandex.ru> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.