Hi Bruno, Bruno Haible <[email protected]> writes:
> Arsen Arsenović wrote: >> I don't think Gnulib should be thought of as part of the implementation >> (thus, it should not have the right to use the implementation >> namespace). It is distributed as part of the application, and not being >> tested as part of the implementation, thus treating it as part of the >> implementation invites trouble. > > Gnulib sits between the implementation and the application. > Therefore the existing rule > "identifiers that start with underscore belong to the implementation, > identifiers that don't start with underscore belong to the application" > would leave no room for Gnulib. Indeed, but that doesn't really change anything. We can't just invent new room there. There's no room, and that's that. There's also no room for Gnulib in the implementation side. However, there's plenty of room in the application side. Gnulib is distributed as part of the application, pulled in by the application developer, tested as part of the application, and built by the application build system (*using* the implementation). It is *not* distributed as part of the implementation, pulled in by the implementation, tested as part of the implementation or built by the implementation build system. It is therefore part of the application. Yet Gnulib is using identifiers reserved for the implementation. Gnulib can declare that 'identifiers with the prefix "gl_" or "GL_" are reserved for gnulib' and that'd be fine. It cannot do so with "gl__" or "_GL_", however. Or it could not make such rules at all. Since Gnulib is vendored in the application, any identifier conflicts are detected by the application developers anyway (but such a rule is still useful due to conditional compilation). It is not part of the implementation, so any identifier conflicts with the implementation would be hard to detect, and would manifest as build failures for the user eventually, because there's no reason to expect a future implementation not to use those identifiers in whichever way it sees fit. GCC is right to define _T_ to whatever it wants. It would be valid for GCC N+1 to define it as the lyrics of L'Internationale; that's its prerogative, but it'd break Gnulib. > For functions and macros, after long discussions, we have adopted the > convention that for undocumented API we use identifiers that start with > gl_, _gl_, GL_, _GL_. > > For the template parameter, we could use '_GL_T' instead of 'T'. But this > appears to be even more ugly than '_T_'. It would also not resolve the problem, since that is still a reserved identifier. -- Arsen Arsenović
signature.asc
Description: PGP signature
