[LLVMbugs] [Bug 17482] New: attribute cleanup will not accept blocks, enforces stricter typing than gcc

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Oct 4 18:00:25 PDT 2013


http://llvm.org/bugs/show_bug.cgi?id=17482

            Bug ID: 17482
           Summary: attribute cleanup will not accept blocks, enforces
                    stricter typing than gcc
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jeremiah at gowdy.me
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I am trying to find a better workaround for the RAII_VARIABLE implementation
used with attribute(cleanup).  I have noticed two issues that make it difficult
to work around the lack of nested functions.  First, the cleanup attribute in
Clang is very strict about the parameter type and doesn't allow the cleanup
function to have a more generic parameter type like void dtor_foo(void* *p). 
Second, I would think that Clang's blocks alternative to nested functions would
be a great answer to how to use RAII_VARIABLE with Clang, but unfortunately
cleanup is disinterested in accepting a block in place of the cleanup function
name.  Third, I tried casting the block variable to a block struct and passing
cleanup the invoke function but it is also not interested in taking a function
pointer and injecting a runtime invoke of that as the cleanup function.

Watching the BSD camp deal with ports of Linux software that expects to be able
to use the cleanup extension in a useful way, they seem to be having to patch
the code to use two macros, one inside the function for the local/auto
variables, and one outside the function to be able to create the cleanup
function.  These patches aren't very welcome upstream as they only make it
harder to maintain the code.

My suggestion would be to make clang capable of accepting its own blocks
feature as a parameter for cleanup, perhaps even limiting it to a block
literal.  I'm very interested in other suggestions to solve this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131005/725a7781/attachment.html>


More information about the llvm-bugs mailing list