For example, htslib/sam.c's sam_hdr_read() calls sam_hdr_parse(0, NULL) when the SAM file has no header lines. This crashes, while sam_hdr_parse(0, "") would be correct.

I also attempted to add ks_init(kstring_t*) and ks_destroy(kstring_t*) functions as wrappers so client code would not need to know exactly which fields to initialise to 0/NULL and which to free. However these names are unfortunately already taken by kstream_t in kseq.h.

Any thoughts about what to do here? Probably kstring_t is simple enough that a comment showing what to set to zero suffices. Another option would be to add a macro like the following to kstring.h:

#define EMPTY_KSTRING { 0, 0, NULL }

so that client code could write

kstring_t str = EMPTY_KSTRING;

I would be happy to add a init/destroy comment or such a macro to this pull request.

@attractivechaos @lh3

I am trying to figure out the types of alignment based on the function names, guessing the following:

• ksw_align - local alignment: a sub-sequence of the query aligned to a sub-sequence of the target
• ksw_extend - a prefix of the query aligned to a prefix of the target**
• ksw_global - alignment of the full query to the full target

** doesn't behave this way, which is why I am asking

Also, I have a ksw_glocal implementation if you are looking for a contribution.

Hi, I'd like to request adding a license file to this repo. Right now most files have a header that says the license is MIT, and the README says MIT/X11, but there are also files without license headers (e.g. keigen.c) and just a sentence in the README isn't really enough.

Also, GitHub's license detection will say that Klib as a whole does not have a license: https://github.com/attractivechaos/klib/community

I'm happy to open a PR if that would help.

Hi!

I noticed that khash is very sensitive to the choice of hash function for >= 64bit keys (not so for 32bit keys). In particular kh_int64_hash_func() is extremely slow with random input. Does anyone have a similar experience? Is it expected to have wildly varying results based on the choice of hash function?

Thanks!

KHASH_DECLARE declares with extern, but KHASH_INIT is replaced with KHASH_INIT2(SCOPE = static kh_inline), SCOPE is always static. I want to know how to use KHASH_DECLARE. It looks like a bug.

Thanks to you.

I've been writing some documentation for klib for personal reference, and if you enabled the wiki feature on github, i'd be able to upload it for all to see and benefit. Its a great library, and with some good docs it has great potential. Thanks again for writing it.

Many of kvec.h function macros require passing the type being stored (kv_resize, kv_copy, kv_push, kv_pushp, kv_a) but this seems to not actually be needed. It's only used for two reasons:

• To cast the pointer returned from realloc(), which is not actually needed in C where the preferred style is usually to not cast from a void pointer when assigning to a variable.
• In sizeof(type) which could be changed to sizeof(*(v).a)

Has this not been changed simply to not break the current API?

Reproduction code:

KHASH_MAP_INIT_STR(var, double);
static khash_t(var) *h = NULL;
static double get_var(const char *name) {
    khiter_t k = kh_get(var, h, name);
    double val = k != kh_end(h) ? kh_val(h, k) : 0;
    printf("value of %s is %g\n", name, val);
    return val;
}

static void set_var(const char *name, double val) {
    printf("set %s to %g\n", name, val);

    int ret;
    khiter_t k = kh_put(var, h, name, &ret);
    kh_value(h, k) = val;
}

void test() {
    if (h == NULL) {
        h = kh_init(var);
    }

    const char *foo = strdup("foo");

    set_var(foo, 20);
    free(foo);

    get_var("foo");
    get_var(strdup("foo"));
}

Result:

set foo to 20
value of foo is 0
value of foo is 20

If I turned on optimization:

set foo to 20
value of foo is 0
value of foo is 0

Here is the code.

https://github.com/attractivechaos/klib/blob/master/khash.h

What I want: I am entering n unique entry in this table. and after inserting key and value i want to check how much space this hastable is consuming.

Issue: Example after entering 1000 entry. When i try to get the size of hastable using kh_size(h) function given in "khash.h" I am getting 387 entry only. But when i am trying get the value by giving the key I am able to get.

