Hum ... this has potential.
struct ipv4_addr_struct {
C_header tag;
uint8_t *octets;
};
typedef struct ipv4_addr_struct ipv4_addr;
static const C_header BTREE_TAG =
((sizeof(ipv4_addr) - sizeof(C_header)) /
sizeof(C_word)) | C_BYTEVECTOR_TYPE;
Actually, a
Actually, the bytes should probably be allocated in the structure,
right?
struct ipv4_addr_struct {
C_header tag;
uint8_t octets[4];
};
typedef struct ipv4_addr_struct ipv4_addr;
static const C_header BTREE_TAG =
((sizeof(ipv4_addr) - sizeof(C_header)) /
Hi,
After considering your comments (Dan Felix), reading the documents, and
some experimentation, I have a solution.
I decided to use atomic data. I believe the C_BYTEBLOCK_BIT is for the GC
and C_BYTEVECTOR_TYPE is the scheme type. The size is in bytes because it
is a byte vector, right?
Hi,
A function in pcap-interface.c calls Chicken Scheme. It builds a vector
containing a bunch of things, e.g. C_fix(ethtype), and the source and
destination addresses as vectors. The scheme code converts the address
vectors to u8vector (u16vector for IPv6). This is a lot of work: just
under
There's a section on accessing external objects that covers this sort of
thing:
http://wiki.call-cc.org/man/4/Accessing%20external%20objects#returning-large-objects-or-chunks-of-memory-to-scheme
It's possible to allocate C structures under the control of the Chicken GC:
On Thu, 27 Jun 2013, Dan Leslie wrote:
There's a section on accessing external objects that covers this sort of
thing:
http://wiki.call-cc.org/man/4/Accessing%20external%20objects#returning-large-objects-or-chunks-of-memory-to-scheme
This addresses a different issue. The PCAP event handler
Hi,
Actually, the bytes should probably be allocated in the structure, right?
struct ipv4_addr_struct {
C_header tag;
uint8_t octets[4];
};
typedef struct ipv4_addr_struct ipv4_addr;
static const C_header BTREE_TAG =
((sizeof(ipv4_addr) - sizeof(C_header)) /
