đž Archived View for it.omarpolo.com âş articoli âş openbsd-evoluzione-printf.gmi captured on 2024-06-16 at 12:23:27. Gemini links have been rewritten to link to archived content
âŹ ď¸ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Una delle cose che apprezzo di piĂš di OpenBSD (e di riflesso anche degli altri BSD, ma Open è il primo della classe in questo riguardo) è il âcoraggioâ di cambiare quando qualcosa non va bene, se non addirittura optare per la rimozione in toto.
Una delle novitĂ introdotte di recente e che molto probabilmente sarĂ presente anche nella prossima release è la deprecazione del supporto per â%nâ dalle funzioni stile printf in libc (printf(3), fprintf(3), âŚ).
Si tratta di un modificatore che scrive sul relativo puntatore passato il numero di byte scritti fino a quel momento. Può non sembrare, ma ha delle âserie implicazioni di sicurezzaâ e pertanto da un poâ di tempo su OpenBSD è stato cambiato in modo che logghi su syslog(3) e chiami abort(3).
(Onestamente non ho idea di quali siano le possibili problematiche, lâunica cosa che mi viene in mente riguarda lâoverflow di eventuali âintâ, che può essere effettivamente grave, ma credo ci sia altro. Anche la manpage di printf(3) di glibc ha una nota nella sezione BUGS che ne sconsiglia lâutilizzo.)
Da quello che visto su ports@ la maggior parte degli usi di %n sembrano essere dovuti alla dimenticanza che printf ritorna il numero totale di byte scritti, e quindi câè una valanga di diff tipo:
int n; - printf(â...%nâ, ..., &n); + n = printf(â...â, ...);
anche se ci sono usi piĂš âfantasiosiâ.
Lâispirazione dietro questo post mi è stata data da un commento (sempre su ports@) di Theo:
For the greater community in the coming years, it is still better to write best-possible diffs which remove it in our tree, then hope that upstreams eventually understand, and even later after that, pray for the greater ecosystem to decide that %n can be removed. This will take two decades. But if we don't start with a "technology demonstration that %n is deletable", then we'll never get there.
e di come, anche se questo è un caso piuttosto piccolo, OpenBSD abbia aperto la strada a diverse innovazioni.
In the past OpenBSD pushed risky theoretical ideas into mainstream software practice by proving the ecosystem was ready to change. No OS wants to make a ABI jump until the case for change is proven. Stack protection, ASLR, and W^X principles are now in common use by mainline operating systems... because things like Firefox and Postgresql don't break anymore. OpenBSD built that route.
Dal commentario per la canzone di OpenBSD 5.5: âWrap in Timeâ.
$BlogIt: openbsd-evoluzione-printf.gmi,v 1.1 2021/10/20 07:41:40 op Exp $