<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 07/08/2012 09:22 AM, Johnny Billquist <a class="moz-txt-link-rfc2396E" href="mailto:bqt@softjar.se"><bqt@softjar.se></a>
wrote:
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">On 2012-07-08 13:58, Michael Bloom wrote:
<br>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
<blockquote type="cite" style="color: #000000;">version of TECO,
it might be beneficial to make as much use of "local Q
<br>
registers" (those with two char names beginning with "."), so
that you
<br>
don't unintentionally accumulate data that you no longer
need. You
<br>
could think of them as a TECO equivalent to "alloca()". <br>
</blockquote>
<br>
They came after V36. But they are not strictly needed, as you
can push down Q-registers yourself if you want to play with them
without affecting someone else.
<br>
</div>
</blockquote>
The whole point is avoiding the need to push Q-registers. It is all
too easy to make a mistake when pushing Q-registers that costs you a
lot of debugging time. If you don't push Q regs, you never have to
pop them!<br>
If you have local Q regs, there is little legitimate use for
pushing/popping them other than to rapidly copy both parts of one
q-reg to another q-reg (it's a good idea to use q-regs as two member
structs, when you can)<br>
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
<br>
If you run out of memory, you are always in trouble...
<br>
</div>
</blockquote>
That's why defensive coding is especially important with as memory
space as TECO has<br>
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
<br>
Not sure when and why you'd need 32-bit arithmetic, though...
<br>
</div>
</blockquote>
I'm not sure either, since, as I've already admitted, I don't know
the HTTP protocol. But I did want to make a suggestion about long
arithmetic, just in case HTTP packets <u>did</u> contain 32 bit
fields upon which arithmetic might be performed. With a heads up
about this, Richard can look for places where this might be needed,
and plan accordingly. It's always beneficial to strategize how to
deal with problems prior to dealing with them, rather than just
jumping in to code, and then figuring out how to "handle each bridge
as it is encountered".<br>
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
I doubt you'll ever have TECO leak memory. However, you can run
out of memory, so cleaning up your Q-registers, especially if
you know they might store lots of data, is a good idea.
<br>
(TECOs memory handling is rather simplistic, not to mention well
tested by now, which is why I doubt you have any memory leaks.)
<br>
</div>
</blockquote>
Of course, TECO itself is robust, but . . .<br>
<br>
I was not referring to *TECO* leaking memory, but rather the program
running <i>within</i> TECO, which may append to q register
space, push q-regs without popping them, or make memory disappear
in other ways. If you've ever written a reasonably large TECO
program (such as the DECUS 11-737 package that I previously
mentioned), you've got a good chance of having experienced trying
to debug a TECO memory leak. This is the kind of place where
defensive programming really shines. As one of my college profs was
known to say "The main prerequisite for debugging is ''bugging''.
And especially with a language that so resembles line noise as TECO
does, avoiding "bugging" takes care.<br>
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">Dumping out a file is
something TECO can do all day long without a problem.
<br>
You can either do it page by page yourself, or let teco do it.
<br>
</div>
</blockquote>
I was assuming that Richard planned to take use of the TECO data
manipulation facilities, not just use it as a glorified "cat"<br>
<blockquote
cite="mid:mailman.34.1341781806.1319.simh@trailing-edge.com"
type="cite">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">There are pros and cons to
both. But neither will cause you any weird memory issues.
<br>
</div>
</blockquote>
Yes, it's how you program that determines whether you reclaim memory
that's no longer needed, or not. Local Q-regs allow de-allocation
to be automatic when you leave a macro, eliminating a source of
coding errors that can result in "weird memory issues". That was
why I made a reference to "alloca()", since local q reg's
effectively allocate their space on the TECO program's execution
stack. With a C program, if you allocate memory within a routine
that you subsequently exit without without saving or freeing the
allocated space, you get a memory leak, but memory allocated with
alloca() is automatically freed. Same thing with Local Q-regs.
When you leave the routine they belong to, "poof" they are gone.<br>
<br>
michael<br>
<br>
</body>
</html>