Seems like a lost opportunity to introduce 0xFF as the error code that means "look in the extended error field we've since added to the message, which includes a u32 _and_ a human readable string for display" to be honest.
Re:Lessons from Ancient File Systems
by didgetmaster on Tuesday July 30, 2024 @01:04PM
(#41111480)
It's been many years ago; but if memory serves...the error code was part of a header in a server response packet. Expanding that header to include another field would break all the clients and handler software.
Eventually, a major release fixed the problem with a different header with expanded fields; but that was not a simple fix. Like I said, backwards compatibility CAN be the bane of innovation.
Deciding what are 'acceptable' limitations given current constraints vs 'planning for future expansion' is an art form. Unfortunately, too little thought is actually put into that decision in too many cases.
I remember working on a system (NetWare) when the server error code was a single byte. It didn't take long to run out and they started assigning the same error code to multiple conditions. The last one (0xFF) was so widely used, internal docs referred to it as 'something bad happened'.