On: Kore: a fast web server for writing web apps in C

[nulltype]

Thank god it's written in C and not C++

[CountSessine → nulltype]

Yeah. Thank God. I love broken string implementationsssssdd##%^$*$#@@#$%$$$###ludvik^0knox^0shamen^0password^0pass^012345^0qwerty^0dreamdevil^0

C is just awesome.

[sdevlin → CountSessine]

You're breaking the tables.

[nulltype → CountSessine]

We got that solved. https://github.com/antirez/sds

[pjmlp → nulltype]

Except it isn't neither part of ANSI C, nor is used by any relevant third party C library, but it is solved....

[CountSessine → nulltype]

This seems to be an adaptation of the earlier SafeStr lib. SafeStr is nice except that the C community is still too busy arguing about their awful lstr* and str*_s functions to take any notice and incorporate something genuinely secure like SafeStr into the standard lib. And the NVD just keeps growing...

So... you guys added something random and silly like <complex.h> to the standard, but still couldn't get around to a working string implementation? OK. Well, good luck with all that.

Not solved yet.

[faragon → CountSessine]

Easy strings for C, with Unicode support (and as fast as std::string): https://github.com/faragon/libsrt

[CountSessine → faragon]

libsrt, sds, SafeStr... How many times will this problem be solved independently before something like this makes it into the standard lib? Libsrt looks nice, but if you can't use it to interface to libraries that use the same types, you're still futzing around with char buffers.

What does Kore use? libsrt? Let's have a look at how you're supposed to program a web app in its examples:

   int
   serve_file_upload(struct http_request *req)
   {
	int			r;
	u_int8_t		*d;
	struct kore_buf		*b;
	u_int32_t		len;
	char			*name, buf[BUFSIZ];

   b = kore_buf_create(asset_len_upload_html);
	kore_buf_append(b, asset_upload_html, asset_len_upload_html);

   if (req->method == HTTP_METHOD_POST) {
		http_populate_multipart_form(req, &r);
		if (http_argument_get_string("firstname", &name, &len)) {
			kore_buf_replace_string(b, "$firstname$", name, len);
		} else {
			kore_buf_replace_string(b, "$firstname$", NULL, 0);
		}

		if (http_file_lookup(req, "file", &name, &d, &len)) {
			(void)snprintf(buf, sizeof(buf),
			    "%s is %d bytes", name, len);
			kore_buf_replace_string(b,
			    "$upload$", buf, strlen(buf));
		} else {
			kore_buf_replace_string(b, "$upload$", NULL, 0);
		}
	} else {
		kore_buf_replace_string(b, "$upload$", NULL, 0);
		kore_buf_replace_string(b, "$firstname$", NULL, 0);
	}

	d = kore_buf_release(b, &len);

	http_response_header(req, "content-type", "text/html");
	http_response(req, 200, d, len);
	kore_mem_free(d);

	return (KORE_RESULT_OK);
   }

Uh oh. So Kore invented yet another safe string/buf type? Why didn't they use libsrt? What's all this kore_buf stuff?

Strings in C are NOT a solved problem. They're a hot mess.

[faragon → CountSessine]

Yes, Kore don't use libsrt, although you could use it in your Kore user-modules (not all services are going to be trivial operations). And I agree, C strings is far from being a solved problem. In the case of libsrt strings, in addition to have embedded length (fast concatenation, search, etc.), it does support UTF-8 operations, include case conversion, without requiring OS support (i.e. without "locale", nor using custom hash tables, but in-code efficient hardwired character range selection), and most typical string operations.

P.S. Before implementing libsrt strings I did a wide study of many string and generic C libraries, implementing the best from all, and adding things that were not still covered (I'll investigate the Kore string/buffer implementation, too):

https://github.com/faragon/libsrt/blob/master/doc/references...

[CountSessine → faragon]

Kudos for the library design - it looks quite nice. We're looking for a safe, cross-platform, C string library at my work now - I'll do an evaluation of libsrt.

As for ANSI C, maybe someday this will get folded into the standard and we can pass around ss_t* 's rather than char* 's whenever we use third-party libraries.

[faragon → CountSessine]

Thank you for the consideration. Although the library targets safe and cross-platform code, I don't recommend you using libsrt on production code, yet. Rationale: the API is not yet finished, and it could have some changes that could break your build. Suggestions are welcome :-)

P.S. I don't expect any standard committee adopting that, not even wide usage (I'm glad just having some feedback! :-D).