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(a)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