stb Documentation

Technical Documentation: nothings/stb

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

stb

single-file public domain (or MIT licensed) libraries for C/C++

This project discusses security-relevant bugs in public in Github Issues and Pull Requests, and it may take significant time for security fixes to be implemented or merged. If this poses an unreasonable risk to your project, do not use stb libraries.

Noteworthy:

• image loader: stb_image.h
• image writer: stb_image_write.h
• image resizer: stb_image_resize2.h
• font text rasterizer: stb_truetype.h
• typesafe containers: stb_ds.h

Most libraries by stb, except: stb_dxt by Fabian "ryg" Giesen, original stb_image_resize
by Jorge L. "VinoBS" Rodriguez, and stb_image_resize2 and stb_sprintf by Jeff Roberts.

Total libraries: 21
Total lines of C code: 51166

FAQ Copy Chapter

What's the license?

These libraries are in the public domain. You can do anything you
want with them. You have no legal obligation
to do anything else, although I appreciate attribution.

They are also licensed under the MIT open source license, if you have lawyers
who are unhappy with public domain. Every source file includes an explicit
dual-license for you to choose from.

How do I use these libraries?

The idea behind single-header file libraries is that they're easy to distribute and deploy
because all the code is contained in a single file. By default, the .h files in here act as
their own header files, i.e. they declare the functions contained in the file but don't
actually result in any code getting compiled.

So in addition, you should select exactly one C/C++ source file that actually instantiates
the code, preferably a file you're not editing frequently. This file should define a
specific macro (this is documented per-library) to actually enable the function definitions.
For example, to use stb_image, you should have exactly one C/C++ file that doesn't
include stb_image.h regularly, but instead does

#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

The right macro to define is pointed out right at the top of each of these libraries.

Are there other single-file public-domain/open source libraries with minimal dependencies out there?

Yes.

If I wrap an stb library in a new library, does the new library have to be public domain/MIT?

No, because it's public domain you can freely relicense it to whatever license your new
library wants to be.

What's the deal with SSE support in GCC-based compilers?

stb_image will either use SSE2 (if you compile with -msse2) or
will not use any SIMD at all, rather than trying to detect the
processor at runtime and handle it correctly. As I understand it,
the approved path in GCC for runtime-detection require
you to use multiple source files, one for each CPU configuration.
Because stb_image is a header-file library that compiles in only
one source file, there's no approved way to build both an
SSE-enabled and a non-SSE-enabled variation.

While we've tried to work around it, we've had multiple issues over
the years due to specific versions of gcc breaking what we're doing,
so we've given up on it. See https://github.com/nothings/stb/issues/280
and https://github.com/nothings/stb/issues/410 for examples.

Some of these libraries seem redundant to existing open source libraries. Are they better somehow?

Generally they're only better in that they're easier to integrate,
easier to use, and easier to release (single file; good API; no
attribution requirement). They may be less featureful, slower,
and/or use more memory. If you're already using an equivalent
library, there's probably no good reason to switch.

Can I link directly to the table of stb libraries?

You can use this URL to link directly to that list.

Why do you list "lines of code"? It's a terrible metric.

Just to give you some idea of the internal complexity of the library,
to help you manage your expectations, or to let you know what you're
getting into. While not all the libraries are written in the same
style, they're certainly similar styles, and so comparisons between
the libraries are probably still meaningful.

Note though that the lines do include both the implementation, the
part that corresponds to a header file, and the documentation.

Why single-file headers?

Windows doesn't have standard directories where libraries
live. That makes deploying libraries in Windows a lot more
painful than open source developers on Unix-derivates generally
realize. (It also makes library dependencies a lot worse in Windows.)

There's also a common problem in Windows where a library was built
against a different version of the runtime library, which causes
link conflicts and confusion. Shipping the libs as headers means
you normally just compile them straight into your project without
making libraries, thus sidestepping that problem.

