Re^2: [Ceph::RADOS] Help Debugging Inline C

Awesome! Thanks for this.

The first thing I did was add the debugging string, which returned a negative number. Thanks for pointing out where in the original code the negative number was coming from.

Ultimately, replacing the NULL with "" did the trick and I no longer get a segfault!

Any thoughts on moving Inline_Stack_Vars to the beginning of the sub definition?

That sounds like something that would be worth filing a bug report about. What is your reasoning behind the prototyping?

Thanks for your help. If you have any more, general advice on writing a Perl wrapper around a C API I'd love to hear it. This is my first foray into trying to extend a C library so I've got a bit of learning to do :)

Thanks again for your help!

Comment on Re^2: [Ceph::RADOS] Help Debugging Inline C

Replies are listed 'Best First'.
Re^3: [Ceph::RADOS] Help Debugging Inline C by oiskuu (Hermit) on Nov 11, 2013 at 09:33 UTC
Regarding rados library and the `rados_pool_list()` — seeing that code instantly reminded me of snprintf. The snprintf/vsnprintf functions return n. of chars that would have been written with large enough buffer. The length argument is `size_t`, whereas return type is `int`... (Historical stdio matter?) SUSv2 and C99 are in disagreement concerning a snprintf call with len==0; with C99 allowing buf==NULL in that case. The `ssize_t` type allows a -1 error return where a `size_t` would otherwise be suitable. Like e.g. read() or pwrite.	[reply]
Re^3: [Ceph::RADOS] Help Debugging Inline C by Anonymous Monk on Feb 25, 2014 at 05:44 UTC
hi I am looking forward the "perl library" for RADOS. could you share the code with me. thanks	[reply]
Re^4: [Ceph::RADOS] Help Debugging Inline C by mlsorensen (Initiate) on May 21, 2014 at 05:49 UTC
Hi guys. I just did a search and noticed people were actually using the proof of concept code I dumped. I have committed it into a github repo: https://github.com/mlsorensen/perl-Ceph-Rados And fixed the list pools as mentioned. It still needs some work, but github is a better place to collaborate if people are improving it.	[reply]