As I've said before, I think this C parser is a remarkable new tool,
something that has been needed for decades. Getting out the last few
nits is annoying, but each of those last few steps adds a surprising
amount to way the user experiences the tool.
By the way, when I was using it (and I encountered no bugs when using it
to deal with the Marpa source), I did note some things which I thought
might make the tool more "cuddly" from the user's point of view.
1.) An option (--stdin?) to accept the pre-processed C source on
standard input. This makes getting things right with the options
easier. You first get the pre-processor options right, separately.
Then you can eyeball the pre-processed C to see it's right. Finally,
you work out the (now far fewer) options to c2ast. And with a --stdin
option, you can do other things like capture the pre-processed C in a
file, for debugging.
2.) More error messages on the c2ast.pl options. In particular, I had a
lot of problems with it "failing" silently when I got the options
wrong. c2ast.pl was not really failing -- it's just that I did not have
the options right. But I think the option processing in c2ast could be
more helpful.
3.) Factor the checking of reserved names into a separate tool, perhaps
c_reserved.pl. This would make the options even simpler. Also, I think
a separate c_reserved.pl could then act as an example of the use of
MarpaX::Languages::C::AST for study.
Thanks, jeffrey
On 12/24/2013 02:59 PM, Durand Jean-Damien wrote:
Damned, c2ast failure on gcc __extension__, ... Will see tomorrow -;
Probably another release of MarpaX::Languages:C::AST when fix found.
else if ((!__extension__ ({ size_t __s1_len, ...
--------------------------^
Uncaught exception from user code:
at /usr/local/share/perl/5.18.1/MarpaX/Languages/C/AST.pm
line 109.
MarpaX::Languages::C::AST::Util::logCroak('%s\x{a}Last
position:\x{a}\x{a}%s%s', 'Error in SLIF parse: No lexemes accepted at
line 18736, colum...', 'line:column 18736:27 (Unicode newline count)
18736:27 (\n cou...', '') called at
/usr/local/share/perl/5.18.1/MarpaX/Languages/C/AST.pm line 109
MarpaX::Languages::C::AST::parse('MarpaX::Languages::C::AST=HASH(0xb392654)',
'SCALAR(0xa702f78)') called at /usr/local/bin/c2ast.pl line 126
Le mardi 24 décembre 2013 19:35:14 UTC+1, Jeffrey Kegler a écrit :
A blog post sounds good. More people should know about this issue
-- even if you don't find fixing legacy code to be worth the
bother, it *is* good to know enough not to write new code with
reserved names. And p5p, etc., will then be free to give the
current issues in the Perl source whatever priority they see as
appropriate.
As context, the C standards reserve certain names to the
"implementation", which means the compiler implementation,
including the C libraries. Your own applications and libraries
are not allowed to use reserved names. These names were reserved
back before namespace issues were well understood. In many cases
there are unnecessarily overbroad and can be called mistakes, but
they are mistakes that we are stuck with. I personally find the
bans on E[A-Z0-9]*, is[a-z]* and to[a-z]* all to be real
nuisance. If you have a variable named "token", you are using
reserved namespace, and an implementation upgrade could cause
unspecified behavior as a result. Or how about the "stream_state"
variable? Banned -- str[a-z]* is reserved for new string
functions. The GNU docs summarize them nicely here
<http://www.gnu.org/software/libc/manual/html_mono/libc.html#Reserved-Names>.
The full list is hard to memorize and C programmers, even at the
highest skill level, often ignore them. Before Jean-Damien created
it at my request, there was (as far as I know) no tool to detect
violations. I was aware of these issues, and believed that I was
writing Marpa to be fully compliant, but c2ast.pl
<http://c2ast.pl> found many issues I'd missed.
So a blog post would be a real service.
-- jeffrey
On 12/24/2013 07:08 AM, Durand Jean-Damien wrote:
Jeffrey,
Nice idea, I'll do so, guessing that posting to blogs.perl.org
<http://blogs.perl.org> could have a better and perhaps more
appreciated audience than directly to p5p or perlbug (?).
Thanks / JD.
2013/12/24 Jeffrey Kegler <[email protected] <javascript:>>
[ Off-line from the group ] An exercise which might help the
Perl community (and in the process bring attention to c2ast),
would be to run a c2ast.pl <http://c2ast.pl> --check
reservedNames on the Perl source, and submit it to
perl5-porters (or perlbug?).
[...] Cleaning up the namespace will be hard -- the Perl
source intrudes on the reserved namespace heavily. And many
people may not realize the reason to keep the namespace clean
-- it'll seem like a lot of work to deal with something that
is not an issue.
I'm emailing you direct off-line because you're the obvious
first-choice to do this. If you like the idea, reply back
into the main list. Otherwise, I may throw this open to the
list as a "Target of Opportunity".
-- jeffrey
--
You received this message because you are subscribed to the
Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google
Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "marpa
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
