The explicit expectation with the AUR has always been that you can't blindly trust the PKGBUILD files. It's more like running an installer from a random website on Windows than it is to using official distro repositories. I think the wiki also always advised against using AUR helper tools that blur the lines between official repositories and the AUR.
The Arch wiki explicitly links to the AUR for lots of things, but the prime example is probably the NVIDIA page - https://wiki.archlinux.org/title/NVIDIA - this page is going to be massively viewed, and if you have Pascal or older architecture the suggested driver is from, you guessed it, the AUR.
Nowhere on this page does it suggest that the AUR is at all untrustworthy.
The new latest version (commit 806789e4d454b, 307 bytes) should also work. It no longer sets p_memsz to something unreasonably large, which was most likely the issue with the 301-byte and 298-byte versions from a few days ago.
Looks like I may have stretched what values are acceptable for p_filesz/p_memsz too far. What's your kernel version? (I tested it on 6.8.0 and 4.4.0.) Perhaps the 316-byte version at commit 451827cfd5399074 (before that particular hack was introduced) would work.
GP is likely referring to how fields in the ELF and program header are abused for instructions and data in a way that happens to not break things on Linux.
If the savings are about `mov $1, %edi` and `mov $10, %ecx`, those 32-bit immediate values line up with the higher bytes of p_filesz and p_memsz in the program header, which have to be zero [1]. If not, what are the savings? :)
