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

21–30 of 158 posts

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

#21

Post by jimbob45 »

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++.

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

#22

Post by LeFantome »

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++.

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

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

#24

Post by littlestymaar »

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…

> Pair it with a better, more modern, and safer native-compiled language and get the same effect. Zig, Nim, Go, hell even Carp.

I love how trollish it is not to talk about Rust in that context.

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

#26

Post by LeFantome »

galdosdi wrote: post #6
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)

Funny to reflect that there was a time not so long ago when writing web apps (CGI usually) in C wasn't at all unusual (shortly before Perl became much more popular for this). And today, it is indeed kind of crazy.

I remember writing CGI scripts in Perl in 1993 ( the year before Netscape ). I am not sure when CGI even became a thing but it could not have been long before that.

Not only was “not so long ago” kind of at the very beginning of meaningful web history but it was also for a very brief moment in time ( if we are talking pre-Perl ). Pre-Perl CGI may have never been a thing though as Perl is older than CGI.

I recall PHP being the next wave after Perl. One could argue it never lost its place even if it now has many neighbours.

Not a Perl advocate by the way though it did generate some pretty magical “dynamic” web pages from text files and directory listings back in the day. Similar story with PHP.

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

#27

Post by zephyr9 »

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…

Is there a good string-manipulation C library?

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

#28

Post by Shared404 »

da39a3ee wrote: post #18

I’d like to love man pages but - I feel that they are linux only. On my MacOS system I can’t rely on man x being the man page for the right version of x. I know that in principle there are environment variables that make sure i’m getting the gnu core utils version or the base homebrew version rather than the system BSD version, but it’s too many moving parts. Furthermore even if I get it right, I can’t expect people…

> - I feel that they are linux only.

They're actually better on Free/Open BSD in my experience. As stupid as it makes me sound, I often struggle to parse Linux man pages, but the BSD's I've had no trouble with for a variety of topics.

> - I feel that a small amount of plain text documentation should be stored in the executable,

Isn't this how --help usually works? I would also rather have more documentation embedded, at least for some executables.

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

#29

Post by the_only_law »

Shared404 wrote: post #28
da39a3ee wrote: post #18

I’d like to love man pages but - I feel that they are linux only. On my MacOS system I can’t rely on man x being the man page for the right version of x. I know that in principle there are environment variables that make sure i’m getting the gnu core utils version or the base homebrew version rather than the system BSD version, but it’s too many moving parts. Furthermore even if I get it right, I can’t expect people…

> - I feel that they are linux only. They're actually better on Free/Open BSD in my experience. As stupid as it makes me sound, I often struggle to parse Linux man pages, but the BSD's I've had no trouble with for a variety of topics. > - I feel that a small amount of plain text documentation should be stored in the executable, Isn't this how --help usually works? I would also rather have more documentation embedded,…

FreeBSD has pretty good documentation.

Comparatively, I’ve found NetBSD documentation to be lacking, although NetBSD seems to take the cake on code quality and legacy architectures (a feature I find my delve right now.

On the wider discussion of doc, I’ve found Linux kernel documentation to be a pain in the ass, and sometimes ever worse than windows kernel documentation (which I won’t even both to get into)

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

#30

Post by loeg »

the_only_law wrote: post #11
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…

I just wish there were better tools for navigating C codebases. There’s been more than one time where I’m in some large auto tools based project trying to figure something out and there’s a call out to some dependencies I have no idea of. Also many of the projects lack and sort of documentation or source code commenting. These aren’t someones pet project either. One of them was from a notable name in the open source…

Have you tried ctags for navigation? Or clang-lsp?
Post reply on HN