Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BCHS: OpenBSD, C, httpd and SQLite web stack

learnbchs.org

Post reply on HN
Print view View original

81–90 of 158 posts

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#81

Post by lelanthran »

pjmlp wrote: post #74
lelanthran wrote: post #71

Earlier quoted context omitted.

I got tired of running into this problem and decided to simply eat the cost of using `char *` in my string library.

And that is why most such efforts eventually die. WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.

> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.

Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project.

1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it is clear when the data object needs a `free`, `fclose`, etc. This is a big deal, it's difficult to change the typedef for sds due to the way it returns pointers.

2. Not compatible with current string functions, strike 1: storing binary data in the strings, like the nul character makes it silently lose data when used with current string functions that accept `const char *`. This is a very big deal!

3. Not compatible with current string functions, strike 2: an sds string is only compatible with current string functions that take a `const char *`. This isn't such a big deal (for example, it provides a replacement for `strtok` as the standard `sds` type won't work for `strtok`) but it's unnecessarily incompatible.

4. With the current way it's exposed to a caller, you cannot use `const sds` variables anywhere, which removes a lot of compiler-checking. Trying to use `const` on any sds variable is pointless as you get none of the error-checking.

While sds solves many problems with raw C strings, those problems can be solved by adding standard library functions that work with existing C strings. In addition, it adds a few more problems of its own.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#82

Post by pjmlp »

lelanthran wrote: post #81
pjmlp wrote: post #74

Earlier quoted context omitted.

And that is why most such efforts eventually die. WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.

> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it…

My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS.

When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#83

Post by [deleted] »

jimbob45 wrote: post #21
dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

Why would you ever choose C anymore? The killer feature of C++ is “you don’t pay for what you don’t use”. There’s virtually no reason ever not to use C++.

[deleted]

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#84

Post by lelanthran »

pjmlp wrote: post #82
lelanthran wrote: post #81

Earlier quoted context omitted.

> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it…

My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS. When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.

> My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS.

Well, yes, I'd love to see some proper string support too, so at least we're in agreement about that :-)

But, overhauling C with additional (memory-safe) array types and string types that are nonetheless still compatible with legacy uses is probably a non-starter anyway. The only way forward would be to add a new type that isn't compatible, which is unpalatable to a lot of people (myself included).

Adding memory-safe functions and/or semantics is easier, but will probably not cover 100% of the memory-safety desired.

> When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.

Threads, I feel, are a poor example for two reasons: 1) Hardly any code uses the `thread_t` type for a variety of reasons, and 2) There was no need for a `thread_t` type to be backward compatible with anything.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#85

Post by foxfluff »

lanstin wrote: post #55
zephyr9 wrote: post #27

Earlier quoted context omitted.

Is there a good string-manipulation C library?

No? Asking for code nav and you get three answers. Asking for this and you get crickets. In the 90s I worked at a place where we embedded TCL into all the apps, and rolled our own templating systems. I had to do a little string stuff in C after few years of go, and it sucked. Ugg. buf[len] = ‘\0’; Using go, I thought I was getting back to low level stuff but this C experience made me appreciate strings in Go. Web ser…

> buf[len] = ‘\0’;

So why didn't you use one of the bazillion library functions or third party libraries that terminate strings for you?

I feel like most of the criticism is coming from people who punish themselves by rejecting library functions and then telling that strings are hard. Doh.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#86

Post by aspyct »

tyingq wrote: post #9
theamk wrote: post #2

It seems pretty crazy to write web-facing apps in C, with no memory safety at all. (They do have "pledge" but even in the most restricted case, this still leaves full access to database)

Though the majority of running web servers, load balancers, protocol proxies like php-fpm, etc, are probably written in C :)

Yes, but they are...better built than your quick social network poll application thingy with customer's special sauce that you had 5 days to specify, develop and deploy.

C is a tremendous tool, but I don't think it's the best for customer facing web apps.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#87

Post by ThinkBeat »

I remember writing a lot of early web stuff in Perl/CGI. The "servers" I wrote were fast. Perl had most things you could desire built in already.

Database stuff took a good deal of doing, but with little in terms of abstraction, it was also quite fast.

I would like to see a rennescance of using different protocols than HTTP and different content markup than HTML.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#88

Post by MrBuddyCasino »

avar wrote: post #79
zephyr9 wrote: post #27

Earlier quoted context omitted.

Is there a good string-manipulation C library?

The strbuf library that's part of git.git is a pleasure to work with. It's C-string compatible (just a char /size_t pair), guarantees that the "char " member is always NULL-delimited, but can also be used for binary data. It also guarantees that the "buf" member is never NULL: https://github.com/git/git/blob/v2.34.0/strbuf.h#L6-L70

This looks really well thought out - bookmarked.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#90

Post by xondono »

1ris wrote: post #38
LeFantome wrote: post #22

Earlier quoted context omitted.

Isn’t “C++ is too complex for me” a decent reason?

It totally is, as long as you don't use C instead. There are plenty of good, less complex languages than C++ out there: Java is quite close and way, way less complex, for example. But C is non of them. Pointers are more complex in C than in C++ (pointer provenance). Casts are more complicated in C than in C++, as C++ named casts are less powerful and therefore give you less opportunity to shoot yourself in the foot.…

> There are plenty of good, less complex languages than C++ out there […] But C is non of them.

To this day I cannot understand how anybody can claim that. C++ is so ridiculously complex that it’s not a superset of C mostly because of added keywords and rules, some of them implicit.

> I suggest using a c++ compiler to write C with enum classes, std::span, either a typed std::span wrapper for malloc or std::vector, std::string, std::string_view,using, std::variant, std::unique_ptr, std::fmt, std::optional, templates, std::vector for your types, in that order.

How on earth do you write that and expect me to believe it’s simpler than C? You’ve just listed a number of options on how to implement an *enum* of all things. Each one will have different pros and cons, and I’m supposed to weight them before coding?

> Pointers are more complex in C than in C++

That’s impossible from you own statement. Pointers in C can be more dangerous because the compiler won’t stop you from doing crazy shit, I’d buy that, but complex?

C++ feels like the Mikrotik version of C, there’s just too many options and buttons and switches, and I won’t use half of this in my life! I guess some people find it interesting but I’m just trying to get my job done.

Post reply on HN