Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__attribute__ #7

Open
ghazel opened this issue Feb 17, 2014 · 2 comments
Open

__attribute__ #7

ghazel opened this issue Feb 17, 2014 · 2 comments

Comments

@ghazel
Copy link

ghazel commented Feb 17, 2014

It might be ambitious, but I'm trying to parse /usr/include/math.h (on OS X)

Here's what I have so far:

f = '/usr/include/math.h'
prep = C::Preprocessor.new
# XXX: bug #4
prep.pwd = File.expand_path('.')
source = prep.preprocess_file(f)
# XXX: there seem to still be some '#' lines, which cause Cast to choke
source.gsub!(/(^\#.+)/, '')
begin
  ast = C.parse(source)
rescue C::ParseError => e
  p e
  # XXX: feature request #3
  line_num = e.message.match(/\d*/)[0].to_i
  puts source.lines.to_a[line_num-1]
end

The output of which is:

#<C::ParseError: 32:0: parse error on LPAREN (LPAREN)>
inline __attribute__ ((__always_inline__)) int __inline_isfinitel(long double);

So my guess is Cast doesn't support __attribute__, which I understand is not part of the C spec, but unfortunately is somewhat common in actual code. Description here: http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html with all its infelicities.

@oggy
Copy link
Owner

oggy commented Feb 18, 2014

Can you just add __attribute__ as a macro that expands to nothing?

I think adding explicit support for this will be something of a slippery slope. Each compiler seems to do its own weird thing.

If there was a good way to package up compiler-specific tweaks for stuff like this, I'd go for it, but I don't have the time to implement it myself. Happy to discuss if it's something you're keen to send a PR for. :)

@alexdowad
Copy link

I have an implementation of __attribute__ ready. Just waiting to see if my first PR will be accepted before opening that one.

In response to @oggy's concern, one option would be to add separate classes C::Parser::ANSI and C::Parser::GNU, one which just accepts "vanilla" C, and one which accepts all the GCC extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants