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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1980 invoked from network); 6 Aug 2020 04:49:55 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2020 04:49:55 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id AB2239C1D6; Thu, 6 Aug 2020 14:49:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C9F259C1AF; Thu, 6 Aug 2020 14:49:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="S3KniIX8"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id E92519C1AF; Thu, 6 Aug 2020 14:49:09 +1000 (AEST) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by minnie.tuhs.org (Postfix) with ESMTPS id 6B4389C1AD for ; Thu, 6 Aug 2020 14:49:09 +1000 (AEST) Received: by mail-ot1-f50.google.com with SMTP id e11so11005312otk.4 for ; Wed, 05 Aug 2020 21:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=FHNd36o9SMjLBF3Td6t6ec5HD4R+E9PrrhK33ffPb08=; b=S3KniIX8jRquwIPRZxehmEkcHk9/kpS63fpsTKDotpXZdQIjE6q+vWjnUCqxUMCvzL rAETQK19EaaN4OHYNN+yCaxb3KLKWKLWD0xP6j6IheAZ3FL9SNMEhLxHHeHi47mwGpG1 3eZsJMoH2vX8ovT9X+nES/mgYq/GRmPyP4nTtpRPzDXmpHFm5RPDkaxX2sApwGIE8Kg2 IliDqKuG4qPoRitqPV2bYh/PC431s5vUhPJmuRvBj7ofeNBP4NFfULW/SFIIzoFdsQYi fbFccS6N5PO4AbGQFBFmkc83w5EkiPyufSQOkE0V4B2YBg5k7ZDRndvPDlsHizGWuHwu sHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=FHNd36o9SMjLBF3Td6t6ec5HD4R+E9PrrhK33ffPb08=; b=uW5Lt5dLIMKIiSyRXNWdEmWtksHEnJzZGRSKTFBtrQufgyHP1CUO+FSjS9RsQYBwKU LnTiHsL7WjTjerC9+SSEji0luhj3o84gayUqU7k0KFNF3xykAB+mAgeuG9Se4wWpbqpr VXRKUAfJjvj9U0szqtz3Wjo+mQv2b4v2ZoRqO8qP9GPd/Sy2YhbYjGr/XFkkQ0eGQnTv ElfdzaoPZYLnwUYe4tjR/oW3XSJ8SkBf0EK2GiXgG9S4Aguoi9/VynYAmQk8/vnBEmwn ulxjlfL3XhElaO8Bvoa1vQFlZVloq2956LTsB4+lGci8sUpWXF4NTxOWeQcS0y5Yx3wA FGUA== X-Gm-Message-State: AOAM53132L8SwvcBwvTSs7E/3/EYsE4kTciVyMi5ZreJiRPB9LIzXpef 8p4fdFObqxlpjA3oz2VKWkw6/LV77As= X-Google-Smtp-Source: ABdhPJw/vdHAq9b2/xTAYrXO4sEMfEicNuLvtU9Baa2Zi/OdqSVwa1CquvU4pbGADoO8eVT9dF32Tw== X-Received: by 2002:a05:6830:2119:: with SMTP id i25mr5866648otc.131.1596689348405; Wed, 05 Aug 2020 21:49:08 -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 x11sm995032oot.0.2020.08.05.21.49.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 21:49:07 -0700 (PDT) To: TUHS main list From: Will Senn Message-ID: <3949d53c-e075-ddf9-a272-d82f103ab59d@gmail.com> Date: Wed, 5 Aug 2020 23:49:06 -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 Content-Type: multipart/alternative; boundary="------------D7B380C2C6A89BF8E75C4083" Content-Language: en-US Subject: [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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------D7B380C2C6A89BF8E75C4083 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------D7B380C2C6A89BF8E75C4083 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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
--------------D7B380C2C6A89BF8E75C4083--