Here is my code: PFA. `#include <stdio.h> #include <stdlib.h> #include "khash.h" #include "string.h"

#define kh_get_val(kname, hash, key, defVal) ({k=kh_get(kname, hash, key);(k!=kh_end(hash)?kh_val(hash,k):defVal);}) #define kh_set(kname, hash, key, val) ({int ret; k = kh_put(kname, hash,key,&ret); kh_value(hash,k) = val; ret;})

const int khIntInt = 33;

KHASH_MAP_INIT_INT(khIntInt, long long) // setup khash to handle string key with int payload //KHASH_MAP_INIT_STR(khStrInt, long long) // setup khash to handle string key with int payload int int_key_int_body_example(char * filename) { printf("\n\nBegin khash test string key with int payload\n"); int ret, is_missing; khiter_t k; char *tval; khash_t(khIntInt) *h = kh_init(khIntInt); // create a hashtable printf("\n --------------------------------- FILE READ AND WRITE OPERTAION -------------------\n");

    FILE *fp;
	int * ch;
	char line[200];
	fp=fopen(filename,"r");
	if(!fp)
	{
            perror("could not find the file");
            exit(0);
	}

printf("\n ------------------------------------------------- PUTTING ALL KEYS ---------------------\n");

int count=0;
long long val_line=0;
    while (fgets ( line, 200, fp ) != NULL ) {

    printf(" Trying to Add key = %s and value = %s count =%lu \n", line,line,count++);
    val_line = strtoll(line, NULL, 0);
    printf("\n int_key_int_body: Here is the value in integer After Atoi = %ld \n",val_line);
    kh_set(khIntInt, h, val_line, val_line);
    printf(" ### DEBUG: h->n_buckets=%d,h->size=%d,h->n_occupied=%d,h->upper_bound=%d \n ",h->n_buckets,h->size,h->n_occupied,h->upper_bound);
    }
           fseek(fp, 0, SEEK_SET);
           printf("\n ------------------------------------------------- GETTING ALL VALUES ---------------------\n");
           count=0;
          while (fgets ( line, 200, fp ) != NULL ) {
                 val_line = strtoll(line, NULL, 0);
                 printf("\n int_key_int_body: Here is the value in integer After Atoi = %ld \n",val_line);
                 k=kh_get(khIntInt, h, val_line);
                if (k == kh_end(h)) {
                     printf("no key found for line=%ld",val_line);
                } else {
                    printf("GET value for  key = %s and value = %d count =%lu and k_iterator=%d \n", 
                    line,kh_val(h,k),count++,k);
              }
           }
          long long 

h,k),count++,k); } } long long no_of_elements = kh_size(h); printf("\n No_of_elements = %lld", no_of_elements); printf("\n ------------------------------------------------- ---------------------\n"); kh_destroy(khIntInt, h); return 0; } int main( int argc, char *argv[] ) { char *filename; filename=argv[1]; printf("\n filename=%s",filename); int_key_int_body_example(filename); }`

I've stumbled upon this thread while looking for an adequate way to iterate over kbtree keys. Then i've ran across this kbtree variation which exposes an iterator interface instead of __kb_traverse. The following example illustrates their usage:

        int cnt = 0;
        kbitr_t itr;
        kb_itr_first_int(h, &itr);
        do {
            ++cnt;
            printf("%u\n", kb_itr_key(int, &itr));
        } while (kb_itr_next_int(h, &itr) != 0); 
        printf("[ht_khash_int] traverse size: %d\n", cnt);

Assuming that this repo is the "official" for klib, any chance that iterator version can be landed here?

Recent versions of Clang warn about unused static inline functions in .c files (though they suppress this warning for such definitions in header files). Definitions via KHASH_INIT etc are effectively in the .c file, and it's impractical to make these inline other than static inline; so add attributes to suppress these warnings.

See for example the warnings that drown out other information in travis htslib build logs.

Given 0 as lsize, the program crashes. These are the relevant lines. https://github.com/attractivechaos/klib/blob/9a063b33efd841fcc42d4b9f68cb78bb528bf75b/ksort.h#L144-L145

Hey there!

I belong to an open source security research community, and a member (@michaellrowley) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

For instance, the following :

#define kv_push(type, v, x) do {									\
		if ((v).n == (v).m) {										\
			(v).m = (v).m? (v).m<<1 : 2;							\
			(v).a = (type*)realloc((v).a, sizeof(type) * (v).m);	\
		}															\
		(v).a[(v).n++] = (x);										\
	} while (0)

can be rewritten as :

#define kv_push(v, x) do {									\
		if ((v).n == (v).m) {										\
			(v).m = (v).m? (v).m<<1 : 2;							\
			(v).a = realloc((v).a, sizeof(*(v).a) * (v).m);	\
		}															\
		(v).a[(v).n++] = (x);										\
	} while (0)

The key difference is that asking for type simply to take sizeof(type) can be error prone (and the errors can be hard to debug) and is redundant when the size of the type can be determined by taking sizeof() of a variable known to be of the same type in the structure passed to us. It is also sweeter syntax, as an aside.

Also, why do we use trust malloc()/realloc() to always succeed ?

Instead of :

#define kvec_t(type) struct { size_t n, m; type *a; }

do :

#define kvec_t(...) struct { size_t n, m; __VA_ARGS__ *a; }

C macros are parsed in a very literal way, with no contextual awareness of {}, etc. So while struct { int x, y; } is a valid type, kvec_t(type) will split it into two arguments at the first , and then complain about too many parameters, while kvec_t(...) will paste the entire thing in place of __VA_ARGS__.

Hello, I encountered segmentation faults (by double free / heap overflow) in the kson_parse / kson_parse_core functions. Could someone please point me to a contact to discuss these issues? Best Regards