Zefram wrote: > I can see why it was done. (At least I think I can; it was done by you, > so maybe you can say better.) It just made sense to me for the laxer namegv requirements to be the default in the new API. > As you say, any caller new enough to > know about the _flags API is new enough to know about the new freedom > for namegv. And more than that, any new call checker ought to be written > to be called in the new way. So the flag state specified through direct > use of the _flags APIs should almost always indicate accepting the > greater latitude of namegv. It would be a hassle if one always had to > explicitly set a flag bit to indicate that. More convenient to invert > the flag's sense and have the recommended flags parameter value be zero. > Calls with the bit set then arise mainly from using the pre-_flags APIs. Well, until we can envision what types of flags we will need to add in the future, I think that tying the two flags parameters to each other may just limit our possibilities. Would it not make more sense to say that gflags is reserved for future use and should be 0?Thread Previous | Thread Next