clibs / buffer Goto Github PK

adding #include <sys/types.h> fixes this:

src/buffer.h:64:1: error: unknown type name ‘ssize_t’
src/buffer.h:68:43: error: unknown type name ‘ssize_t’
src/buffer.h:70:1: error: unknown type name ‘ssize_t’
src/buffer.c:87:1: error: unknown type name ‘ssize_t’
src/buffer.c:197:42: error: unknown type name ‘ssize_t’
src/buffer.c:228:1: error: unknown type name ‘ssize_t’

compiler

$ gcc --version
gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

result

buffer.c: In function ‘buffer_slice’:
buffer.c:248:10: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (to < from) return NULL;
          ^
buffer.c:254:10: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (to > len) to = len;
          ^
buffer.c: In function ‘buffer_print’:
buffer.c:347:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   for (i = 0; i < len; ++i) {

Hello all,
I have come across an issue where for what appears to be no good reason buffer_prepend doesn't work as expected. I used the test.c buffer_prepend test as a template:

    buffer_t *buf = buffer_new();
    buffer_append(buf, " World");
    buffer_prepend(buf, "Hello");
    printf("HW: %s\n", buf->data);

Which returns:

HW: Hello World

As expected, but the following:

    buffer_t *file = buffer_new();
    buffer_append(file, "layout.bk.html");
    buffer_prepend(file, "./example/");
    printf("BASED: %s\n", file->data);

returns:

BASED: ./example/layout.bk.h

Cutting off the "tml" on the end of the file path.

I have played with the memmove function call and the only way I could get it to be reasonable was to have it copy the length of the "needed" length and not the length of the string to prepend. This could cause a write into memory not allocated for that buffer, so that is right out.

Not sure where to go from here.
Thanks,
Adam.

I'm confused by the .alloc member of buffer_t – it seems to always point to the same memory as .data.

One reason to have separate pointers for data and allocated data would be if the buffer could be passed in some initial space to use. Maybe something like this:

char buf[BUFFER_DEFAULT_SIZE];
struct buffer_t buffer;
buffer_init(buf, BUFFER_DEFAULT_SIZE);

after which buffer.data would point to the memory at buf, but buffer.alloc would be null. After pushing more than BUFFER_DEFAULT_SIZE characters into the buffer I would expect a realloc, after which .data and .alloc would point at the same piece of heap memory.

This is not how the code works though – the buffer is always heap allocated.

Possbile solutions:

• allow user to pass in a block if initial memory (that .alloc would not reference)
• remove the .alloc member

/cc @tj