On Thu, Apr 22, 2004 at 12:12:24AM -0700, Chris Waters wrote: > On Thu, Apr 22, 2004 at 11:28:24AM +1000, Daniel Stone wrote: > > On Wed, Apr 21, 2004 at 11:51:58AM -0700, Chris Waters wrote: > > > Now, I'll grant that large parts of X11 predate the C standards, but > > > that's no excuse for ignoring the problem or pretending it doesn't > > > exist. There should be a plan in place for dealing with this sort of > > > thing. > > > OK, so let me dictate something on behalf of the XSF and X upstream and > > make existing, long-accepted practice absolutely clear: > > Let me repeat, "long-accepted practice" is no excuse for ignoring the > problem or pretending it doesn't exist. (And it may be long-accepted, > but it's not very widely accepted, or the ISO C committees wouldn't > have forbidden it.) Look, ISO C doesn't tell you to not use the same file 14 times in different places, with #define's modifying the behaviour. That doesn't mean it's not a stupid idea. As for 'not widely accepted', have a look at the kernel or any of those some time, and note the use of underscores. ISO C is not authoritive on use of the language, nor can anyone expect it to be. That's why you have common sense and generally-accepted practice to fill in the gaps; policy, as Manoj will tell you, reflects existing practice, not dictates it. Ask someone what an underscore in a symbol denotes. > > The use of a preceding underscore in functions, macros, variable names > > and/or other symbols in X code denotes internalisation, > > What part of "this code is relying on undefined behavior" don't you > understand? The code works fine. As long as it's not doing 'n += n++' or something, it's in the clear. It's OpenMotif's use of internal symbols that is very clearly in the wrong. Let me tell you that this is how it is. This will not change. Any bugs against it will be closed. It's internal API - deal. > > and MUST NOT be depended on by any other library. > > I agree, depending on undefined behavior is foolish. Both outside *and* > inside of X. Yes. That's why no-one writes code like 'n += n++'. > So technically, what we have here is two bugs. One against OpenMotif > for depending on X internal symbols (symbols with mandatorily > undefined behavior, at that). And one against X upstream for code > with undefined behavior. The behaviour of the code isn't undefined; one bug. > After fifteen years(!) there should be a plan for dealing with this > sort of thing! I'm not blaming you, I know you're not responsible, > but geeze! Even the BSDs only took five or six years to terms with > ISO C, and they started out convinced it was a AT&T plot! :) This is not ISO C. This is OpenMotif being too lazy to do something right, and stealing someone else's internal API to deal with that problem. This is not X's problem. This is not ISO C's problem. There is only one problem here, and that is that OpenMotif uses X's internal API. Internal APIs, by definition, cannot be relied upon. If they change behaviour, tough. You get to keep both pieces, and earn a smack upside the head along the way. Let me make this absolutely clear: a preceding underscore, in many projects (X, the Linux kernel, GNOME/GTk, others), denotes that the symbol is internal. Internal symbols must not be relied upon. If they are, this is a bug in the caller. If the internal symbols change and it is not visible to people using the externally-defined API (e.g. all the internal uses are changed to be consistent), there is no problem. If someone else is using the internal API, there is a problem that must be rectified. -- Daniel Stone <daniels@debian.org> Debian: the universal operating system http://www.debian.org
Attachment:
signature.asc
Description: Digital signature