Making them a single file makes it very easy to just
drop them into a project that needs them. (Of course you can
still put them in a proper shared library tree if you want.)

Why not two files, one a header and one an implementation?
The difference between 10 files and 9 files is not a big deal,
but the difference between 2 files and 1 file is a big deal.
You don't need to zip or tar the files up, you don't have to
remember to attach two files, etc.

Why "stb"? Is this something to do with Set-Top Boxes?

No, they are just the initials for my name, Sean T. Barrett.
This was not chosen out of egomania, but as a moderately sane
way of namespacing the filenames and source function names.

Will you add more image types to stb_image.h?

No. As stb_image use has grown, it has become more important
for us to focus on security of the codebase. Adding new image
formats increases the amount of code we need to secure, so it
is no longer worth adding new formats.

Do you have any advice on how to create my own single-file library?

Yes. https://github.com/nothings/stb/blob/master/docs/stb_howto.txt

Why public domain?

I prefer it over GPL, LGPL, BSD, zlib, etc. for many reasons.
Some of them are listed here:
https://github.com/nothings/stb/blob/master/docs/why_public_domain.md

Why C?

Primarily, because I use C, not C++. But it does also make it easier
for other people to use them from other languages.

Why not C99? stdint.h, declare-anywhere, etc.

I still use MSVC 6 (1998) as my IDE because it has better human factors
for me than later versions of MSVC.

Overview (`.NO_AI/README.md`) Copy Section

Use of AI is forbidden, see CONTRIBUTING.md for details.

Overview (`tests/caveview/README.md`) Copy Section

FAQ

How to run it? Copy Section

There's no GUI. Find a directory with Minecraft Anvil files (.mca).
Copy a Minecraft "terrain.png" into that directory (do a google
image search). Run from that directory.

How accurate is this as a Minecraft viewer? Copy Section

Not very. Many Minecraft blocks are not handled correctly:

• text Copy

  No redstone, rails, or other "flat" blocks

• text Copy

  No signs, doors, fences, carpets, or other complicated geometry

• text Copy

  Stairs are turned into ramps

• text Copy

  Upper slabs turn into lower slabs

• text Copy

  Wood types only for blocks, not stairs, slabs, etc

• text Copy

  Colored glass becomes regular glass

• text Copy

  Glass panes become glass blocks

• text Copy

  Water is opaque

• text Copy

  Water level is incorrect

• text Copy

  No biome coloration

• text Copy

  Cactus is not shrunk, shows holes

• text Copy

  Chests are not shrunk

• text Copy

  Double-chests draw as two chests

• text Copy

  Pumpkins etc. are not rotated properly

• text Copy

  Torches are drawn hackily, do not attach to walls

• text Copy

  Incorrect textures for blocks that postdate terrain.png

• text Copy

  Transparent textures have black fringes due to non-premultiplied-alpha

• text Copy

  Skylight and block light are combined in a single value

• text Copy

  Only blocks at y=1..255 are shown (not y=0)

• text Copy

  If a 32x32x256 "quad-chunk" needs more than 800K quads, isn't handled (very unlikely)

Some of these are due to engine limitations, and some of
these are because I didn't make the effort since my
goal was to make a demo for stb_voxel_render.h, not
to make a proper Minecraft viewer.

Could this be turned into a proper Minecraft viewer? Copy Section

Yes and no. Yes, you could do it, but no, it wouldn't
really resemble this code that much anymore.

You could certainly use this engine to
render the parts of Minecraft it works for, but many
of the things it doesn't handle it can't handle at all
(stairs, water, fences, carpets, etc) because it uses
low-precision coordinates to store voxel data.

You would have to render all of the stuff it doesn't
handle through another rendering path. In a game (not
a viewer) you would need such a path for movable entities
like doors and carts anyway, so possibly handling other
things that way wouldn't be so bad.

