lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Aug 2007 14:09:10 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Joe Perches <joe@...ches.com>
Cc:	David Miller <davem@...emloft.net>, johannes@...solutions.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

On Mon, 27 Aug 2007 13:57:42 -0700
Joe Perches <joe@...ches.com> wrote:

> On Mon, 2007-08-27 at 13:41 -0700, David Miller wrote:
> > From: Johannes Berg <johannes@...solutions.net>
> > Date: Mon, 27 Aug 2007 12:54:09 +0200
> > > #define MAC_FMT "%s"
> > > #define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
> 
> > I don't think this works.
> 
> $ cat test_fmt.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define MAC_FMT "%s"
> #define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
> 
> int print_mac(const char* p, char* b)
> {
>   return sprintf(b, "%02x:%02x:%02x:%02x:%02x:%02x",
> 		 p[0], p[1], p[2], p[3], p[4], p[5]);
> }
> 
> int main(int argc, char** argv)
> {
>   char m1[6] = {1,2,3,4,5,6};
>   char m2[6] = {6,5,4,3,2,1};
> 
>   printf("m1: " MAC_FMT " m2: " MAC_FMT "\n", MAC_ARG(m1), MAC_ARG(m2));
>   return 0;
> }
> 
> $ gcc test_fmt.c
> $ ./a.out
> m1: 01:02:03:04:05:06 m2: 06:05:04:03:02:01

As Dave said, you are passing out a variable which is no longer valid outside
of it's scope. GCC today may accidentally allow it or it might work, but it
is only because of a GCC bug. If I recall discussions about some of the
recent kernel space bloat, GCC doesn't reuse space for variables declared
in subblocks.

I.e:
int foo(int x) {
	if (x) {
	    char block1[1024];
		...
	} else {
	    char block2[128];
	}

}

Compiler should be able to use same stack space for block1/block2 and only grow
stack by 1K. But it probably isn't that smart.




-- 
Stephen Hemminger <shemminger@...ux-foundation.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