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=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3299 invoked from network); 6 Aug 2020 05:00:56 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2020 05:00:56 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 232A69C1E6; Thu, 6 Aug 2020 15:00:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 209D19C1AF; Thu, 6 Aug 2020 15:00:27 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="N3YXjLtl"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A76B19C1AF; Thu, 6 Aug 2020 15:00:25 +1000 (AEST) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by minnie.tuhs.org (Postfix) with ESMTPS id BB0C19C1AD for ; Thu, 6 Aug 2020 15:00:24 +1000 (AEST) Received: by mail-qt1-f179.google.com with SMTP id w9so35476984qts.6 for ; Wed, 05 Aug 2020 22:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/g5aZKNwkESTporM/azCVfxu1y5RaNIs7ihZ5Qz6eiA=; b=N3YXjLtl+gV0m9s3l9wh+Gu2TUTF2L7gNSCthqjZFvTMGAaX1ILJC7b4OIDACO6L9r WIXtaEvns0asEk0LpW8IR3jpFQPGPGoe8OHCRaGvEiyXkJTWwx+hqtkQD5UL2ODGqfbT p6B1wfS2CSmyMh31R0bB/sZCLDxUi9K2Eq2oCDojs0zCAl3PbI7Sxh1ktzvJKS0bqL14 khylmWr7K7EseT8tITCzCdJiNLQg9aG2wtPvp8JckJxQGr9qSNaMrNgyFXkBX4+z7nVR 6Aj/+3tRRZuLgTvgLmExOAtQjQNK2Pv3tAVXgewJ9YW0cxgiAs+yIm+CTJWeD2A9/JgP Qi9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/g5aZKNwkESTporM/azCVfxu1y5RaNIs7ihZ5Qz6eiA=; b=UTSF7Lv29zgl9aDCyU1EE+DwdkUHI/6XDoazUEEFEfJ1Z1JApjXBsbEfedC/kisIf+ icdkfKjhAWbWOaV1ZbJWM/VaXUi1Z8TG9I1RurZaAoNkQJMcm44rTQc6uWaviSkaj9KR tuXECDnLDJd3hzzE+KvuMuVjhjhWha+O0jwvgfObd3/BduJ1nmQc5cKXGfe31QvOJZW3 dFK56DyHdGtNhaTc950wd8zvUBMQ8M+7D0E2onKICkONsXTJ4qCcckztr3Ni0IRoJ3en JQY05mDezyCXoqNffen8hlXO6Qd8EY9N/Pg2vRnwJTqy9rgTJfFXoan8yslkGIGu9TvD wfNQ== X-Gm-Message-State: AOAM530CtIZsrM9GP3mUz66BYUI++tbIXYz0nfhCA8L9CEd8EdgkzHro qqkwwr5ljDMBYTpGnvzBS5L81/l6cVmCzb4Kf0YyXynAypE= X-Google-Smtp-Source: ABdhPJyA/EExisPQG4pWEgAzOFyNuQF0w6jv/DmZ3Lnbo29ozRr8nLbjhoyVkyrNgODMi5z+65tfwElwlmXphJjoYeg= X-Received: by 2002:ac8:1084:: with SMTP id a4mr6667655qtj.83.1596690023741; Wed, 05 Aug 2020 22:00:23 -0700 (PDT) MIME-Version: 1.0 References: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> In-Reply-To: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> From: John Cowan Date: Thu, 6 Aug 2020 01:00:13 -0400 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="000000000000ae913505ac2e5dcf" 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" --000000000000ae913505ac2e5dcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 include= s: > > 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 =E2=80=93lp p= ackage > are both dead, and even getchar has changed. All have been replaced by th= e > clean, highly efficient, stdio(3) package. The first things to know are > that getchar(3) returns the integer EOF (=E2=80=931), which is not a poss= ible 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 > > --000000000000ae913505ac2e5dcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The manual came out in editions, but the code, man pages, = etc. changed continuously.=C2=A0 So what you hear about in a particular pap= er is not necessarily correlated with a particular state of the manual.
On T= hu, Aug 6, 2020 at 12:49 AM Will Senn <will.senn@gmail.com> wrote:
=20 =20 =20
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 =E2=80=93= 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 (=E2=80=931), which is not a possible byte value, on end of file, tha= t 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
 
--=20
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
--000000000000ae913505ac2e5dcf--