You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If i set some currently-unused bit in a GMimeVerifyFlags or GMimeDecryptFlags variable, and then try to use it, I don't think GMime notices that the unused bit is set.
This results in a potential for a broken API -- if version X of gmime introduces a new flag, and i build against it and use that flag, and then i run against version X-1, then the flag will be supplied and ignored.
GMime should check if any unused flags are set, and if so, raise an error (if you're not comfortable with this update in the 3.x series, please at least consider this defensive approach when considering how to resolve #70).
If this seems too extreme (for example, if you contemplate adding some flag or flags in the future that are or should be ignorable/best-effort, and therefore it isn't an error to send them to a non-implementing version), perhaps we could set aside some range of bits that would be ignorable/best-effort. Then when a new flag is added, we can reason about which bitfield to place the new flag in, based on our understanding of the intended semantics.
The text was updated successfully, but these errors were encountered:
If i set some currently-unused bit in a GMimeVerifyFlags or GMimeDecryptFlags variable, and then try to use it, I don't think GMime notices that the unused bit is set.
This results in a potential for a broken API -- if version X of gmime introduces a new flag, and i build against it and use that flag, and then i run against version X-1, then the flag will be supplied and ignored.
GMime should check if any unused flags are set, and if so, raise an error (if you're not comfortable with this update in the 3.x series, please at least consider this defensive approach when considering how to resolve #70).
If this seems too extreme (for example, if you contemplate adding some flag or flags in the future that are or should be ignorable/best-effort, and therefore it isn't an error to send them to a non-implementing version), perhaps we could set aside some range of bits that would be ignorable/best-effort. Then when a new flag is added, we can reason about which bitfield to place the new flag in, based on our understanding of the intended semantics.
The text was updated successfully, but these errors were encountered: