Ok, I think you are bit confused about the calls. A couple of posts ago, you wrote:
Now for the source of your problem (I think):
XS(XS_Net__LibnetRaw_libnet_init_packet)
[...]
u_char * buf = (u_char *)SvPV(ST(1),PL_
+na);
[...]
RETVAL = libnet_init_packet(p_size, &buf);
sv_setpv((SV*)ST(1), buf);
This function seems to have used a different typemap for buf which is trying to extract the '\0'-terminated string that it is supposed to point to. I
think all you need to do is fix this typemap to be like the other functions.
I'm going to check some other things I noticed and I'll reply separately if I detect any problems.
It seems that you are under the impression that libnet_init_packet() and functions like libnet_do_checksum() have the same prototype for buf. They don't. As per my original post, the prototype for libnet_init_packet() is<
int libnet_init_packet(size_t p_size, u_char **buf);
This function asks for a pointer to a pointer. So the pointed-to pointer (confusing, I know...) is being altered. This is how the function gets the pointer returns from malloc() back to the program. The other functions are prototyped like this:
int libnet_build_ip([...], u_char *buf);
The pointer itself is not being modified so the pointer to a pointer is unnecessasry. But the data being pointed to is. If I understand correctly, you thought that this was the way in wich libnet_init_packet() and libnet_destroy_packet() were also prototyped.
So my feeling is that, like a C program would using this library, the value stored in the top level of the program in $buf should be a pointer. In C, I usually do something like this:
u_char *buf;
libnet_init_packet(IP_H + TCP_H, &buf); /* This calls malloc() and set
+s buf as a pointer to that new memory */
[...]
libnet_build_ip([...], buf); /* The pointer value is the same, but dat
+a pointed to is altered */
So essentially I am attempt to make the perl calls the same. I did try it some others ways, based on your suggestions and my own tinkering. In the past couple of days, I have tried a few things. Not being experience with XS, I am obviously confused on some issues. The unary & was one example.
For now, though, I don't have a lot of time to devote to contemplating this problem. I still have some ideas that I might attempt to bounce off this thread in the future. | [reply]
[d/l]
[select] |
Yes, I flip-flopped between thinking that all of the functions used u_char **buf and thinking what you just described. So parts of what I wrote may be a bit confusing (sorry, and more on this later). But my final analysis is correct based on what you write above.
You need to have all of the functions use u_char *buf or u_char * &buf and nothing else. The typemap defines a way to convert between a u_char * and a Perl UV (unsigned long integer). The & tells XS to use &buf as the argument to the function. So you specify the & when the function expects u_char **buf.
Where you quote me above, I have quoted code that shows that XS is trying to convert to/from a Perl PV (string) instead of a UV. This probably means that you used char *buf instead of u_char *buf. So what I wrote wasn't due to confusion about whether buf was a pointer or a pointer-to-a-pointer for that case.
You do need to use the same typemap (u_char *) for all of the functions. It is just that some also need the & as well.
The Perl variable, $buf, will hold an unsigned integer value that is the value of the u_char * pointer (just typecasted).
Does that make more sense?
-
tye
(but my friends call me "Tye")
| [reply]
[d/l]
[select] |