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 to a quite high value -;
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 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 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 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 --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] <javascript:>.
> 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.
