This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: organization of C Extensions in manual


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.

(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.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]