This is always true...

why redirect read(2) and none of the other system calls that write back into user space?

I don't see any others in NetBSD's either. Expanding it is a big ask, so before I really do that as more than maybe a suggestion, I'd like to know the thinking here.

Fair point; I'll hack it back out in the second patch that reworks part of these headers for FreeBSD (with a brief explanation that it's tautological here)

I think they more or less tried to stick with the common _FORTIFY_SOURCE implementation (glibc). We can expand it, but IMO let's get to the baseline and define expanding it as future work (explicitly in the commit message) -- the baseline should be 'relatively safe' as folks have been running with glibc's implementation for years as it is.

I do not think lint is relevant for FreeBSD.

These lint-style comments (as well LINTLIBRARY) are not relevant either.

The counter you your argument may also be that fortify_source was done years ago and is showing its age :)....
But what you suggest works for me, so long as we understand that followup work might be good to increase the coverage. Mostly I wanted to understand why it was incomplete.

Is this true?

I added the comment based on the greatest of technicalities, that it appeared in our version of libssp in 13.0-CURRENT (since I added our version of libssp in cd0d51baaa4509a1d); happy enough to revise it, though.

Ok it's fine with me 👍

Would be good if you could also mention FreeBSD here.

Matters word order. :-)

"in" missing unless .Nx does more than what I remember .Fx doing. (Maybe let upstream know as well?)

Can we use gcc ({}) extension there to avoid multiple evaluations for the args?
It still would cause multi-eval when real function is called after __ssp_overlap, though.

This should become 1.8

extern is not needed

15.0

We could, though it looks like __ssp_overlap is really only intended to be used in libc so I think I'll move it into an ssp_private.h in libc.

What does it mean for the object to not have a side effect?

I'll revise this based on experimentation; the point is, as you probably guessed, that ptr is really just an expression that may or may not have side effects. Consider this example, which must be built with -O1 or higher:

#include <stdio.h>                                                                                            
                                                                                                              
int                                                                                                           
main()                                                                                                        
{                                                                                                             
    char buf[64], *p = buf;                                                                                   
                                                                                                              
    printf("%zu\n", __builtin_object_size(p, 0));                                                             
    printf("%zu\n", __builtin_object_size(++p, 0));                                                           
}

The first printf() gets you 64, the second one gets you (size_t)-1 and p remains unadvanced; this seems like a further argument for the conversion to compound statements, easier to reason about and avoids disabling fortification because of a technicality.

This doesn't quite work because of, e.g., gems like this from fortune:

460 |                 strcat(strcat(strcpy(tpath, dir), "/"), file);

This looks stilted to me. Maybe "knows can be pointed"?

Does this apply to clang as well? If so, I'd mention both.

Add clang here if added above.

This is referring to https://svnweb.freebsd.org/base/?view=revision&revision=r356356, it just didn't get a man page back then and these symbols aborted.