Hacker News Reader

Comment by borplk | Hacker News Reader

I'd say that's a bit naive.

How would you go about writing something like rsyslog without doing the things they have done?

How would you create rsyslog's flexible (I'm not saying it's "good") module system where people can write their own pluggable custom input/output modules?

Your comment somehow suggests that it's possible to achieve everything they have achieved in terms of functionality while doing it in a much much better way that they just don't know about.

If people writing rsyslog aren't good enough to do it then 99% of other people aren't either.

So let's not blame people, it's the weakness of the language.

View on HN

Are you serious? You could start by fixing that godawful code style and removing the macros. You could change these variable names and function names to make more sense (CHKiRet? omsdRegCFSLineHdlr? What the hell?). The compiler extensions are unnecessary and can just be removed. None of these changes have any impact on the functionality of rsyslog.

Cool down a bit, would you?

You could get your point across without using that tone.

Maybe you are not too familiar with rsyslog. Those are modules that get compiled into rsyslog itself.

If you attempted to create such a module system you will very soon see that doing a lot of the things that they have done is unavoidable (weird naming and so on aside).

I see this attitude where people suggest that writing beautiful secure wonderful C code is possible however just somehow all people are just too dumb to be able to do it.

Every example you show them they say "nah, that person? also too dumb".

You can find similar crap like that example that I pasted in all popular C projects including the Linux kernel and Redis.

At some point does something become not fit for purpose?

I'd say we'd make more progress if we become less tolerant of technologies that disrespect us as humans.

If only an elite subset of people are good enough to program in C. I'd say that's because C is not good enough, not because everyone else is too bad for C.

Have I said anything that implies the module system is bad here? None of the guidelines in my article nor my comments here have anything to say about their module system. You could easily make this style better, name things better, and expand the macros and it would (1) work exactly the same and (2) be much better code for it.

I'm not sure which parts of that you are referring to as unavoidable since C can do modules just fine without any mess. Define the functions you want to implement as static functions and add something like this at the bottom of the file:

    outputmodule_t omstdout = { .name = "omstdout", .description = "blah", .init = prepare_stdout, .do_action = write_to_stdout }
    #if COMPILING_FOR_RUNTIME_LOADING
    outputmodule_t *rsyslog_outputmodule = &omstdout;
    #endif

Then either stick `omstdout` in a list of modules known at compile-time or compile separately and use dlopen/dlsym to get the one necessary symbol. No GNUisms, no language extensions, no linker tricks, no macro magic.

C has problems but it's not that hard to create readable code in it.

Reply on news.ycombinator.com