Hello,
I have tried to improve the parsing of C code recently. The main changes,
currently available on github, are as follows:
1. More aggressive inclusion of header files, combined with caching of
header files. Now if there is only one occurrence of a header file with a
given name in the pro
Julia,
1. More aggressive inclusion of header files, combined with caching of
header files. Now if there is only one occurrence of a header file with a
Caching can be dangerous because macros may be defined differently
for different includes of the same header. An option to switch off
cachi
On Tue, 22 Aug 2017, Derek M Jones wrote:
> Julia,
>
> > 1. More aggressive inclusion of header files, combined with caching of
> > header files. Now if there is only one occurrence of a header file with a
>
> Caching can be dangerous because macros may be defined differently
> for different i
On Tue, 22 Aug 2017, Derek M Jones wrote:
> Julia,
>
> > 1. More aggressive inclusion of header files, combined with caching of
> > header files. Now if there is only one occurrence of a header file with a
>
> Caching can be dangerous because macros may be defined differently
> for different i
Julia,
The Linux kernel has some declarations like
type fn(a1, a2) >
with no trailing ; followed by a function definition. This gives a parse
error on a1. In the previous version, Coccinelle was able to recover an
The K&R style. Perfectly legal C.
Basically the recovery process is focuse
On Wed, 23 Aug 2017, Derek M Jones wrote:
> Julia,
>
> > The Linux kernel has some declarations like
> >
> > type fn(a1, a2) >
> > with no trailing ; followed by a function definition. This gives a parse
> > error on a1. In the previous version, Coccinelle was able to recover an
>
> The K&R st
Julia,
I don't think that is what it is. The declarations are eg:
static inline __printf(2, 3)
void _dev_info(const struct device *dev, const char *fmt, ...)
{}
I guess that the whole first line is part of the declaration of _dev_info,
but Coccinelle can't cope with the __printf(2, 3).
http
On Wed, 23 Aug 2017, Derek M Jones wrote:
> Julia,
>
> > I don't think that is what it is. The declarations are eg:
> >
> > static inline __printf(2, 3)
> > void _dev_info(const struct device *dev, const char *fmt, ...)
> > {}
> >
> > I guess that the whole first line is part of the declaration
> At least for the Linux kernel, you can't just run one make and get all the
> files to be compiled. Some files are indeed very hard to compile.
How do you think about to point any specific source code examples out
which you find a bit too challenging so far?
Regards,
Markus
> I have tried to improve the parsing of C code recently.
This information is useful.
> 1. More aggressive inclusion of header files,
Why do you need to become “aggressive” there when the corresponding
data processing should be just correct?
> combined with caching of header files.
How do y
>> If it's yacc based you can recover where ever you like. Knowing how to
>> do it is something of a black art.
> Well, ocamlyacc, to be precise.
Can the software “Menhir” help any more for the needed data processing?
http://gallium.inria.fr/%7Efpottier/menhir/
Regards,
Markus
_
> Actually, I noticed that unfolding macros can sometimes hurt more than it
> helps.
Would you like to discuss (or explain) involved implementation details
and configuration parameters any more?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6
On Thu, 24 Aug 2017, SF Markus Elfring wrote:
> > Actually, I noticed that unfolding macros can sometimes hurt more than it
> > helps.
>
> Would you like to discuss (or explain) involved implementation details
> and configuration parameters any more?
#define FOO(x) BAR(x,+,y)
int foo() __xxx(
> Parsing of foo fails due to the attribute __xxx(yyy) that Coccinelle is
> not able to cope with.
Why does the parsing software struggle with such input data so far?
> Coccinele hopes that expanding macros will solve the problem.
Why do you need to “hope” something if the software could be des
> Parsing of foo fails due to the attribute __xxx(yyy) that Coccinelle is
> not able to cope with.
* Do you find information relevant from answers to a question like
“Context-free grammars versus context-sensitive grammars?”?
https://stackoverflow.com/questions/8236422/context-free-grammars-v
On 24/08/2017 16:23, SF Markus Elfring wrote:
More importantly; does Julia like red jelly beans more than blue jelly
beans?
* Do you find information relevant from answers to a question like
“Context-free grammars versus context-sensitive grammars?”?
https://stackoverflow.com/questions/8
> More importantly; does Julia like red jelly beans more than blue jelly beans?
Would you like to discuss favourite sweets more than to clarify
further improvements in parsing technology also for application
together with the Coccinelle software? ;-)
Regards,
Markus
17 matches
Mail list logo
