enumerateObjectsWithOptions:usingBlock - runtime error "incorrect signature"

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

enumerateObjectsWithOptions:usingBlock - runtime error "incorrect signature"

Tom Sheffler
I have the following code

  [mutarray enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(NSObject *o, NSUInteger idx, BOOL *stop) {
    ...}];

This compiles and runs fine on one installation of gnustep on Ubuntu16, but on a different installation, I get the following runtime error:

Calling [GSMutableArray -enumerateObjectsWithOptions:usingBlock:] with incorrect signature.  Method has v32@0:8Q16^{?=^vii^?}24, selector has v32@0:8Q16@?24

I believe my failing installation has an older version of gnustep-base.  Both use clang 3.8.0-2ubuntu4.  Both installations of gnustep are from git repos.  I believe the failing one is an older installation, so I am not very concerned about it.  But I am wary.

Has anyone else seen this?  I tried modifying the block in a number of ways, and couldn’t find an incantation that worked.

Thanks,
Tom


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: enumerateObjectsWithOptions:usingBlock - runtime error "incorrect signature"

David Chisnall-4

> On 27 Nov 2017, at 17:25, Tom Sheffler <[hidden email]> wrote:
>
> I have the following code
>
>   [mutarray enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(NSObject *o, NSUInteger idx, BOOL *stop) {
>     ...}];
>
> This compiles and runs fine on one installation of gnustep on Ubuntu16, but on a different installation, I get the following runtime error:
>
> Calling [GSMutableArray -enumerateObjectsWithOptions:usingBlock:] with incorrect signature.  Method has v32@0:8Q16^{?=^vii^?}24, selector has v32@0:8Q16@?24
>
> I believe my failing installation has an older version of gnustep-base.  Both use clang 3.8.0-2ubuntu4.  Both installations of gnustep are from git repos.  I believe the failing one is an older installation, so I am not very concerned about it.  But I am wary.
>
> Has anyone else seen this?  I tried modifying the block in a number of ways, and couldn’t find an incantation that worked.

It looks as if the caller knows that this is a block (encoding: @?), but the callee is not block aware.  If GNUstep is compiled by a compiler without blocks support, then it falls back to declaring the methods taking a pointer to a block structure and calling them by manually dereferencing the field that contains the invoke function.

There’s nothing to worry about here, unless you want to override the enumerateObjectsWithOptions:usingBlock: method in a subclass, at which point you’ll have some surprising behaviour!

Recompiling GNUstep-base with clang (possibly including rerunning configure if this is a configure-time check) should make this go away.

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep