Increase the size of the 'message' buffer, which is currently

[sgt/tweak] / main.c

diff --git a/main.c b/main.c
index 6f71356..9478f9e 100644 (file)
--- a/main.c
+++ b/main.c
@@ -115,6 +115,55 @@
  *      everything one byte further up, you _really_ don't want to
  *      hit Save. The semantics of the warning are difficult,
  *      though.
+ *
+ *  - Custom display and/or input formats?
+ *     + for example, Zap on RISC OS is able to display a binary
+ *      file at 4 bytes per line and show the ARM disassembly of
+ *      each word. For added credit, ability to type an ARM
+ *      instruction back _in_ and have it reassembled into binary
+ *      would be even better.
+ *     + a simpler example is that sometimes you want to view a
+ *      file as a sequence of little-endian 32-bit words rather
+ *      than single bytes.
+ *     + this would have to involve some sort of scripting or
+ *      internal API. I'd really rather the interface was nailed
+ *      down very early on and people were then free to develop
+ *      custom formats without my involvement; I might be
+ *      persuaded to keep a library of them or a list of
+ *      hyperlinks or something, but actually _maintaining_ them
+ *      is more effort than I want.
+ *     + ARM assembler is all very well, but what about x86, with
+ *      its variable instruction length? You can start
+ *      disassembling from any byte position and work forwards
+ *      unambiguously, but going backwards or jumping to an
+ *      arbitrary byte position is much harder. You might have to
+ *      shift your current file view back or forward by one byte
+ *      to resynchronise, and the semantics of insert mode become
+ *      generally confused, and even trying to _predict_ what a
+ *      sensible synchronisation point would be when jumping to a
+ *      bit of the file you've never seen before ... yuck.
+ *       * The key thing that makes this horrid is that the custom
+ *         display mode looks at the file _contents_, not merely
+ *         its length, when deciding how many bytes per line to
+ *         display. File-position-dependent number of bytes per
+ *         line is fine, but _data_ dependency is doom.
+ *       * So I think that in the interests of not causing tension
+ *         between random things people would like in _some_ hex
+ *         editor and what makes Tweak Tweak, I am going to put my
+ *         foot down and say that I will not implement any
+ *         mechanism which permits a data-dependent number of
+ *         bytes per line. Anything short of that, fine, send me a
+ *         patch or a detailed and well thought out design and
+ *         I'll consider it on its merits.
+ *       * I don't, OTOH, see any reason why a custom display
+ *         function couldn't be permitted to see data before or
+ *         after the current lineful if it wanted to. So x86
+ *         disassembly could be done in a one-byte-per-line sort
+ *         of fashion in which each line shows the machine
+ *         instruction which the CPU would see if it started
+ *         executing at that byte, and also gave its length. Then
+ *         you could pick out the sequence of instructions you
+ *         were interested in from the various out-of-sync ones.
  */
 
 #include "tweak.h"
@@ -141,7 +190,7 @@ static void load_file (char *);
 char toprint[256];                    /* LUT: printable versions of chars */
 char hex[256][3];                     /* LUT: binary to hex, 1 byte */
 
-char message[80];
+char message[512];
 
 char decstatus[] = "%s TWEAK "VER": %-18.18s %s posn=%-10"OFF"d size=%-10"OFF"d";
 char hexstatus[] = "%s TWEAK "VER": %-18.18s %s posn=0x%-8"OFF"X size=0x%-8"OFF"X";
@@ -420,7 +469,7 @@ int backup_file (void) {
 }
 
 static unsigned char *scrbuf = NULL;
-static int scrbuflines = 0;
+static int scrbufsize = 0;
 
 /*
  * Draw the screen, for normal usage.
@@ -435,16 +484,15 @@ void draw_scr (void) {
     char *linebuf;
 
     scrlines = display_rows - 2;
-    if (scrlines > scrbuflines) {
-       scrbuf = (scrbuf ?
-                 realloc(scrbuf, scrlines*width) :
-                 malloc(scrlines*width));
+    scrsize = scrlines * width;
+    if (scrsize > scrbufsize) {
+       scrbuf = (scrbuf ? realloc(scrbuf, scrsize) : malloc(scrsize));
        if (!scrbuf) {
            done();
            fprintf(stderr, "%s: out of memory!\n", pname);
            exit (2);
        }
-       scrbuflines = scrlines;
+       scrbufsize = scrsize;
     }
 
     linebuf = malloc(width*4+20);
@@ -460,7 +508,8 @@ void draw_scr (void) {
        scroff = width - offset;
     else
        scroff = 0;
-    scrsize = scrlines * width - scroff;
+
+    scrsize -= scroff;
     if (scrsize > file_size - top_pos)
        scrsize = file_size - top_pos;