On Wed, Dec 25, 2013 at 8:13 AM, Durand Jean-Damien <
[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 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 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].
>> 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].
For more options, visit https://groups.google.com/groups/opt_out.
