The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Will Senn <will.senn@gmail.com>
To: John Cowan <cowan@ccil.org>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] v7, adb, and fcreat
Date: Thu, 6 Aug 2020 07:15:25 -0500	[thread overview]
Message-ID: <5c410870-cfeb-a63b-d699-3cdfdb53f82b@gmail.com> (raw)
In-Reply-To: <CAD2gp_SOJSLh-Nq2OokJKPiL0tfR_FyqYBxhHgBhkY7+WWtmAw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

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 
> <mailto: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


[-- Attachment #2: Type: text/html, Size: 3456 bytes --]

  reply	other threads:[~2020-08-06 12:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-06  4:49 Will Senn
2020-08-06  5:00 ` John Cowan
2020-08-06 12:15   ` Will Senn [this message]
2020-08-06 16:55 Noel Chiappa
2020-08-06 18:36 ` Will Senn
2020-08-06 19:25 Noel Chiappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c410870-cfeb-a63b-d699-3cdfdb53f82b@gmail.com \
    --to=will.senn@gmail.com \
    --cc=cowan@ccil.org \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).