Date: Wed, 12 May 2010 22:45:22 -0400 From: Garrett Cooper <yanefbsd@gmail.com> To: Mike Meyer <mwm@mired.org> Cc: hackers@freebsd.org Subject: Re: argv offset -- doesn't make sense... Message-ID: <8BEE374F-6A0C-409B-943C-653BA66FCAF5@gmail.com> In-Reply-To: <20100512185415.7b6d2583@bhuda.mired.org> References: <A28FCE87-10DE-46BB-B22F-E7DF9FD32BCD@gmail.com> <20100512185415.7b6d2583@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 12, 2010, at 6:54 PM, Mike Meyer wrote: > On Wed, 12 May 2010 17:30:48 -0400 > Garrett Cooper <yanefbsd@gmail.com> wrote: >=20 >> Hi Hackers, >> Ignoring the compiler warning (yes, I know...), why is the = offset for the argv[0] (program name) in the following program off by = one? It doesn't make sense why the fstat would work, but the printf = would fail (and in fact segfault if I remove the 1 < argc guard = statement and adjusted the offset by removing the +1). >> Thanks, >> -Garrett >=20 > It isn't off by one. argv is a pointer to pointers to char, so *argv > is a pointer to char, and so is *(argv+1). In the latter case, it > increments by the size of a pointer, so *(argv+1) is the same as > argv[1]. You're confusing the issue by having argv[0] and argv[1] be > copies of the same string. If you make argv[1] something_else, you > get: >=20 > bhuda% ./test_fstat something_else > argc - 2, argv[0] - ./test_fstat > something_else - 3745212532062 >=20 > Your real bug is that you never allocate the buffer you passed to > fstat. You need to declare sb without the "*", and then pass &sb to > fstat and reference sb.st_size. With what you've got, fstat will write > the stat results across whatever address is on the stack space > allocated to the pointer sb. >=20 > Removing the test and increment (which one?) will move the code > around, potentially changing the value of the pointer sb, both of > which will cause a different part of memory to be clobbered by the > call to fstat, meaning things will blow up in a different way. Yup ... as pointed out on the list elsewhere, that was my fault = by not properly allocating the storage for the pointer to the struct = stat object. Silly me for not realizing it sooner. Thanks for the help :), -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8BEE374F-6A0C-409B-943C-653BA66FCAF5>