Hacker Newsnew | comments | show | ask | jobs | submit | przemoc's commentslogin

I didn't know about use of static keyword in array parameter declaration, but I dare to say that a lot of senior C programmers are unaware of this C99 feature.

It's nice to be able to specify function's expectations on that level, yet it looks that only clang (tested with 3.5.0) takes use of it, while gcc (tested with 4.9.1) seems oblivious to it. Be it NULL or shorter string literal than expected, gcc with -Wall -Wextra -pedantic -std=c99 spits nothing. Both mistakes are detected by clang.

Sadly even clang doesn't warn us when fun(int len, char str[static len+1]) is called like fun(5, "test").

But I'm not sure that I agree with the rule Don't use NULL. In any sane C environment NULL is defined as follows (unless __cplusplus is already defined, because then it's defined as 0 or 0L)

    #define NULL ((void*)0)
and IMHO there is nothing wrong with that.

Distinguishing kind of 0 we're dealing with (even if it's not strongly guarded by compiler) is often important for readability and eases maintenance of the code (0 vs '\0' vs NULL). While comparing pointer with NULL (writing p == NULL or p != NULL instead of simply !p or p) may seem superfluous (yet I have nothing against programmers doing so), calling function with pointer parameters providing 0 argument instead of NULL seems less clear to me.

> if you really want to emphasize that the value is a pointer use the magic token sequence (void *)0 directly.

I don't buy it.


One of musl libc guys wrote quite convincing article about NULL: http://ewontfix.com/11/

There was also discussion on musl mailing list (I don't know is this best link to it): http://www.openwall.com/lists/musl/2013/01/09/1


The topic was modern C and in modern C environment NULL is defined as

    (void *)0
There is no point in writing longer form and it's still clearer and safer than 0 alone.

C++ is another story with its

    void* hate
built-in. In this land you rather write



for extra purists), but as you're denoting pointer type already in this notation, there is not much gain in using NULL instead of 0 (well, beside grepability).