Rails, ladders, and redstone lines could be implemented by
using tex2 to overlay those effects, but you can't rotate
tex1 and tex2 independently, so there may be cases where
the underlying texture needs a different rotation from the
overlaid texture, which would require separate rendering.
Handling redstone's brightness being different from underlying
block's brightness would require separate rendering.

You can use the face-color effect to do biome coloration,
but the change won't be smooth the way it is in Minecraft.

Why isn't building the mesh data faster? Copy Section

Partly because converting from minecraft data is expensive.

Here is the approximate breakdown of an older version
of this executable and lib that did the building single-threaded.

• text Copy

  25%   loading & parsing minecraft files (4/5ths of this is my crappy zlib)

• text Copy

  18%   converting from minecraft blockids & lighting to stb blockids & lighting

• text Copy

  10%   reordering from data[z][y]\[x] (minecraft-style) to data[y][x]\[z] (stb-style)

• text Copy

  40%   building mesh data

• text Copy

  7%   uploading mesh data to OpenGL

I did do significant optimizations after the above, so the
final breakdown is different, but it should give you some
sense of the costs.

Overview (`tests/oversample/README.md`) Copy Section

Font character oversampling for rendering from atlas textures

TL,DR: Run oversample.exe on a windows machine to see the
benefits of oversampling. It will try to use arial.ttf from the
Windows font directory unless you type the name of a .ttf file as
a command-line argument.

Benefits of oversampling Copy Chapter

Oversampling is a mechanism for improving subpixel rendering of characters.

Improving subpixel has a few benefits:

• With horizontal-oversampling, text can remain sharper while still being sub-pixel positioned for better kerning
• Horizontally-oversampled text significantly reduces aliasing when text animates horizontally
• Vertically-oversampled text significantly reduces aliasing when text animates vertically
• Text oversampled in both directions significantly reduces aliasing when text rotates

What text oversampling is Copy Chapter

A common strategy for rendering text is to cache character bitmaps
and reuse them. For hinted characters, every instance of a given
character is always identical, so this works fine. However, stb_truetype
doesn't do hinting.

For anti-aliased characters, you can actually position the characters
with subpixel precision, and get different bitmaps based on that positioning
if you re-render the vector data.

However, if you simply cache a single version of the bitmap and
draw it at different subpixel positions with a GPU, you will get
either the exact same result (if you use point-sampling on the
texture) or linear filtering. Linear filtering will cause a sub-pixel
positioned bitmap to blur further, causing a visible de-sharpening
of the character. (And, since the character wasn't hinted, it was
already blurrier than a hinted one would be, and now it gets even
more blurry.)

You can avoid this by caching multiple variants of a character which
were rendered independently from the vector data. For example, you
might cache 3 versions of a char, at 0, 1/3, and 2/3rds of a pixel
horizontal offset, and always require characters to fall on integer
positions vertically.

When creating a texture atlas for use on GPUs, which support bilinear
filtering, there is a better approach than caching several independent
positions, which is to allow lerping between the versions to allow
finer subpixel positioning. You can achieve these by interleaving
each of the cached bitmaps, but this turns out to be mathematically
equivalent to a simpler operation: oversampling and prefiltering the
characters.

So, setting oversampling of 2x2 in stb_truetype is equivalent to caching
each character in 4 different variations, 1 for each subpixel position
in a 2x2 set.

An advantage of this formulation is that no changes are required to
the rendering code; the exact same quad-rendering code works, it just
uses different texture coordinates. (Note this does potentially increase
texture bandwidth for text rendering since we end up minifying the texture
without using mipmapping, but you probably are not going to be fill-bound
by your text rendering.)

What about gamma? Copy Chapter

Gamma-correction for fonts just doesn't work. This doesn't seem to make
much sense -- it's physically correct, it simulates what we'd see if you
shrunk a font down really far, right?

