On 10-Nov-10 17:25:05, Louis Guillaume wrote: > Hi, > I just noticed that tbl was crashing under certain conditions with the > "nospaces" option. Here's what I discovered: > > Take a simple table like this: > > .TS H > expand nospaces tab(@); > l c r. > \fBone @ two @ three\fP > .TH > 1 @ 2 @ 3 > .TE > > Everything works here. But, if, say we didn't have a value in the > second > column, but still had spaces, we get a segmentation fault in tbl: > > > .TS H > expand nospaces tab(@); > l c r. > \fBone @ two @ three\fP > .TH > 1 @ @ 3 > .TE > > > $ tbl se_test.ms > .if !\n(.g .ab GNU tbl requires GNU troff. > .if !dTS .ds TS > .if !dTE .ds TE > .lf 1 se_test.ms > .TS H > Segmentation fault > > Removing the spaces, leaving "1 @@ 3", solves the problem. But seems > like a bug in tbl to me... > > I've reproduced this on OS X and NetBSD. > > Louis
This definitely looks like a bug! I suspect that the logic of "removing leading and trailing spaces" is tripping up over the failure to find a data item with reference to which a space can be categorised as "leading" or "trailing". If you remove the spaces in the missing data item: .TS H expand nospaces tab(@); l c r. \fBone @ two @ three\fP .TH 1 @@ 3 .TE then all is fine. Likewise, if you put in a "\&" so that the logic has something to bite on: .TS H expand nospaces tab(@); l c r. \fBone @ two @ three\fP .TH 1 @ \&@ 3 .TE then all is again fine. (you could put the "\&" anywhere amongst the spaces -- the above with it at the end is just one example). Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.hard...@wlandres.net> Fax-to-email: +44 (0)870 094 0861 Date: 11-Nov-10 Time: 10:17:41 ------------------------------ XFMail ------------------------------
