hthh

What is "Nitro"?

"Copyright infringement" is not "trademark infringement" and shouldn't be in the title.

Why? I mean you're still sending the referer header, right?

Making the atomic bomb scores pretty high on the evil-genius scale.

Wow, in a happy coincidence syntect is exactly what I was looking for all last week! Now I just need to figure out Rust.

Dynamic resizing fixes this, although hash collisions can still be a problem (albeit a very unlikely one if your hash is secure). https://en.wikipedia.org/wiki/Hash_table#Dynamic_resizing

Absolutely, by all means look at old code - code that has survived and been useful for a long time. It's either adaptable (Linux) or doesn't need to change or adapt much (TeX).

Do you currently use and rely on software which you expect won't be useful to you in ten years time? I can't think of much personally.

(I do use IDA Pro, which has clearly adapted poorly to changing requirements - it still has scars of the 32-bit to 64-bit transition that get in the way of day-to-day usage. I hope there'll be something better in ten years. Of course, I could buy a cheaper, "higher quality" tool instead, but none of them are as powerful or as useful.)

"High quality" is an strange concept. I would look at code you actually use and rely on - that's the best indication of quality. A lot of critical code deals with inelegant, complex problems correctly and efficiently - I'd consider anything that can be relied on to manage that "high quality", even if it is unclean, inelegant, poorly formatted and algorithmically mundane.

That said, if you want to read elegant code, I'd recommend the stb parser libraries (written in C). They are small self-contained decoders for many common media formats, with excellent documentation:

https://github.com/nothings/stb/blob/master/stb_image.h https://github.com/nothings/stb/blob/master/stb_truetype.h https://github.com/nothings/stb/blob/master/stb_vorbis.c

These libraries are likely insecure, handle many edge-cases incorrectly, implement fewer features, and perform worse than other options. However, they meet your criteria better.

This is an interesting article, but the "Portability" comments could be a lot more useful: strndup and open_memstream are both "POSIX 2008", but strndup can be used on OS X while open_memstream cannot.

On Windows, sure. On other platforms UTF-8 is generally preferable (in my opinion).

I think this is the COFF document which they say "is directly applicable". https://github.com/llvm-mirror/lld/blob/master/COFF/README.m...

I'm guessing the speed difference comes from this linker using a different approach to symbol resolution which requires visiting files fewer times, but I'm not sure.

"It's weird how there are like two alternate realities of data compression.

"There's people who actually know WTF they're doing. (eg. encode.ru & the DCC's and so on). In that world you have compressors like PAQ, Nanozip, lzturbo, tornado, CCM, ZCM, Zstd, LZ4, BMF, BCIF, gralic, etc. etc.

"Then there's the mainstream world, where people still think gzip is state of the art (or ooh real modern bzip2), and they invent new things like brotli and webp and seem to not pay any attention to that alternate reality where the experts live. They sometimes do good work, but it's just a little odd."

- Charles Bloom, 10-02-15 (http://www.cbloom.com/rambles.html)

I disagree with it, but the Google C++ Style Guide offers the rationale you're looking for (under "On Unsigned Integers"): https://google-styleguide.googlecode.com/svn/trunk/cppguide....

My GCC seems to be GCC (don't remember why - I guess I installed it for something). I can also make it build using "--std=c99" (but that makes the undefined behavior mentioned in issue #2 show up, which is why I went with clang).

  gcc: warning: couldn't understand kern.osversion '14.3.0
  gcc (GCC) 4.8.2
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I too wrote a TIS-100 simulator in C ( https://github.com/hthh/tis100sim ) - it's interesting to compare styles.

(I get a bunch of errors on OS X unless I change "CC=gcc" to "CC=clang", btw)