But you can play with it in the oversample.exe app. If you turn it on,
white-on-black fonts become too thick (i.e. they become too bright), and
black-on-white fonts become too thin (i.e. they are insufficiently dark). There is
no way to adjust the font's inherent thickness (i.e. by switching to
bold) to fix this for both; making the font thicker will make white
text worse, and making the font thinner will make black text worse.
Obviously you could use different fonts for light and dark cases, but
this doesn't seem like a very good way for fonts to work.

Multiple people who have experimented with this independently (me,
Fabian Giesen,and Maxim Shemanarev of Anti-Grain Geometry) have all
concluded that correct gamma-correction does not produce the best
results for fonts. Font rendering just generally looks better without
gamma correction (or possibly with some arbitrary power stuck in
there, but it's not really correcting for gamma at that point). Maybe
this is in part a product of how we're used to fonts being on screens
which has changed how we expect them to look (e.g. perhaps hinting
oversharpens them and prevents the real-world thinning you'd see in
a black-on-white text).

(AGG link on text rendering, including mention of gamma:
http://www.antigrain.com/research/font_rasterization/ )

Nevertheless, even if you turn on gamma-correction, you will find that
oversampling still helps in many cases for small fonts.

Other Libs (`docs/other_libs.md`) Copy Section

Moved to https://github.com/nothings/single_file_libs

Stb Howto (`docs/stb_howto.txt`) Copy Section

Lessons learned about how to make a header-file library
V1.0
September 2013 Sean Barrett

Things to do in an stb-style header-file library,
and rationales:

1. #define LIBRARYNAME_IMPLEMENTATION

Use a symbol like the above to control creating
the implementation. (I used a far-less-clear name
in my first header-file library; it became
clear that was a mistake once I had multiple
libraries.)

Include a "header-file" section with header-file
guards and declarations for all the functions,
but only guard the implementation with LIBRARYNAME_IMPLEMENTATION,
not the header-file guard. That way, if client's
header file X includes your header file for
declarations, they can still include header file X
in the source file that creates the implementation;
if you guard the implementation too, then the first
include (before the #define) creates the declarations,
and the second one (after the #define) does nothing.

2. AVOID DEPENDENCIES

Don't rely on anything other than the C standard libraries.

(If you're creating a library specifically to leverage/wrap
some other library, then obviously you can rely on that
library. But if that library is public domain, you might
be better off directly embedding the source, to reduce
dependencies for your clients. But of course now you have
to update whenever that library updates.)

If you use stdlib, consider wrapping all stdlib calls in
macros, and then conditionally define those macros to the
stdlib function, allowing the user to replace them.

For functions with side effects, like memory allocations,
consider letting the user pass in a context and pass
that in to the macros. (The stdlib versions will ignore
the parameter.) Otherwise, users may have to use global
or thread-local variables to achieve the same effect.

3. AVOID MALLOC

You can't always do this, but when you can, embedded developers
will appreciate it. I almost never bother avoiding, as it's
too much work (and in some cases is pretty infeasible;
see http://nothings.org/gamedev/font_rendering_malloc.txt ).
But it's definitely something one of the things I've gotten
the most pushback on from potential users.

4. ALLOW STATIC IMPLEMENTATION

Have a #define which makes function declarations and
function definitions static. This makes the implementation
private to the source file that creates it. This allows
people to use your library multiple times in their project
without collision. (This is only necessary if your library
has configuration macros or global state, or if your
library has multiple versions that are not backwards
compatible. I've run into both of those cases.)

5. MAKE ACCESSIBLE FROM C

Making your code accessible from C instead of C++ (i.e.
either coding in C, or using extern "C") makes it more
straightforward to be used in C and in other languages,
which often only have support for C bindings, not C++.
(One of the earliest results I found in googling for
stb_image was a Haskell wrapper.) Otherwise, people
have to wrap it in another set of function calls, and
the whole point here is to make it convenient for people
to use, isn't it? (See below.)

I prefer to code entirely in C, so the source file that
instantiates the implementation can be C itself, for
those crazy people out there who are programming in C.
But it's probably not a big hardship for a C programmer
to create a single C++ source file to instantiate your
library.

6. NAMESPACE PRIVATE FUNCTIONS

Try to avoid having names in your source code that
will cause conflicts with identical names in client
code. You can do this either by namespacing in C++,
or prefixing with your library name in C.

In C, generally, I use the same prefix for API
functions and private symbols, such as "stbtt_"
for stb_truetype; but private functions (and
static globals) use a second underscore as
in "stbtt__" to further minimize the chance of
additional collisions in the unlikely but not
impossible event that users write wrapper
functions that have names of the form "stbtt_".
(Consider the user that has used "stbtt_foo"
successfully, and then upgrades to a new
version of your library which has a new private
function named either "stbtt_foo" or "stbtt__foo".)

Note that the double-underscore is reserved for
use by the compiler, but (1) there is nothing
reserved for "middleware", i.e. libraries
desiring to avoid conflicts with user symbols
have no other good options, and (2) in practice
no compilers use double-underscore in the middle
rather than the beginning/end. (Unfortunately,
there is at least one videogame-console compiler that
will warn about double-underscores by default.)

7. EASY-TO-COMPLY LICENSE

I make my libraries public domain. You don't have to.
But my goal in releasing stb-style libraries is to
reduce friction for potential users as much as
possible. That means:

a. easy to build (what this file is mostly about)
b. easy to invoke (which requires good API design)
c. easy to deploy (which is about licensing)

I choose to place all my libraries in the public
domain, abjuring copyright, rather than license
the libraries. This has some benefits and some
drawbacks.

Any license which is "viral" to modifications
causes worries for lawyers, even if their programmers
aren't modifying it.

Any license which requires crediting in documentation
adds friction which can add up. Valve used to have
a page with a list of all of these on their web site,
and it was insane, and obviously nobody ever looked
at it so why would you care whether your credit appeared
there?

Permissive licenses like zlib and BSD license are
perfectly reasonable, but they are very wordy and
have only two benefits over public domain: legally-mandated
attribution and liability-control. I do not believe these
are worth the excessive verbosity and user-unfriendliness
these licenses induce, especially in the single-file
case where those licenses tend to be at the top of
the file, the first thing you see. (To the specific
points, I have had no trouble receiving attribution
for my libraries; liability in the face of no explicit
disclaimer of liability is an open question.)

However, public domain has frictions of its own, because
public domain declarations aren't necessary recognized
in the USA and some other locations. For that reason,
I recommend a declaration along these lines:

// This software is dual-licensed to the public domain and under the following
// license: you are granted a perpetual, irrevocable license to copy, modify,
// publish, and distribute this file as you see fit.

I typically place this declaration at the end of the initial
comment block of the file and just say 'public domain'
at the top.

I have had people say they couldn't use one of my
libraries because it was only "public domain" and didn't
have the additional fallback clause, who asked if
I could dual-license it under a traditional license.

My answer: they can create a derivative work by
modifying one character, and then license that however
they like. (Indeed, adding the zlib or BSD license
would be such a modification!) Unfortunately, their
lawyers reportedly didn't like that answer. :(

Stb Voxel Render Interview (`docs/stb_voxel_render_interview.md`) Copy Section

An interview with STB about stb_voxel_render.h

Q:
I suppose you really like Minecraft?

A:
Not really. I mean, I do own it and play it some, and
I do watch YouTube videos of other people playing it
once in a while, but I'm not saying it's that great.

But I do love voxels. I've been playing with voxel rendering
since the mid-late 90's when we were still doing software
rendering and thinking maybe polygons weren't the answer.
Once GPUs came along that kind of died off, at least until
Minecraft brought it back to attention.

Q:
Do you expect people will make a lot of Minecraft clones
with this?

A:
I hope not!

For one thing, it's a terrible idea for the
developer. Remember before Minecraft was on the Xbox 360,
there were a ton of "indie" clones (some maybe making
decent money even), but then the real Minecraft came out
and just crushed them (as far as I know). It's just not
something you really want to compete with.

The reason I made this library is because I'd like
to see more games with Minecraft's art style, not
necessary its gameplay.

I can understand the urge to clone the gameplay. When
you have a world made of voxels/blocks, there are a
few things that become incredibly easy to do that would
otherwise be very hard (at least for an indie) to do in 3D.
One thing is that procedural generation becomes much easier.
Another is that destructible environments are easy. Another
is that you have a world where your average user can build
stuff that they find satisfactory.

Minecraft is at a sort of local maximum, a sweet spot, where
it leverages all of those easy-to-dos. And so I'm sure it's
hard to look at the space of 'games using voxels' and move
away from that local maximum, to give up some of that.
But I think that's what people should do.

Q:
So what else can people do with stb_voxel_render?

A:
All of those benefits I mentioned above are still valid even
if you stay away from the sweet spot. You can make a 3D roguelike
without player-creation/destruction that uses procedural generation.
You could make a shooter with pre-designed maps but destructible
environments.

And I'm sure there are other possible benefits to using voxels/blocks.
Hopefully this will make it easier for people to explore the space.

The library has a pretty wide range of features to allow
people to come up with some distinctive looks. For example,
the art style of Continue?9876543210 was one of the inspirations
for trying to make the multitexturing capabilities flexible.
I'm terrible at art, so this isn't really something I can
come up with myself, but I tried to put in flexible
technology that could be used multiple ways.

One thing I did intentionally was try to make it possible to
make nicer looking ground terrain, using the half-height
slopes and "weird slopes". There are Minecraft mods with
drivable cars and they just go up these blocky slopes and,
like, what? So I wanted you to be able to make smoother
terrain, either just for the look, or for vehicles etc.
Also, you can spatially cross-fade between two ground textures for
that classic bad dirt/grass transition that has shipped
in plenty of professional games. Of course, you could
just use a separate non-voxel ground renderer for all of
this. But this way, you can seamlessly integrate everything
else with it. E.g. in your authoring tool (or procedural
generation) you can make smooth ground and then cut a
sharp-edged hole in it for a building's basement or whatever.

Another thing you can do is work at a very different scale.
In Minecraft, a person is just under 2 blocks tall. In
Ace of Spades, a person is just under 3 blocks tall. Why
not 4 or 6? Well, partly because you just need a lot more
voxels; if a meter is 2 voxels in Mineraft and 4 voxels in
your game, and you draw the same number of voxels due to
hardware limits, then your game has half the view distance
of Minecraft. Since stb_voxel_render is designed to keep
the meshes small and render efficiently, you can push the
view distance out further than Minecraft--or use a similar
view distance and a higher voxel resolution. You could also
stop making infinite worlds and work at entirely different
scales; where Minecraft is 1 voxel per meter, you could
have 20 voxels per meter and make a small arena that's
50 meters wide and 5 meters tall.

Back when the voxel game Voxatron was announced, the weekend
after the trailer came out I wrote my own little GPU-accelerated
version of the engine and thought that was pretty cool. I've
been tempted many times to extract that and release it
as a library, but
I don't want to steal Voxatron's thunder so I've avoided
it. You could use this engine to do the same kind of thing,
although it won't be as efficient as an engine dedicated to
that style of thing would be.

Q:
What one thing would you really like to see somebody do?

A:
Before Unity, 3D has seemed deeply problematic in the indie
space. Software like GameMaker has tried to support 3D but
it seems like little of note has been done with it.

Minecraft has shown that people can build worlds with the
Minecraft toolset far more easily than we've ever seen from those
other tools. Obviously people have done great things with
Unity, but those people are much closer to professional
developers; typically they still need real 3D modelling
and all of that stuff.

So what I'd really like to see is someone build some kind
of voxel-game-construction-set. Start with stb_voxel_render,
maybe expose all the flexibility of stb_voxel_render (so
people can do different things). Thrown in lua or something
else for scripting, make some kind of editor that feels
at least as good as Minecraft and Infinifactory, and see
where that gets you.

Q:
Why'd you make this library?

A:
Mainly as a way of releasing this technology I've been working
on since 2011 and seemed unlikely to ever ship myself. In 2011
I was playing the voxel shooter Ace of Spades. One of the maps
that we played on was a partial port of Broville (which is the
first Minecraft map in stb_voxel_render release trailer). I'd
made a bunch of procedural level generators for the game, and
I started trying to make a city generator inspired by Broville.

But I realized it would be a lot of work, and of very little
value (most of my maps didn't get much play because people
preferred to play on maps where they could charge straight
at the enemies and shoot them as fast as possible). So I
wrote my own voxel engine and started working on a procedural
city game. But I got bogged down after I finally got the road
generator working and never got anywhere with building
generation or gameplay.

stb_voxel_render is actually a complete rewrite from scratch,
but it's based a lot on what I learned from that previous work.

Q:
About the release video... how long did that take to edit?

A:
About seven or eight hours. I had the first version done in
maybe six or seven hours, but then I realized I'd left out
one clip, and when I went back to add it I also gussied up
a couple other moments in the video. But there was something
basically identical to it that was done in around six.

Q:
Ok, that's it. Thanks, me.

A:
Thanks me!

Why Public Domain (`docs/why_public_domain.md`) Copy Section

My collected rationales for placing these libraries
in the public domain:

1. Public domain vs. viral licenses

Why is this library public domain?
Because more people will use it. Because it's not viral, people are
not obligated to give back, so you could argue that it hurts the
development of it, and then because it doesn't develop as well it's
not as good, and then because it's not as good, in the long run
maybe fewer people will use it. I have total respect for that
opinion, but I just don't believe it myself for most software.

2. Public domain vs. attribution-required licenses

The primary difference between public domain and, say, a Creative Commons
commercial / non-share-alike / attribution license is solely the
requirement for attribution. (Similarly the BSD license and such.)
While I would appreciate acknowledgement and attribution, I believe
that it is foolish to place a legal encumberment (i.e. a license) on
the software solely to get attribution.

In other words, I'm arguing that PD is superior to the BSD license and
the Creative Commons 'Attribution' license. If the license offers
anything besides attribution -- as does, e.g., CC NonCommercial-ShareAlike,
or the GPL -- that's a separate discussion.

3. Other aspects of BSD-style licenses besides attribution

Permissive licenses like zlib and BSD license are perfectly reasonable
in their requirements, but they are very wordy and
have only two benefits over public domain: legally-mandated
attribution and liability-control. I do not believe these
are worth the excessive verbosity and user-unfriendliness
these licenses induce, especially in the single-file
case where those licenses tend to be at the top of
the file, the first thing you see.

To the specific points, I have had no trouble receiving
attribution for my libraries; liability in the face of
no explicit disclaimer of liability is an open question,
but one I have a lot of difficulty imagining there being
any actual doubt about in court. Sometimes I explicitly
note in my libraries that I make no guarantees about them
being fit for purpose, but it's pretty absurd to do this;
as a whole, it comes across as "here is a library to decode
vorbis audio files, but it may not actually work and if
you have problems it's not my fault, but also please
report bugs so I can fix them"--so dumb!

4. full discussion from stb_howto.txt on what YOU should do for YOUR libs

/* Detailed source-code truncated for AI context efficiency. */

--- METRICS ---

• Files Extracted: 8
• Estimated Token Budget: ~8693 tokens
• Canonical Reference: https://codewiki.google/github.com/nothings/stb