HP3000-L Archives

August 2000, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Cadier <[log in to unmask]>
Reply To:
Bill Cadier <[log in to unmask]>
Date:
Tue, 29 Aug 2000 12:35:12 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (88 lines)
Stan wrote:

>Re:
>
>I wrote:
>
>> : I reported it again in April of 2000 (Call ID 3100150578), and just
>> : noticed that it was closed *WITH NO EXPLANATION*.
>> : Side comment: please...don't accept it if a call is closed with
>> : no explanation!
>
>Several HP people were kind enough to write me saying something
>to the effect:
>
>   > It says that it couldn't be duplicated, in March 13.
>
>or:
>
>   > there's a response from the HP ESC in the call ID.
>
>So...I went back and checked...no response *VISIBLE TO ME*.
>
>I suspect that what happened is that the engineer who entered the
>response failed to mark it "customer visible", so I couldn't see it.
>


This happened to me once and nothing I did to force it to be visible to the
world worked. Phone calls to various internal folks who run this did not result
in a solution either. Another problem!

>
>Technical note...
>
>Bill Cadier wrote me about the probable problem.  He sure seems to
>have found the bug, although the full analysis is a bit more complicated.
>
>A loop like:
>
>        while (buf[length-1] == '' '')
>           length--;
>
>will not loop forever unless "length" is a 16-bit counter.
>


<< snip >>

I hope I didn't imply that this loops forever! That's actually not at all the problem.

The loop terminates once buf[length-1] is not a blank (hex 20). More often than not the
address immediately preceeding buf[0] contains something that isn't a blank and so
we stop. It is in the rare circumstance where buf[-1] is actually a blank that we run into
a problem because length then goes negative and this length is passed to the C library
write() function. Since the buffer address remains constant for the instance of 'tobyte'
(the built-in version not the program) the contents of buf[-1] remain constant too. So any
time we process a completely blank line we trundle backwards some number of bytes
beyond buf[-1] and that is what causes the target file to wind up being both useless and
huge.

Here's the whole code fragment taken from the 1995 SR:

while (!SHELL_BREAK) {
        length = FREAD(file_num, buf, buf_size);
        if (ccode() == CCL) {
                fprintf(stderr, "%s: read error on input file %s\n",
                        _cmdname, name);
                result = 1;
                goto done;
        } else if (ccode() == CCG) {
                /* end of file */
                break;
        }
        if (trim) {
                while (buf[length-1] == '' '')
                        length--;
        }
        write(fileno(of), buf, length);
        if (add_nl)                               |
                write(fileno(of), "\n", 1);
}

Best Regards,

Bill
HP/CSY
[log in to unmask]

ATOM RSS1 RSS2