From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16053 invoked from network); 6 Aug 2020 12:16:16 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2020 12:16:16 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2BF439C1E3; Thu, 6 Aug 2020 22:16:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7914C9C1AD; Thu, 6 Aug 2020 22:15:30 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DHK+aTFY"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DCAF49C1B0; Thu, 6 Aug 2020 22:15:27 +1000 (AEST) Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by minnie.tuhs.org (Postfix) with ESMTPS id 5657B9C1AF for ; Thu, 6 Aug 2020 22:15:27 +1000 (AEST) Received: by mail-oo1-f41.google.com with SMTP id k4so5102656ooa.9 for ; Thu, 06 Aug 2020 05:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xPKBSBSlUPUCM5odrlNvcpY0BB+5x+SSTe8qNWWDbSg=; b=DHK+aTFYmSIJjW5py1FT+IStVCd7L/hejPRhV4/2fRBlxcI7xl+U5DslGYV37deHg1 XAUDx230wyRh6GjC3XEd4smQjvnzEAA1hO509aW9/0fMBhqHgwr+Nvzvn0qlRi7PKxVy ZQygWzQu9s09g6sWkBjAbM1/pJINekyfbhFKEMZfW4DWTHrIsuL4W6awaqXS7YtuRee+ 00JXRZwCARl4Vww8lTUfew2gPSf99FjwFZeUeM8wpIjkFGZUPXkQa+3SeKCeJT6oJBJn +D+5LPUdb140n1MsVLc2KHHtlOLtYAi4eqTQ3nRXJd095BrCptVUMGPypz96qgRLyQS3 AdBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xPKBSBSlUPUCM5odrlNvcpY0BB+5x+SSTe8qNWWDbSg=; b=YaSr0wF2JbXeKzEQDL7J4JvRdmu+funuewGxmotii4FmJbkdCTWGx452iMk/8ucKRv 29EJ9S6U4c6tnI2qk/1SGezymHX7sZWMjp/zotEUEdtQVme/+K7T/D8c0BUcvj6Xz1CZ rcBNKJgzKowXayPIm84Ko7QdkcH7RxCPONLwR6i2YrSp5t+Y0P8wqyBFRuEOqiEasz0t E+84KXoZtkjokahKCuXKsig3s4CihF2jJGuYm16ijH4HEZWjfZdhVeM/OOxKogRVvuhq pDGYPzGcVguGQYzc94nAe4bMfDgP8LsoA2wOaVdxYB5WVlowAPBTfsT1Ez/Exckmuryi V7Fw== X-Gm-Message-State: AOAM532aYITzSxUP8R+hONzG9g1uFDJt3LAGKqqj4mgS7ELEdfEoqq4i M5jyyOU0uApx1wob24KEaarwepsMacA= X-Google-Smtp-Source: ABdhPJy0ojT1u74dKQLl1A0v9fVXCPtlxbevVc1BumoEzCde0jaDZKWICetYxnHvHzkCS6xsdaCjyg== X-Received: by 2002:a4a:d62c:: with SMTP id n12mr7501851oon.38.1596716126399; Thu, 06 Aug 2020 05:15:26 -0700 (PDT) Received: from terra.local (99-139-148-170.lightspeed.rcsntx.sbcglobal.net. [99.139.148.170]) by smtp.gmail.com with ESMTPSA id o5sm987732otp.8.2020.08.06.05.15.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2020 05:15:25 -0700 (PDT) To: John Cowan References: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> From: Will Senn Message-ID: <5c410870-cfeb-a63b-d699-3cdfdb53f82b@gmail.com> Date: Thu, 6 Aug 2020 07:15:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------167A16CD4C7727313693FC9C" Content-Language: en-US Subject: Re: [TUHS] v7, adb, and fcreat X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------167A16CD4C7727313693FC9C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, John. That is one concise answer that explains the problem quite well. Now that I think about it, it explains quite a bit about quite a bit :). Will On 8/6/20 12:00 AM, John Cowan wrote: > The manual came out in editions, but the code, man pages, etc. changed > continuously.  So what you hear about in a particular paper is not > necessarily correlated with a particular state of the manual. > > On Thu, Aug 6, 2020 at 12:49 AM Will Senn > wrote: > > I've done research on this, but I'm confused and would appreciate > some help to understand what's going on. In the 7th edition > manual, vol 2, there's an ADB tutorial (pp. 323-336). In the > tutorial, the authors, Maranzano and Bourne, walk the reader > through a debugging session. The first example is predicated on a > buffer overflow bug and the code includes: > > struct buf { > int fildes; > int nleft; > char *nextp; char buff[512]; }bb; > struct buf *obuf; > > ... > if((fcreat(argv[1],obuf)) < 0){ > ... > > Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. > VII): > > Standard I/O. The old fopen, getc, putc complex and the old –lp > package are both dead, and even getchar has changed. All have been > replaced by the clean, highly efficient, stdio(3) package. The > first things to know are that getchar(3) returns the integer EOF > (–1), which is not a possible byte value, on end of file, that > 518-byte buffers are out, and that there is a defined FILE data type. > > The buffers are out, fcreat is gone, etc. So, what's up with this? > I don't think adb was in v6, where the fcreat function and buf > struct are used... Were Maranzano and Bourne using some kind of > hybrid 6+ system? > > Thanks, > > Will > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF --------------167A16CD4C7727313693FC9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks, John. That is one concise answer that explains the problem quite well. Now that I think about it, it explains quite a bit about quite a bit :).

Will

On 8/6/20 12:00 AM, John Cowan wrote:
The manual came out in editions, but the code, man pages, etc. changed continuously.  So what you hear about in a particular paper is not necessarily correlated with a particular state of the manual.

On Thu, Aug 6, 2020 at 12:49 AM Will Senn <will.senn@gmail.com> wrote:
I've done research on this, but I'm confused and would appreciate some help to understand what's going on. In the 7th edition manual, vol 2, there's an ADB tutorial (pp. 323-336). In the tutorial, the authors, Maranzano and Bourne, walk the reader through a debugging session. The first example is predicated on a buffer overflow bug and the code includes:

struct buf {
int fildes;
int nleft;
char *nextp; char buff[512]; }bb;
struct buf *obuf;

...
if((fcreat(argv[1],obuf)) < 0){
...

Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. VII):

Standard I/O. The old fopen, getc, putc complex and the old –lp package are both dead, and even getchar has changed. All have been replaced by the clean, highly efficient, stdio(3) package. The first things to know are that getchar(3) returns the integer EOF (–1), which is not a possible byte value, on end of file, that 518-byte buffers are out, and that there is a defined FILE data type.

The buffers are out, fcreat is gone, etc. So, what's up with this? I don't think adb was in v6, where the fcreat function and buf struct are used... Were Maranzano and Bourne using some kind of hybrid 6+ system?

Thanks,

Will
 
-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
--------------167A16CD4C7727313693FC9C--