5 ms·

pledge(2) is great. However, BCHS sucks. No. Do not write your webapp in C. I'm serious here. Write it in Python, write it in TCL, write it in Lisp. But write

pledge(2) is great. However, BCHS sucks. No. Do not write your webapp in C. I'm serious here. Write it in Python, write it in TCL, write it in Lisp. But write it an environment that is at least semi-manged. FFIs are pretty good. You can call pledge from your app. But don't write your app in C. If you're doing anything serious, it's a bad idea.

catern 10y ago
Well... there is at least some sense in writing a webapp in C. If you rely on operating system primitives for security (processes, Unix filesystem permissions, seccomp/pledge/capsicum) instead of language features (bounds checking, garbage collection, etc.) then just maybe you could get performance gains while still being secure. But in reality writing applications in a hosted environment/virtual machine is more performant than writing it in C and locking it down with operating system features. And of course more secure. The author's efforts would be better spent on improving the performance of OS-based security (processes, filesystems), than attempting to use that security as it stands. There are all kinds of tricks that could be implemented to improve things...
- aidenn0 10y ago
  If you are using CGI, then you probably already don't care about performance. On top of that, the CPU throughput overhead of using a compiled managed language is typically less than a factor of 2, which, combined with the fact that the majority of web applications are not compute bound means the number of webapps that it would make any sense to write in C is nearly zero. Pretty much all pithy advice (such as "Don't write your webapps in C") has an implicit exception "Unless you fully understand why I made this recommendation and have good reasons for why they don't apply." That exception is not made explicit because 1) It would make the advice less pithy and 2) Then those who would most benefit from the advice convince themselves that it doesn't apply to them.
  - SwellJoe 10y ago
    "If you are using CGI, then you probably already don't care about performance." So...I think you're missing a few pieces of the puzzle with this statement. The statement is a truism that is right almost always, but it has exceptions, and this is one of those exceptions. CGI is slow when startup time for your app is slow, because of a VM, because of the library loading overhead, because of environment setup, because of some thing that isn't really the fault of CGI per se. CGI can be fast, or at least fast enough, if startup time for your app is very fast. An app written in C, statically linked, could potentially start and respond faster than many dynamic language apps could even when running in an app server. C is fast. C is small. C is also particularly error-prone, would be a little verbose for web apps, and does not have a good ecosystem of support libraries for web apps, but even if running it without an app server in a CGI mode it could be fast enough for most deployments. The CGI interface is not why CGI apps are slow. CGI apps are slow because startup of many modern language environments is slow. C is a language that doesn't have to be slow in that context. (Though, it could be faster still by using an FCGI or other app server model and having your C web app running all the time, so it just has to answer requests over a socket or whatever...though async programming in C is also hard to get right for inexperienced programmers.)
    - qwertyuiop924 10y ago
      Huh. I wonder what the start time is on the language I'm using for CGI work. (I'm using CHICKEN, which is a compiled Scheme R5RS implementation with numerous extensions).
      - SwellJoe 10y ago
        Probably fine for some things, since it is compiled, and, as I understand it is pretty fast. I don't know a lot about the internals of chicken, but since it's a Scheme wouldn't it need some kind of VM for macros and memory management and such? That'd impose some kind of startup overhead that C wouldn't have. But, then again, Perl can start fast enough for some things (though most Perl web app developers use some sort of app server, because they rely on a bunch of libraries that would increase startup time remarkably if it had to happen for every request). Do you write command line apps with CHICKEN? Are they super fast to start, like instant (comparable to something written in C or small Perl scripts)? If so, then CGI could probably be fast enough for some use cases. If you can perceive the startup time, then no, it'd be kinda sucky when used with CGI.
- moosingin3space 10y ago
  > just maybe you could get performance gains Not too sure about that -- Erlang/OTP-based web applications have very good performance (and transparent scaling) with a fraction of the code of a hand-rolled C-based web application. I honestly think web applications are a place where everything but assembly is better than C.
lilyball 10y ago
If you're considering writing it in C, you probably have some reason why you don't want to use a scripting language. To that end, I'd suggest using something like Rust instead of C.
- clarry 10y ago
  Maybe I'm writing it in C because I like the language, enjoy using it and am good with it? And I know it works everywhere I want it, even years later? I hate to be told what I should or shouldn't use.
  - Nullabillity 10y ago
    And your users will certainly enjoy all the security issues your code will have.
    - comex 10y ago
      Not the person you replied to, but I'm actually quite conflicted on this count. I enjoy C, both aesthetically and for its performance, yet I care a lot about security, so I feel obligated to avoid C for anything important. I'm a big fan of Rust, but it's nowhere near replicating what I like about C.
    - z3t4 10y ago
      Someone with say 10-20 years of experience in a language will write a more secure program then someone just started in any language ... And even if you program in a "safe" language, you still make bugs, and all those bugs passed the compiler/parser, so your language obviously didn't help you there. There are a lot of code written in C in the wild, witch means there are also a lot of bad code.
      - Nullabillity 10y ago
        There are business logic bugs, and there are memory corruption bugs. One of those leads to RCEs a lot more often than the other. One of those is a lot easier for the compiler to prevent than the other.
