Pádraig Brady <p...@draigbrady.com> writes: > However if there are good use-cases for bad inputs > we may need to adjust this patch, > rather than failing unconditionally. > > For example we could just flag non canonical input in the context, > and leave it up to the caller how to deal with that.
That adds complexity -- I'd prefer to just default to fail and see if we get complaints. > It would be good to know an example of good use-cases > for bad inputs though, as I can't think of any. The simplest example of good use-case is to be able to decode existing incorrectly formatted inputs. However I think this is one that could be defered to other tools for that purpose, since generally this is not a trivial feature and it is a slippery slope to support all needs. This may becomes a problem if user failure happens at a very high level and doing the low-level base64-decoding separately is not feasible in an application, but let's see... /Simon
signature.asc
Description: PGP signature