In many cases you can be done with 0 alone in C++, that's true, and in such cases NULL at least poses some intention, but if you're not careful enough, you may end up putting NULL alone (without pointer-to-type cast) in some variadic function and things start to blow up all of a sudden (that is if your NULL integer width isn't the same as pointer width). That's why having a habit of writing

is a good thing in this land.

Regarding musl check also:


In short, musl's stddef.h has following lines:

    #ifdef __cplusplus
    #define NULL 0L
    #define NULL ((void*)0)
NULL defined as 0L for C++ is nice workaround, but it works only for LP64 platforms.

In the same vein for Windows C++ x64 environment you need NULL to be 0LL, as it is LLP64 platform.


Looks nice. I was going to perform a shameless plug by mentioning my simple Linux OSD nanoproject (for those wanting to use some other recording matters, but still see the keystrokes on the screen):


but I just remembered that I still haven't fixed a bug I noticed on my computer at work, where I had Gnome back then. Nowadays I have awesome there too (just like on my laptop), so I'll possibly won't reproduce it, but notes I left should be enough to do the fix one day. ;)


You are not. I hate how browsers nowadays, especially browsers on smartphones, are unusable without access to Internet. Sure, there is Pocket for instance, but IMHO there shouldn't be need for such app. And while I'm ranting at Pocket - there is still no automated login for LWN.net. (I know I can go with manual way, but still...)

P.S. I'm thinking about making nice dedicated cross-platform LWN.net articles & comments reader one day (well, maybe more), but it's hard to squeeze out enough time for that kind of fiddling (unless it's really a gravely matter, but it isn't here).


Opera Mobile (the "classic" one before they threw it all away) let you save pages for offline reading. Not perfect but better than nothing. Sadly it did not cache content through restarts which is annoying on mobile where apps get killed a lot. But if I recall correctly at least the navigation back and forward was instant, like on desktop, with no network traffic.


What about appcache manifest, service workers in chrome, and hood.ie? There's ways to make the web work offline.


I bought my T430 (N1T56PB) on August 2013. 10 months later "Tab" key fell off. 2 months later "A" key fell off and few months ago another one - "S". Currently "E" is the one that behaves a bit differently and surely will be the next one to fall off.

At the beginning I thought that these islandish keyboards aren't that bad, but after a year I'm sure they are total crap, which shouldn't be put in stuff that costs $1500+.

Previously I owned R61 (NF55WPB), which was surely lower-end laptop and I didn't have any problems with keyboard for 3 years that I spent using it (until NVS140m exhibited its factory problem and I have no longer seen anything on the screen).


I think the keyboard on my T430s is the best keyboard I have ever used. It feels perfect to use. I love it and I get annoyed with anyone else's laptop. I haven't had any of your problems.


All hard (but honest) LaTeX fans may enjoy reading my old post about LaTeX, which is somehow loosely related (I hope I'm not overstretching it :>).

Getting things done in LaTeX (or not)


Surely any modern complete (La)TeX replacement would be a good thing to have, but I haven't found out any yet, so LaTeX IMHO still remains one of the best choices when it comes to writing/publishing stuff.

I think that reStructuredText could be a nice foundation for some more generic writing/publishing solution, where TeX notation could be still uded for math environments (as I don't know any better one for that). Markdown is too vague, imprecise and inflexible, and CommonMark - a strongly specified, highly compatible implementation of Markdown - is not much better, mostly due to Markdown compatibility.

EDIT: AsciiDoc could be also used instead of reST.


I was never into FreeBSD (I hoped to dive into it more in the past, but never done so sadly), but heard that 1st ed was really good, so the revised version quite likely shouldn't be any worse (hopefully even better). I would order it, but there are still many technical books on my shelf waiting for my attention, thus adding another one will not help in that matter.

One thing is sure, even if you're not into FreeBSD, broadening your perspective is never wrong. So I may eventually order it in the future.


FreeBSD combined with this book is great for learning about operating systems in general, regardless of whether you care about FreeBSD specifically. The book goes into a lot of detail about why certain design decisions were made, and how things are implemented in other operating systems.

If you're already studied some other OS in general, you might not need this book, but if you haven't, this is a great place to start.


Thanks! Do you think it's useful to get this one even if you have used Linux almost exclusively? Will it make it easier for one to get into Kernel development?


Sure. But it's worth having a FreeBSD box (or VM) that you can use to tinker with the kernel.

Recompiling FreeBSD kernel source is super easy, by the way. It comes in /usr/src on your machine and all you need to do to reinstall one with your changes is "make buildkernel && make installkernel" . Actually understanding the sometimes decades-old source code, on the other hand, might be a little more difficult...


How'd you compare this with Linux Kernel Development by Robert Love and/or Bovet/Cesati, especially for someone who's a newbie (but curious to learn and work hard)?


I've worked a little on kernel. I think it would surely help to get into kernel development. Codebase is different, but they share similar architecture. If you understand one, it wont be hard to get started with other. From my experience I found BSD codebase easier to approach than Linux.


Yes. I'd also get 'Modern Operating Systems' by Tannenbaum, which will explain lots of stuff that might be opaque/confusing if you're not already a kernel guy.


Personally I would say yes, as it shows not all UNIXes are alike.


Book was great, I really liked it. I haven't seen the older adaptation yet, but the more recent one (with Clooney) was IMHO terrible. Such adaptations make more harm than good.


The Tarkovsky version is fantastic, definitely find time to watch it. It's visually stunning. Kurosawa wrote about how much he aesthetically loved Solaris, particularly the way Tarkovsky captured water.


I am a bit late to the conversation, but apparently Mosfilm has made Solaris available online:

Part 1:


Part 2:


(Links are from:


there are more Tarkovsky film links there).

Word of warning: do not expect Star Wars or Inception type special effects. And this is Tarksovky's reading which, if you know Tarkovsky, he was concerned more about the human condition, than technological aspects of Sci-Fi.


I both read the book and watched the clooney movie and I liked both of them. The key to enjoying movie adaptations is to imagine they're two completely separate stories that just happen to have certain names in common.


Nitpick: You're talking about CRC32c (C of Castagnoli) - 0x1EDC6F41. By CRC32 without any additional context people usually mean CRC using polynomial 0x04C11DB7, which is much more common than CRC32c. CRC32 has also a nice feature:

"CRC-32 polynom 0x04C11DB7 can correct 1 byte error in ~1mbit[,] not that correcting single byte errors in such huge blocks is good for anything but ive found a much better one specifically 0x0D438219 which can correct one byte error in 9747877 bits" [1]

[1] http://guru.multimedia.cx/category/error-correcting-codes/


Shouldn't "Europeans" in the title be renamed to "Brits"?

In Poland we keep eggs in the fridge, be it home or market.


IIRC "security" plays important role here too, because using regexps you can much easier find sensitive data, or to be precise: context (neighborhood) of sensitive data.



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact