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

[NCI] callback sub parameter definition isn't unified with callback definition in the C lib. #595

Open
zhuomingliang opened this issue Jan 30, 2011 · 1 comment

Comments

@zhuomingliang
Copy link
Contributor

Hello,
see https://github.com/parrot/parrot/blob/master/src/nci_test.c#-115 , there are two define here.

typedef void (*cb_C1_func)(const char*, void*);
PARROT_DYNEXT_EXPORT void nci_cb_C1(cb_C1_func, void*);

the callback is created by:

     cb_wrapped = new_callback cb, user_data, "vtU"

which means it's first parameter is external_data, and the two is user_data. that is, the callback function should be defined as this one:

.sub _call_back
  .param string external_data
  .param pmc user_data
  print "user data: "
  print u
  print "\n"
  print "external data: "
  print s
  print "\n"
.end

but actually in t/pmc/nci.t, it's defined as:

.sub _call_back
  .param pmc user_data
  .param string external_data
  print "user data: "
  print u
  print "\n"
  print "external data: "
  print s
  print "\n"
.end

according to t/pmc/nci.t it seems that no matter user_data is the first parameter or two, the callback sub must be defined as:

.sub _call_back
  .param pmc user_data
  .param string external_data
.end

then I took a look at PDD16, and it's said user_data should be defined in the second parameter:

.sub _call_back
  .param string external_data
  .param pmc user_data
.end

which is right.

Originally http://trac.parrot.org/parrot/ticket/1992

@plobsing
Copy link
Contributor

plobsing commented Feb 3, 2011

It is true that the callback parameters are inconsistent between C and PIR. However, it does mean that all callbacks defined from within parrot are consistent, regardless of dissagreements between C libraries.

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

No branches or pull requests

2 participants