Re: [Bug-gnupress] Review of GCC Manual, segment 011

[James A. Morrison]

On Thu, 2003-04-24 at 23:20, D F wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've attached a file containing the results of my review of section 
> 011. I'm now working on section 018. I hope to have it completed in 
> a couple of days.
> 
> - -- 
> Dave Fluri

 This patch reminds me, I should have mentioned this page:
http://gcc.gnu.org/codingconventions.html

 So all your corrections from PowerPC to PowerPc are incorrect,
but the rest looks pretty good.

Thanks,
Jim


> Page 192--line 25
>       calls to malloc result in a pointers that cannot alias anything. This
>       should be
>       calls to malloc result in pointers that cannot alias anything. This
> 
> Page 193--line 10
>       ule. Note that hidden symbols, while then cannot be
>       should be
>       ule. Note that hidden symbols, while they cannot be
> 
> Page 193--line 31
>       The PowerPC compiler for Windows NT currently ignores the stdcall
>       should be
>       The PowerPc compiler for Windows NT currently ignores the stdcall
>       as per the GCC coding conventions guide
> 
> Page 193--line 36
>       The PowerPC compiler for Windows NT currently ignores the cdecl
>       should be
>       The PowerPc compiler for Windows NT currently ignores the cdecl
>       as per the GCC coding conventions guide
> 
> Page 193--line 39
>       On the RS/6000 and PowerPC, the longcall attribute causes the com-
>       should be
>       On the RS/6000 and PowerPc, the longcall attribute causes the com-
>       as per the GCC coding conventions guide
> 
> Page 193--line 44
>       See Section 3.17.10 [RS/6000 and PowerPC Options], page 106, for
>       should be
>       See Section 3.17.10 [RS/6000 and PowerPc Options], page 106, for
>       as per the GCC coding conventions guide
> 
> Page 193--line 45
>       more information on when long calls are and are not necessary
>       should be
>       more information on when long calls are or are not necessary
> 
> Page 193--line 47
>       This attribute allows to specify how to call a particular function on
>       should be
>       This attribute allows one to specify how to call a particular function 
> on
>       or
>       This attribute specifies how a particular function is called on
> 
> Page 194--line 7
>       On the PowerPC running Windows NT, the dllimport attribute causes
>       should be
>       On the PowerPc running Windows NT, the dllimport attribute causes
>       as per the GCC coding conventions guide
> 
> Page 194--lines 8 and 9
>       the compiler to call the function via a global pointer to the function
>       pointer that is set up by the Windows NT dll library. The pointer
>       should be
>       the compiler to reference the function via a global pointer. This global
>       pointer refers directly to the pointer to the function that is set up by
>       the Windows dll. The pointer
> 
> Page 194--line 11
>       On the PowerPC running Windows NT, the dllexport attribute causes
>       should be
>       On the PowerPc running Windows NT, the dllexport attribute causes
>       as per the GCC coding conventions guide
> 
> Page 194--line 16
>       On the PowerPC running Windows NT, the exception attribute causes
>       should be
>       On the PowerPc running Windows NT, the exception attribute causes
>       as per the GCC coding conventions guide
> 
> Page 194--line 38
>       Note, on the AVR interrupts will be enabled inside the function
>       should be
>       Note, on the AVR, interrupts will be enabled inside the function
> 
> Page 194--line 39
>       Note, for the ARM you can specify the kind of interrupt to be handled
>       should be
>       Note, for the ARM, you can specify the kind of interrupt to be handled
> 
> Page 195--line 24
>       an signal handler. The compiler will generate function entry and exit
>       should be
>       a signal handler. The compiler will generate function entry and exit
> 
> Page 195--line 25
>       sequences suitable for use in an signal handler when this attribute is
>       should be
>       sequences suitable for use in a signal handler when this attribute is
> 
> Page 195--line 26
>       present. Interrupts will be disabled inside function.
>       should be
>       present. Interrupts will be disabled inside the function.
> 
> Page 195--line 28
>       the specified function do not need prologue/epilogue sequences gen-
>       should be
>       the specified function does not need prologue/epilogue sequences gen-
> 
> Page 195--line 32
>       Use this attributeon the M32R/D to set the addressability of an object,
>       should be
>       Use this attribute on the M32R/D to set the addressability of an object,
> 
> Page 195--line 33
>       and the code generated for a function. The identifier model-name is
>       should be
>       and of the code generated for a function. The identifier model-name is
> 
> Page 197--paragraph 4
>       I have absolutely no idea what any of this paragraph is supposed to 
> mean.
>       Certainly, the first sentence is excessively long and needs to be 
> broken up.
>       I suggest someone who is more technically astute than am I look at this
>       paragraph.
> 
> Page 200--line 25
>       data type even at an odd addresses. For these machines, __alignof__ 
> reports the
>       should be
>       data type even at an odd address. For these machines, __alignof__ 
> reports the
> 
> Page 204--line 5
>       the warnings only occurs for uses:
>       should be
>       the wqarning only occurs for uses:
> 
> Page 206--line 29
>       specified that the minimum required memory be used to represent
>       should be
>       specifies that the minimum required memory be used to represent
> 
> Page 207--line 2
>       ventions of first member of the transparent union, not the calling
>       should be
>       ventions of the first member of the transparent union, not the calling
> 
> Page 209--lines 46 and 47
>       For future compatability with when GCC implements ISO C99 semantics for
>       inline functions, it is best to use static inline only. (The existing 
> semantics will
>       should be
>       Since GCC is moving toward the increasing implementation of ISO C99
>       semantics in the future for inline functions, it is best to use static
>       inline only to guarantee compatability. (The existing semantics will
> 
> Page 210--line 39
>       must ensure that no two operands within the same assembler construct 
> use the
>       should be
>       you must ensure that no two operands within the same assembler 
> construct use the
> 
> ----
> 

> _______________________________________________
> Bug-gnupress mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnupress
> 
> 
> --
>  PRIVACY WARNING: For auditing purposes, a copy of this message has been
>  saved in a permanent database by the Net Integrator at weavernet.null.
> 
> --
>  PRIVACY WARNING: For auditing purposes, a copy of this message has been
>  saved in a permanent database by the Net Integrator at weavernet.null.