[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Disable #error?
From: Sean Silva <silvas () purdue ! edu>
Date: 2014-01-15 21:09:07
Message-ID: CAHnXoakrTGMULVE=HuT+Wxpx+g_Uv9Rkqi5HQ6E0PkRx-fX-sQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jan 15, 2014 at 2:38 PM, Jacob Carlborg <doob@me.com> wrote:
> On 2014-01-15 18:39, Sean Silva wrote:
>
> You are trying to understand the meaning of the program, which means
>> that you are under the same correctness constraints as when compiling.
>>
>
> I want the tool to understand enough to do the translation.
>
>
> Consider:
>>
>> #if defined(FOO)
>> #error "bar"
>> void
>> #else
>> int
>> #endif
>> some_function(int arg);
>>
>> If you ignore the #error, you will misunderstand the program's semantics.
>>
>
> I do understand what you're saying but I don't see any other way.
The cleanest thing in your particular usecase is to just ignore that header
if you hit that sort of #error, since you will end up including it through
it's "proper" user-facing header when processing a different header. Or is
there some impediment to doing that?
Otherwise, it's really a discussion about "where do we put in a gross hack
to trample the source code's intent and forcibly ignore the check and
#error". That gross hack could be in clang, it could be done by sed, it
could be done in memory on the file buffers, it could be done by detecting
such errors and reparsing with -D__INCLUDED_UMBRELLA_H (or whatever the
guard macro is), or any of a number of techniques. Without a really
compelling use case, my gut is to not want that hack to live in clang.
-- Sean Silva
> The feature would probably be off by default with a flag to enable it. The
> user is free to use it if he/she wants to.
>
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, \
Jan 15, 2014 at 2:38 PM, Jacob Carlborg <span dir="ltr"><<a \
href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="im">On 2014-01-15 18:39, Sean Silva wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You are trying to understand the meaning of the program, which means<br>
that you are under the same correctness constraints as when compiling.<br>
</blockquote>
<br></div>
I want the tool to understand enough to do the translation.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Consider:<br>
<br>
#if defined(FOO)<br>
#error "bar"<br>
void<br>
#else<br>
int<br>
#endif<br>
some_function(int arg);<br>
<br>
If you ignore the #error, you will misunderstand the program's semantics.<br>
</blockquote>
<br></div>
I do understand what you're saying but I don't see any other \
way.</blockquote><div><br></div><div>The cleanest thing in your particular usecase is \
to just ignore that header if you hit that sort of #error, since you will end up \
including it through it's "proper" user-facing header when processing a \
different header. Or is there some impediment to doing that?<br> \
</div><div><br></div><div>Otherwise, it's really a discussion about "where \
do we put in a gross hack to trample the source code's intent and forcibly ignore \
the check and #error". That gross hack could be in clang, it could be done by \
sed, it could be done in memory on the file buffers, it could be done by detecting \
such errors and reparsing with -D__INCLUDED_UMBRELLA_H (or whatever the guard macro \
is), or any of a number of techniques. Without a really compelling use case, my gut \
is to not want that hack to live in clang.</div> <div><br></div><div>-- Sean \
Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> \
The feature would probably be off by default with a flag to enable it. The user is \
free to use it if he/she wants to.<div class=""> <div class="h5"><br>
<br>
-- <br>
/Jacob Carlborg<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br> \
</div></div></blockquote></div><br></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic