-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[re-adding m4-discuss, to widen the audience concerning your proposed option]
According to Raphael 'kena' Poss on 7/8/2009 3:16 AM:
> as you suggested I reworked the patch from 1.6, and included documentation
> with example and test code. Let me know if there is anything else to improve.
I probably won't look at this closer until your copyright papers come
through. But a first very general comment:
POSIX states that 'm4 -s' must:
| Enable line synchronization output for the c99 preprocessor phase (that
| is, #line directives).
If our synclines are not suitable with the c99 preprocessor already, then
we are not compliant with POSIX. But naming a new option --synclines-cpp
makes it sound like synclines are not c99-ready unless you use this new
option. That is, until I read your documentation of the option:
> +...@item --synclines-cpp
> +
> +This provides identical behavior to @option{-s} or @option{--synclines},
> +but with a different synchronization line format suitable for a C
> +compiler without a C preprocessor. With this option synchronization
> +lines are of the form @samp{# @var{line} "@var{file}"}. This format is
> +suitable when M4 is used as a substitute to the C preprocessor or as a
> +filter between preprocessing and compilation.
Which is NOT a cpp-parseable line directive (rather, it is a c99
non-directive), so it is the exact opposite of what you are proposing
naming this option. Furthermore, there is no standard-compliant C
compiler that does not have a preprocessor; c99 5.1.1.2 states that a
non-directive is discarded between the preprocessing phase (4) and
translation phase (phases 5-8). So in effect, what it looks like you are
trying to introduce is an option to make m4 line directives NOT affect C99
preprocessing (ie. they will be silently ignored by the c99 preprocessor,
without affecting the c99 magic macros __LINE__ and __FILE__), but still
be recognizable enough for a human reading the file to still correlate the
lines back to previously preprocessed source code. If that is the case,
then you need a better name than --synclines-cpp; and preferably one that
does not introduce ambiguities so that people can still use 'm4 --sync' as
a shortcut for 'm4 --synclines'.
And if we do add that as an option, we should break this into multiple
patches - one that adds an optional argument to __line__/__file__, and
another patch that introduces the new option, rather than doing it all in
one patch.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpUkn0ACgkQ84KuGfSFAYCsAwCgjdQbb9AP8zpjvm9D8z4X9Mde
U2sAnjESIJ0kS0H1EKRFglCsN9vb7Pnf
=mlqE
-----END PGP SIGNATURE-----
_______________________________________________
M4-patches mailing list
M4-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-patches
