I would like to point out that identifiers like "_XRENDER_H_" and "_XFUNCPROTOBEGIN" do not fit to the expected naming convention of the C language standard. http://cgit.freedesktop.org/xorg/lib/libXrender/tree/include/X11/extensions/Xrender.h?id=b3cfeecf2bddbbb120a9c796a4c9fb8fd08e15fc#n25 http://cgit.freedesktop.org/xorg/lib/libXrandr/tree/include/X11/extensions/Xrandr.h?id=6dfe7d4fa04a5054ee3daeb654ac5a763f37fed1#n37 Would you like to adjust your selection for unique names? https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier
No, we would not like to do that at all. Renaming _XFUNCPROTOBEGIN would require coordinated changes across dozens of modules for no real benefit. X predates the C language standards, and when written was considered part of the OS implementation, not an application. The odds that ISO C will ever create a _XFUNCPROTOBEGIN macro as part of future standards are very slim, and can be addressed in the unlikely event that ever happens.
(In reply to comment #1) > Renaming _XFUNCPROTOBEGIN would require coordinated changes across dozens > of modules for no real benefit. Can this standard incompliance mean that the current X server software builds on undefined behaviour? How are the chances to start a corresponding clean-up of affected identifiers with safer include guards?
Changing the include guards would be *less* safe, as we'd increase the odds of conflicting with application #defines.
(In reply to comment #3) > Changing the include guards would be *less* safe, as we'd increase the odds > of conflicting with application #defines. How do you think about the following adjustments? - Make them standard-compliant by the deletion of the leading underscore. http://en.wikipedia.org/wiki/Include_guard#Difficulties - They could also become unique by appending a kind of UUID. http://en.wikipedia.org/wiki/Universally_unique_identifier "universally unique identifier
(In reply to comment #4) > (In reply to comment #3) > > Changing the include guards would be *less* safe, as we'd increase the odds > > of conflicting with application #defines. > > How do you think about the following adjustments? > - Make them standard-compliant by the deletion of the leading underscore. > http://en.wikipedia.org/wiki/Include_guard#Difficulties > > - They could also become unique by appending a kind of UUID. > http://en.wikipedia.org/wiki/Universally_unique_identifier "universally > unique identifier I'm sure we'd take patches, but since this would be solving a problem that nobody appears to be having, I doubt anyone's likely to work on it in the near term.
(In reply to comment #5) How much are involved software developers interested to clean-up such a dependency on undefined behaviour? https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_106
(In reply to comment #6) > How much are involved software developers interested to clean-up such a > dependency on undefined behaviour? Not that interested, because it's not undefined for us. Such identifiers are reserved for use by "the implementation" - X is part of the Unix98 platform implementation, not an application. POSIX similarly defines a number of identifiers beginning with _ at the OS layer - surely you're not filing bugs against all those are you?
(In reply to comment #7) > POSIX similarly defines a number of identifiers beginning with _ at the OS > layer - surely you're not filing bugs against all those are you? It depends on the detail eventually if they belong also to a C/C++ compiler implementation.
(In reply to comment #5) > I'm sure we'd take patches, but since this would be solving a problem that > nobody appears to be having, I doubt anyone's likely to work on it in the > near term. Closing, as no patches are forthcoming, and still nobody is having any actual problem.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.