diff options
author | Pablo Neira Ayuso <pablo@netfilter.org> | 2012-07-23 12:27:16 +0200 |
---|---|---|
committer | Pablo Neira Ayuso <pablo@netfilter.org> | 2012-07-25 13:04:52 +0200 |
commit | 44191bdbd71e685fba9eab864b9df25e63905220 (patch) | |
tree | aca9c181f8c0643374653870e6742db51dce2a4b /extensions/libxt_CT.man | |
parent | f4a6c20c39c97214e22625764bfa80ef8e1e3147 (diff) |
iptables-restore: move code to add_param_to_argv, cleanup (fix gcc-4.7)
This patch seems to be a mere cleanup that moves the parameter parsing
code to add_param_to_argv.
But, in reality, it also fixes iptables when compiled with gcc-4.7.
Moving param_buffer declaration out of the loop seems to resolve the
issue. gcc-4.7 seems to be generating bad code regarding param_buffer.
@@ -380,9 +380,9 @@
quote_open = 0;
escaped = 0;
param_len = 0;
+ char param_buffer[1024];
for (curchar = parsestart; *curchar; curchar++) {
- char param_buffer[1024];
if (quote_open) {
if (escaped) {
But I have hard time to apply this patch in such a way. Instead, I came
up with the idea of this cleanup, which does not harm after all (and fixes
the issue for us).
Someone in:
https://bugzilla.redhat.com/show_bug.cgi?id=82579
put some light on this:
"Yes, I ran into this too. The issue is that the gcc optimizer is
optimizing out the code that collects quoted strings in
iptables-restore.c at line 396. If inside a quotemark and it hasn't
seen another one yet, it executes
param_buffer[param_len++] = *curchar;
continue;
At -O1 or higher, the write to param_buffer[] never happens. It just
increments param_len and continues.
Moving the definition of char param_buffer[1024]; outside the loop
fixes it. Why, I'm not sure. Defining the param_buffer[] inside the
loop should simply restrict its scope to inside the loop."
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'extensions/libxt_CT.man')
0 files changed, 0 insertions, 0 deletions