On 2023-10-25, Maria Morisot <openbsd.g...@icloud.com> wrote: > Basically I just changed all instances of strcpy and sprintf to use strlcpy > and snprintf, because the compiler said to. >> >> This sort of change should go upstream rather than in ports. Be careful >> that you're using correct lengths though, it is possible to get things >> wrong and break programs. > > What does upstream mean, in the main source tree? I would have guessed that > such changes were already implemented in the main system.
If you're looking at code directly in an OpenBSD CVS repository and it still has strcpy/sprintf, it almost certainly does not originate from OpenBSD itself, rather comes from another origin, and often updated from time to time. Examples of this include most of the xenocara tree for X, some of the toolchain used to produce binaries (compilers, linkers and so on) and a few other parts of the system. Making changes like this to such code in the OpenBSD tree makes it difficult to update to newer versions; if done at all, it's usually done "the other way round" - changed in the origin, and then synced across as part of a later update to OpenBSD. Similarly for software in the ports tree, carrying patches for things like this often makes it difficult to update to a newer version. They're usually quite intrusive and affecting large parts of the source distribution. And while they can be simple, strcpy/sprintf/similar conversions still need careful review, to make sure that there aren't off-by-1 calculation errors in string length, or to make sure that actual string lengths are used and not e.g. size of a char * pointer. Generally I'd suggest that someone new to this finds problems/niggles in their use of the system, looks at how it works and figures out what's going on and what changes could be made to improve that. There's a lower risk of accidentally introducing problems if you're looking at code which you actually use rather than in a big sweep of the source tree, and probably better for gaining understanding. Also if there's some code which interests you, you might like to try seeing how it changed over time, how problems were fixed, etc (i.e. read the commit history - this may be simpler by using the mirror on github than cvs, as you can see changes grouped together as a whole commit, which can include changes to multiple files at once). A big part of working on software like this is understanding the history and why things were done. -- Please keep replies on the mailing list.
