I noticed another incompatibility with traditional implementations. POSIX requires undivert to reject arguments with non-numeric characters (hence our extension of treating those as a filename and diverting the file contents instead). But since an empty string has no non-numeric characters, and since the empty string cannot be a file, we should treat undivert() as though it were undivert(0) (in other words, expand to the empty string, since diversion 0 is always immediately pushed to stdout).
$ /usr/ccs/bin/m4 divert(1)one divert(2)two divert undivert(0) undivert() undivert one two m4exit $ m4 divert(1)one divert(2)two divert undivert(0) undivert() stdin:5: m4: Cannot undivert : No such file or directory undivert one two m4exit I will go ahead and patch this to match traditional behavior, where the empty string is treated as 0 (and hence a no-op) rather than a filename. I also noticed this: $ /usr/ccs/bin/m4 divert(-1) undivert(0) divert m4exit $ m4 divert(-1) undivert(0) divert m4exit $ m4 -dV m4 debug: NONE: 0: input read from stdin divert(-1) m4trace:stdin:1: -1- id 1: divert ... m4trace:stdin:1: -1- id 1: divert(`-1') -> ??? m4trace:stdin:1: -1- id 1: divert(...) undivert(0) m4trace:stdin:2: -1- id 2: undivert ... m4trace:stdin:2: -1- id 2: undivert(`0') -> ??? divert m4exit Hmm - when we are discarding input, undiverting diversion 0 seems to hang the output engine! Hopefully, this is also easy to fix. -- Eric Blake _______________________________________________ Bug-m4 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-m4
