It's only used in the else, but yeah, I could move it up.

Why add whitespace before the function number?

With this decrement, the first iteration of the following loop will check the second-last character, not the last character. Is that intentional?

Can this be UB? With NDEBUG defined the compiler has no guarantee that cp is a valid pointer.

I've moved these out to a separate commit.

A stray tab. :)

Hmm, this is just copied from pciconf (which is also code I wrote). However, I do think it's true we do want to check that the last character is a valid digit. I think a string like "ppt0a" still ends up getting caught when strtol() below returns with *cp not equal to '\0'. Probably I did the cp-- originally to avoid checking the trailing nul. However, it's probably safer to drop the decrement, and I think it will work fine to reject values like an empty string (though the caller will never pass an empty string).

I don't think it can be given the constraint that name must be a valid C string? The one edge case currently that doesn't work is if name is an empty string and dropping the cp-- should handle that.

Yeah, I guess it would be "must be attached to by the ppt(4) device driver" but that's kind of a mouthful. In a way, you can view the "attach" relationship as bi-directional? Once the driver claims a device, the device is then attached to that driver? Could perhaps say "device .. must be owned/managed by ppt(4)", but "attached" seems to be the most accurate jargon in FreeBSD terms.

Oh, I will go with that actually.