Hello, While refactoring flashrom.c to move towards a reentrant flashrom a pragmatic choice of utilising NULLity to represent the default state of a struct at instiation was used in the following and related commits - https://review.coreboot.org/c/flashrom/+/67391/
It was brought to my attention that this is perhaps considered a more substantive change to the general practice within flashrom and so I just wanted to give a brief prelude to the rationale and if anyone has any reason why they don't like it. Basically using NULL as the default state rather than an invalid state allows for memory address by value to be in a boolean state of either 'defined to be default' or 'defined to be custom' - over that of a tristate of 'defiled to be default explicitly', 'defined to be custom' or NULL which must be manually validated as 'invalid'. This is quite pragmatic as we can rid ourselves of explicit nullarity checks at runtime and instead have always defined reasonable defaults at compile-time thus making functions domains more well defined at compile-time. It is also pragmatic and arguably more modern from the stand-point of requiring less code to effectively obtain a valid value from the instantiated type not unlike Rust's Default trait or Ada's ability to have default values in a Record and so on. While not particularly novel I did want to follow up on the request to highlight it here. Kindly, Edward.
_______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
