Thread (1 message) 1 message, 1 author, 2007-08-29

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

From: Michael Buesch <hidden>
Date: 2007-08-29 17:48:22

On Wednesday 29 August 2007 00:54:19 David Miller wrote:
From: Michael Buesch <redacted>
Date: Tue, 28 Aug 2007 16:48:44 +0200
quoted
On Monday 27 August 2007 23:11:50 David Miller wrote:
quoted
From: Joe Perches <joe@perches.com>
Date: Mon, 27 Aug 2007 13:57:42 -0700
quoted
On Mon, 2007-08-27 at 13:41 -0700, David Miller wrote:
quoted
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 27 Aug 2007 12:54:09 +0200
quoted
#define MAC_FMT "%s"
#define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
quoted
I don't think this works.
$ cat test_fmt.c
#include <stdio.h>
#include <stdlib.h>
You're just getting lucky in this test case.

The language does not allow what you are doing, so you're
playing with fire.
What exactly to you think it invalid in this code?
I think it's fine (except that I'd chose an u8* for the mac
address (first arg in print_mac()).
The __buf[] is used out of scope, therefore it's stack space is
fair game for the compiler to reuse.

When the compiler sees:

	printk(FMT, ({ char __buf[x]; print_mac(a, __buf); __buf;}));

It first all of the printk() argument expressions, first FMT and
then it evaluates the ({ ... }) argument.

Now that the ({ ... }) expression is done, __buf[] is out of
scope and illegal to reference.

printk() is now called, with a pointer to an out-of-scope buffer.
This is illegal.

I don't know how else to explain this to you, I can learn how to
describe the issue in German if this would help :-)
Oh, not needed. I see the bug and indeed, this is a ticking
timebomb.
I don't use the ({}) notation a lot, so I didn't see this here.

-- 
Greetings Michael.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help