On Wed, Dec 25, 2013 at 8:13 AM, Durand Jean-Damien
<[email protected] <mailto:[email protected]>> wrote:
Thanks for this feedback. All of them has been pushed on my todo
list, and you will get feedback progressively.
Right now, I have fixed the grammar (gcc __extension__ keyword was
misplaced) and have released a new version of
MarpaX::Languages::C::AST. Which parses successfully the
perl-5.18.1 sources, increasing the confidence level on c2ast.pl
<http://c2ast.pl> to a quite high value -;
Great news; congratulations.
I just wondered can it be useful if MarpaX::Languages::C::AST had a
dump() method to re-produce the source C text?
Such reproduced file would then be shown
to be the same as the original C (no textual diff, sans whitespace
perhaps)
to do the same (no binary diff perhaps?) as the original C file
when compiled with the same compiler.
Naive as it is, but hopefully helpful?
Thanks / JD.
Le mercredi 25 décembre 2013 01:08:22 UTC+1, Jeffrey Kegler a écrit :
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 <http://c2ast.pl>
options. In particular, I had a lot of problems with it
"failing" silently when I got the options wrong. c2ast.pl
<http://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 <http://c_reserved.pl>. This
would make the options even simpler. Also, I think a separate
c_reserved.pl <http://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
<http://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]>
[ 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].
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.
--
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]
<mailto:marpa-parser%[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.
