[Bug-gnupress] [DOCPATCH] Section 17 (was using-gcc/gcc.020.pdf comments)

[Simon Law]

On Fri, May 09, 2003 at 08:00:50PM -0500, J. Otto Tennant wrote:
>    We read (and this is just me)
> 
>      GCC normally defines __STDC__ to be 1, and in addition defines
>      __STRICT_ANSI_
>      _ if you specify the `-ansi' option, or a `-std' option for strict
>      conformance to
>      some version of ISO C. On some hosts, system include les use a different
> 
>    The problem here is that there should not be a line break within the
>    variable
>    __STRICT_ANSI__.  Let us hope that this indicates a trivial formatting
>    problem within the text, rather than a generic mark-up problem.
> 
>    Oops.  I notice on the next page (Page 319) that it must be a generic
>    mark-up problem.
> 
>    I cannot guess how hard this is to fix; and, of course, it may be only me
>    who objects to line breaks within names.  But, even if it makes it into
>    the Chicago Manual of Style, a stand-alone "_" at the beginning of a line
>    is going to look strange to me until the end of time.

        Fixed these specific instances.  I'm not sure how we'll go about
fixing the entire thing.

>    Is it "synch" or "sync"?  I have always used "sync" in my personal
>    writing, but, for all I know, for my corporate works, some editor
>    corrected me.

        "sync" and fixed.

>    There is really no chance that casual readers will be able to guess what
>    "insn" means.  And I am a casual reader.  I would have to guess that
>    somewhere it is defined as "instantiation", which would make sense in this
>    context.  My personal opinion is that, excepting well known abbreviations
>    (such as "ctor", "dtor", "i18n", "snafu", "fubar", and "tuifu"), most
>    abbreviations should be spelt out.

        The term "insn" is defined in the section "Insns".

The RTL representation of the code for a function is a doubly-linked
chain of objects called @dfn{insns}.  Insns are expressions with
special codes that are used for no other purpose.  Some insns are
actual instructions; others represent dispatch tables for @code{switch}
statements; others represent labels to jump to or various sorts of
declarative information.

        I am leaving it as is.

2003-05-09  J. Otto Tennant  <address@hidden>

        * doc/bugreport.texi: Fixes to spelling, grammar, and diction.
        * doc/trouble.texi: Fix linebreaking across variables.

--- bugreport.texi.orig 2003-05-13 13:01:12.000000000 -0400
+++ bugreport.texi      2003-05-13 13:01:30.000000000 -0400
@@ -233,7 +233,7 @@
 
 Even if the problem you experience is a fatal signal, you should still
 say so explicitly.  Suppose something strange is going on, such as, your
-copy of the compiler is out of synch, or you have encountered a bug in
+copy of the compiler is out of sync, or you have encountered a bug in
 the C library on your system.  (This has happened!)  Your copy might
 crash and the copy here would not.  If you @i{said} to expect a crash,
 then when the compiler here fails to crash, we would know that the bug
--- trouble.texi.orig   2003-05-13 12:52:40.000000000 -0400
+++ trouble.texi        2003-05-13 12:59:48.000000000 -0400
@@ -1226,7 +1226,7 @@
 for pragmatic reasons, not as a requirement.
 
 GCC normally defines @code{__STDC__} to be 1, and in addition
-defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
+defines @address@hidden if you specify the @option{-ansi} option,
 or a @option{-std} option for strict conformance to some version of ISO 
address@hidden
 On some hosts, system include files use a different convention, where
 @code{__STDC__} is normally 0, but is 1 if the user specifies strict
@@ -1238,7 +1238,7 @@
 Undefining @code{__STDC__} in C++.
 
 Programs written to compile with C++-to-C translators get the
-value of @code{__STDC__} that goes with the C compiler that is
+value of @address@hidden that goes with the C compiler that is
 subsequently used.  These programs must test @code{__STDC__}
 to determine what kind of C preprocessor that compiler uses:
 whether they should concatenate tokens in the ISO C fashion