On Wed, Oct 16, 2024 at 3:01 PM joerg van den hoff <veedeeh...@gmail.com> wrote: > I now double-checked: the manual seems to indicate that w/o preceding mk, rt > needs an argument > (distance from page top). if it _really_ does the line would have to read > `.rt 0'. but doing this > does not change behaviour neither for 1.22 nor for 1.23: AFAICS the resulting > pdfs are unaltered. > > so apparently `.rt' w/o argument and preceding `mk' indeed is valid and > _does_ (and might > prospectively be guaranteed to) return to page top.
This falls into an interesting area of underspecification. CSTR #54 also mentions the behavior of .rt without .mk but with argument, but does not address argumentless .rt without .mk (let's call it ARWM). What then should be concluded from this? 1. The behavior of ARWM is undefined 2. The behavior of ARWM is undocumented but defined by troff's behavior In 1984 maybe one could have made a case for the former, and changed the behavior with impunity (perhaps making ARWM throw an error or always move the drawing position to pi inches from the top of the page). With an extra 40 years of consistent behavior, this becomes harder to defend, especially knowing that a lot of things were poorly specified in CSTR #54, so users figured out what worked by trial and error. (Some of these things have even been codified in groff documentation.) And also knowing that some of troff's user base enjoyed finding ways to creatively (ab)use programming languages' fringes. That said, there's good reason to _not_ use ARWM in your documents. To experienced roff readers, ".rt" without an argument strongly implies there was a preceding .mk. Code that gets the machine to do what you want is nice, but code that humans can read and make sense of (while also getting the machine to do what you want) is better. So ".rt 0" is better than plain ".rt" because it makes clear that there's no preceding .mk, even if they both behave the same. (This holds even if you're the only one who ever reads your roff code; a future you will appreciate the disambiguation. It holds even more strongly for code you post publicly.) On Wed, Oct 16, 2024 at 4:13 PM G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > On many machine architectures, in the C language, a pointer occupies the > same number of bits as an `int` variable. Clearly we can assume that > they're always equivalent; if our code works despite some tedious manual > warning us not to rely on this conclusion, we should do so anyway. That's a flawed analogy on two fronts: - C standards explicitly say the size of a pointer is undefined. ARWM is unaddressed by any documentation. - As you imply above, pointer sizes do actually vary across architectures. There is no evidence ARWM behavior also so varies.
