1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
GNU m4 TODO - Tasks that need implementing. -*- outline -*-
Copyright (C) 2000, 2001, 2006, 2007, 2008, 2010 Free Software
Foundation, Inc.
Tell the maintainers at <bug-m4@gnu.org> if you feel like volunteering
for any of these ideas or if you have others to add.
* KNOWN BUGS
+ The following patch needs to be ported from the branch:
http://lists.gnu.org/archive/html/m4-patches/2007-03/msg00005.html
May be a couple of issues in that thread.
+ The format builtin needs more power to be like printf(1):
http://lists.gnu.org/archive/html/m4-discuss/2007-05/msg00015.html
But be aware of compatibility issues in making too many changes.
+ The test case `other-tests/stackovf.test' does not work.
+ stack overflow is basically broken
The routines to detect stack overflow throuh segv are basically
broken. The idea may be fine, but it ends up calling a sigv handler
that uses gettext, printf, stdout... all of which are definitely NOT
sig-safe. Pity, because the hardcode routine is basically very careful
to use write(2), to avoid this.
I haven't checked that translation magic is signal-safe.
- I doubt it;
- stdio is not signal-safe in any kind of portable setting anyways.
--
Marc Espie
espie@schutzenberger.liafa.jussieu.fr
Perhaps the gnulib c-stack module or libsigsegv would be useful:
http://lists.gnu.org/archive/html/bug-gnu-utils/2008-01/msg00042.html
* FEATURES OR PROBLEMS
+ m4 should keep an ``execution stack'' of macros, which applications could
use in their error messages.
+ Implement discarding comment delimiters with the syntax table.
+ Implement qindir. Like indir, except that the result of the macro call
is not expanded. Because the input stack might contain a file or a
string, it is probably best achieved by making note that the TOS input
should be copied rather than rescanned.
$ echo "a'b" > f
$ m4
define(a,z)dnl
include(f)dnl
z'b
indir(`include', f)dnl
z'b
qindir(`include', f)dnl
a'b
define(b,NONO)dnl
patsubst(qindir(`include', f), `b', x)
z'x
+ Use the TOS input quoting for qindir to fix this undesirable POSIX
behavior:
define(`x', -'-)
define(y, defn(`x'))
y
--'
--
Stepan Kasal <kasal@ucw.cz>
+ If configured --with-gmp for multiple precision arithmetic there are
some warnings, but it passes the tests.
+ Make m4 show include dependencies like gcc so Makefile targets are
updated when their (included) input files are updated (Erick B).
+ Add support for wide character sets.
* OPTIMIZATION AND CLEAN UP
+ Have NULs go really undisturbed through GNU m4
GNU m4 is lousy regarding NULs in streams (this would require
maintaining the string lengths, and avoiding strlen, strcpy,
etc.). (Almost there, once argv_ref is ported).
+ The argument count limits are handled for all tokens passed around by
the internals: we should enable attaching these values to text macros
too.
+ The context parameter is just a placeholder for formerly global state.
We should be making the library reentrant so that multiple instances
of m4 can be run in the same process at the same time.
+ The path management stuff (in path.c/m4private.h) is reinventing the
wheel. There are a bunch of fast path management and search functions
in ltdl.c: These need to be sanitized, exported through ltdl.h, and
then wrapped by the m4module.h path api. path.c can probably be removed
entirely at that point.
* MODULE SPECIFIC ISSUES
+ Some way of linking a module statically is needed, for systems
without support for dynamic loading.
+ Some sort of module interface versioning system needs to be implemented
in the module loader and the freezer so that m4 can tell if it is being
asked to load a frozen file that requires versions of modules with
interface versions unsupported by the current release.
+ The module API should probably use functions, not data exports:
http://lists.gnu.org/archive/html/m4-patches/2007-09/msg00012.html
Actually, there are several good ideas for module in that thread.
+ Setting of the module search path within m4 scripts:
append(__modulepath__, `/some/modules/live/here')
+ Module autoloader. This would allow an m4 core with no builtins except
for loadmodule(). A default startup script would mark the recognised
set of builtins for autoload from the installed module directory on first
use. A new cli parameter would inhibit initialisation from this script,
so that customised m4 interpreters could be built on the fly!
+ The module loader needs to differentiate between modules that are in
memory and modules that are loaded (i.e. visible) from various context
structures.
+ The perl module should only be built if a suitable perl interpreter
is found on the build machine. For that matter, it has been a
while since the perl module has even been built, and perl has had
new releases in the meantime.
Local Variables:
mode: outline
outline-regexp: " *[-+*.] \\| "
End:
Copyright (C) 2000, 2006, 2007, 2009, 2010 Free Software Foundation,
Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts. A copy of the license is included in the ``GNU Free
Documentation License'' file as part of this distribution.
|
