From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 02:45:15 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 576A31065672 for ; Thu, 13 May 2010 02:45:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C33098FC0A for ; Thu, 13 May 2010 02:45:14 +0000 (UTC) Received: by vws1 with SMTP id 1so921880vws.13 for ; Wed, 12 May 2010 19:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=RrQRSHY+5QAiqjeGM6mpW4qylBNtD1W7JFTwhdVNmgE=; b=ieAWp+5iRyUcUI0g5rhk1nKFGJRUmdLY48QwWoNczkwTmOYIsVSrofBVkc+lP4xy1k 1PuXZNWXu+7KvYMokDRXvUq3bI6e8bU+SvWSPGIr1lGJbgY1/F0Y9pBRa0kSE5XJkvvb Yaoca5akud9aYmIs5WYadsVATrS69eGWo/mrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CxHGYWMstYD6L1lwKiheUsd2Sbsu05D2F4MD3ku05GFKG3/RO1vpFasquo/iZwElns kE/eLIT6Y6Ex3TPF3gnqhW48K2HKRFLzvBg10XjzWeBrHGObLqYrBxR9tqpgT+1KOZNK oHmcca2K9CC0HEL4VpW6YWpX13bqHkvN5zmjU= Received: by 10.220.128.136 with SMTP id k8mr6084500vcs.58.1273718713684; Wed, 12 May 2010 19:45:13 -0700 (PDT) Received: from [192.168.15.41] ([24.114.252.239]) by mx.google.com with ESMTPS id z22sm3418831vco.22.2010.05.12.19.45.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 19:45:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20100512185415.7b6d2583@bhuda.mired.org> Date: Wed, 12 May 2010 22:45:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BEE374F-6A0C-409B-943C-653BA66FCAF5@gmail.com> References: <20100512185415.7b6d2583@bhuda.mired.org> To: Mike Meyer X-Mailer: Apple Mail (2.1078) Cc: hackers@freebsd.org Subject: Re: argv offset -- doesn't make sense... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 02:45:15 -0000 On May 12, 2010, at 6:54 PM, Mike Meyer wrote: > On Wed, 12 May 2010 17:30:48 -0400 > Garrett Cooper 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=