nwmcsween 10y ago
BCHS needs a higher level api that is simple to use.

catern 10y ago

Well... there is at least some sense in writing a webapp in C. If you rely on operating system primitives for security (processes, Unix filesystem permissions, seccomp/pledge/capsicum) instead of language features (bounds checking, garbage collection, etc.) then just maybe you could get performance gains while still being secure. But in reality writing applications in a hosted environment/virtual machine is more performant than writing it in C and locking it down with operating system features. And of course more secure. The author's efforts would be better spent on improving the performance of OS-based security (processes, filesystems), than attempting to use that security as it stands. There are all kinds of tricks that could be implemented to improve things...

aidenn0 10y ago
If you are using CGI, then you probably already don't care about performance. On top of that, the CPU throughput overhead of using a compiled managed language is typically less than a factor of 2, which, combined with the fact that the majority of web applications are not compute bound means the number of webapps that it would make any sense to write in C is nearly zero. Pretty much all pithy advice (such as "Don't write your webapps in C") has an implicit exception "Unless you fully understand why I made this recommendation and have good reasons for why they don't apply." That exception is not made explicit because 1) It would make the advice less pithy and 2) Then those who would most benefit from the advice convince themselves that it doesn't apply to them.
- SwellJoe 10y ago
  "If you are using CGI, then you probably already don't care about performance." So...I think you're missing a few pieces of the puzzle with this statement. The statement is a truism that is right almost always, but it has exceptions, and this is one of those exceptions. CGI is slow when startup time for your app is slow, because of a VM, because of the library loading overhead, because of environment setup, because of some thing that isn't really the fault of CGI per se. CGI can be fast, or at least fast enough, if startup time for your app is very fast. An app written in C, statically linked, could potentially start and respond faster than many dynamic language apps could even when running in an app server. C is fast. C is small. C is also particularly error-prone, would be a little verbose for web apps, and does not have a good ecosystem of support libraries for web apps, but even if running it without an app server in a CGI mode it could be fast enough for most deployments. The CGI interface is not why CGI apps are slow. CGI apps are slow because startup of many modern language environments is slow. C is a language that doesn't have to be slow in that context. (Though, it could be faster still by using an FCGI or other app server model and having your C web app running all the time, so it just has to answer requests over a socket or whatever...though async programming in C is also hard to get right for inexperienced programmers.)
  - qwertyuiop924 10y ago
    Huh. I wonder what the start time is on the language I'm using for CGI work. (I'm using CHICKEN, which is a compiled Scheme R5RS implementation with numerous extensions).
    - SwellJoe 10y ago
      Probably fine for some things, since it is compiled, and, as I understand it is pretty fast. I don't know a lot about the internals of chicken, but since it's a Scheme wouldn't it need some kind of VM for macros and memory management and such? That'd impose some kind of startup overhead that C wouldn't have. But, then again, Perl can start fast enough for some things (though most Perl web app developers use some sort of app server, because they rely on a bunch of libraries that would increase startup time remarkably if it had to happen for every request). Do you write command line apps with CHICKEN? Are they super fast to start, like instant (comparable to something written in C or small Perl scripts)? If so, then CGI could probably be fast enough for some use cases. If you can perceive the startup time, then no, it'd be kinda sucky when used with CGI.
moosingin3space 10y ago
> just maybe you could get performance gains Not too sure about that -- Erlang/OTP-based web applications have very good performance (and transparent scaling) with a fraction of the code of a hand-rolled C-based web application. I honestly think web applications are a place where everything but assembly is better than C.

lilyball 10y ago

If you're considering writing it in C, you probably have some reason why you don't want to use a scripting language. To that end, I'd suggest using something like Rust instead of C.

clarry 10y ago
Maybe I'm writing it in C because I like the language, enjoy using it and am good with it? And I know it works everywhere I want it, even years later? I hate to be told what I should or shouldn't use.
- Nullabillity 10y ago
  And your users will certainly enjoy all the security issues your code will have.
  - comex 10y ago
    Not the person you replied to, but I'm actually quite conflicted on this count. I enjoy C, both aesthetically and for its performance, yet I care a lot about security, so I feel obligated to avoid C for anything important. I'm a big fan of Rust, but it's nowhere near replicating what I like about C.
  - z3t4 10y ago
    Someone with say 10-20 years of experience in a language will write a more secure program then someone just started in any language ... And even if you program in a "safe" language, you still make bugs, and all those bugs passed the compiler/parser, so your language obviously didn't help you there. There are a lot of code written in C in the wild, witch means there are also a lot of bad code.
    - Nullabillity 10y ago
      There are business logic bugs, and there are memory corruption bugs. One of those leads to RCEs a lot more often than the other. One of those is a lot easier for the compiler to prevent than the other.

nwmcsween 10y ago

BCHS needs a higher level api that is simple to use.