As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal.

Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.

▲

dpc_01234 4 days ago | parent | next [-]

NPM dev gets hacked, packages compromised, it's detected within couple of hours.

XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections.

Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:

	▲	grayhatter 4 days ago \| parent \| next [-]
		xz didn't get hacked (phished). For xz an advanced persistent threat, inserted hypertargeted self modifying code into a tarball. A single npm dev was "hacked" (phished) by a moderate effort, (presumably drive by) crypto thief. I have no idea what you meant by "right inside _ssh_" but I don't think that's a good description of what actually happened in any possible case. I'm unlikely to defend C devel practices but this doesn't feel like an indictment of C, if anything the NPM ecosystem looks worse by this comparison. Especially considering the comment you replied to was advocating for minimizing dependencies, which if the distros effected by xz being compromised had followed, (instead of patching sshd) they wouldn't have shipped a compromised version.
	▲	typpilol 4 days ago \| parent \| prev [-]
		Lol it's so true.. the C smugness is unmatched

▲

1718627440 3 days ago | parent | prev | next [-]

This isn't part of the current discussion, but what is the appeal of single-header libraries?

Most times they actually are a normal .c/.h combo, but the implementation was moved to the "header" file and is simply only exposed by defining some macro. When it is actually a like a single file, that can be included multiple times, there is still code in it, so it is only a header file in name.

What is the big deal in actually using the convention like it is intended to and name the file containing the code *.c ? If is intended to only be included this can be still done.

> avoiding the C standard library are regressive and obsolete

I don't understand this as well, since the one half of libc are syscall wrappers and the other half are primitives which the compiler will use to replace your hand-rolled versions anyway. But this is not harming anyone and picking a good "core" library will probably make your code more consistent and readable.

	▲	dzaima 2 days ago \| parent [-]
		With just a single file you can trivially use it such that everything is inlined (if it's of the sort that static-s all functions, at least), even across multiple files using it, without needing the full compile-time-destruction of LTO. And generally it's one less file to look at, more easy to copy-paste into your project (and as a very minor security benefit you'll potentially look at arbitrary subsets of the contents every time you do a go-to-definition or use the header as docs (thus having chances to notice oddities) instead of just looking at a header).

▲

dboon 4 days ago | parent | prev [-]

Yeah lol I’m making a C package manager for exactly this. No transitive dependencies, no binaries served. Just pulling source code, building, and being smart about avoiding rebuilds.

	▲	eviks 4 days ago \| parent [-]
		Being smart about avoiding rebuilds is serving prebuilds