Understanding glibc source code conventions

后端 未结 2 773
太阳男子
太阳男子 2021-02-08 19:03

I\'ve been looking at some of the source code for glibc, in particular the nptl code, and I\'ve found it a little bit hard to understand since it seems to have conventions that

相关标签:
2条回答
  • 2021-02-08 19:13
    1. Old writing.
    2. To ensure the type of __pthread_equal, pthread_equal to same.
    3. To distinguish between variable names, and distinguish between core area and user area.
    0 讨论(0)
  • 2021-02-08 19:15

    The function is written without requiring a C89 compliant compiler; it will work with older compilers too. That is a non-prototype function definition.

    int   /* Return type */
    function(arg1, arg2)    /* Function name and argument names (but no types) */
        int arg1;    /* Type of arg1 */
        char *arg2;  /* Type of arg2 */
    {
        /* Body of function */
    }
    

    Note that the definitions of the arguments do not have to be in the same sequence as in the function line (I've had to convert code from this 'K&R' notation to prototype notation where they were out of order!). Also note that it used to be possible to simply write:

    main(argc, argv)
        char **argv;
    {
        ...
    }
    

    The implied type for argc was int since it wasn't specified as anything else. It is unlikely that the glib code takes advantage of that licence. Similarly, the return type of main() was int because no other type was given.

    The strong_alias is related to hiding and exposing symbols in shared libraries. I've not used it, so I'm not sure of all the ramifications, but I believe it means that __pthread_equal() is another name for the pthread_equal() function.


    One part of the reasoning behind the __pthread_equal() name is that names starting with an underscore followed by an upper-case letter or another underscore are 'reserved to the implementation' by the C Standard. Names such as 'pthread_equal()' are in the users' name space according to the C standard.

    ISO/IEC 9899:1990 (the C99 standard) says:

    7.1.3 Reserved identifiers

    Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

    — All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.

    — All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

    — Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).

    — All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.154)

    — Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included.

    No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

    154) The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp, and va_end.

    0 讨论(0)
提交回复
热议问题