Bug 70686

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.