organization of C Extensions in manual

David Wohlferd dw@LimeGreenSocks.com
Mon Jan 26 00:20:00 GMT 2015


On 1/22/2015 1:23 PM, Joseph Myers wrote:
> On Thu, 22 Jan 2015, Jeff Law wrote:
>
>>>>       Inline: Defining inline functions (as fast as macros).
>>> Doesn't seem to belong here.
>> Given that inline isn't really an extension anymore, one could argue this
>> isn't relevant anymore.
> Well, we need to document -std=gnu89 / __gnu_inline__ attribute semantics.
> And the fact that a C99 feature is accepted as an extension in C89 mode is
> something that needs documenting.  Though for C extensions maybe the
> documentation would better describe exceptions - extensions from newer C
> standards that are *not* enabled in older standard modes, or that are only
> enabled when you use alternative keywords such as __inline.  Then you
> wouldn't need to go into the details e.g. of long long, just that it's an
> extension accepted in C89 / C++98 mode.

I can't speak to whether removing this topic is a good idea or not. For 
the moment, I have moved volatile, inline and thread-local from the 
Attributes section to their own section (Specifiers).  If it is time to 
remove inline from this page (or just re-work it), someone else will 
need to pursue this.

>
> (For C++ there may be more features than for C that require -std=c++11 to
> enable them, so listing exceptions may not be the right approach for C++.)
>
> Ways in which GNU C features go beyond the corresponding standard feature
> do also need documenting.  (So VLA documentation needs to refer to VLAs in
> structures, and to the interaction with alloca, and to parameter forward
> declarations, even if the basic feature is described in terms of a C99
> feature also supported in C89 mode and for C++ and there's less need to
> describe the C99 semantics.)
>



More information about the Gcc mailing list