path: root/libiptc/
diff options
authorPablo Neira Ayuso <>2012-07-23 12:27:16 +0200
committerPablo Neira Ayuso <>2012-07-25 13:04:52 +0200
commit44191bdbd71e685fba9eab864b9df25e63905220 (patch)
treeaca9c181f8c0643374653870e6742db51dce2a4b /libiptc/
parentf4a6c20c39c97214e22625764bfa80ef8e1e3147 (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: 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 <>
Diffstat (limited to 'libiptc/')
0 files changed, 0 insertions, 0 deletions