gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK.
* gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK. * README.TRAD, TESTS.FLUNK: Remove. From-SVN: r36846
This commit is contained in:
Joseph Myers
Joseph Myers
parent
9fa8f75dc9
commit
bc87c1c88d
|
|
@ -1,3 +1,8 @@
|
|||
2000-10-12 Joseph S. Myers <jsm28@cam.ac.uk>
|
||||
|
||||
* gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK.
|
||||
* README.TRAD, TESTS.FLUNK: Remove.
|
||||
|
||||
2000-10-12 Joseph S. Myers <jsm28@cam.ac.uk>
|
||||
|
||||
* c-common.c (decl_attributes): Don't allow strftime formats with
|
||||
|
|
|
|||
|
|
@ -1,55 +0,0 @@
|
|||
This is a partial list of how `gcc -traditional' disagrees with
|
||||
traditional C compilers (perhaps only some of them). Most of these
|
||||
differences are not bugs.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
K&R-1 (2.4.3) says:
|
||||
|
||||
"If the character following a backslash is not one of those
|
||||
specified {in the table above}, the backslash is ignored."
|
||||
|
||||
Up until recently, `gcc -traditional' complained about \x \a and \v
|
||||
appearing in a character or string literal. I believe however that
|
||||
this non-feature has been eliminated (recently).
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
When in -traditional mode, gcc allows the following erroneous pair of
|
||||
declarations to appear together in a given scope:
|
||||
|
||||
typedef int foo;
|
||||
typedef foo foo;
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
K&R-1 (8.5) says:
|
||||
|
||||
"No field may be wider than a word."
|
||||
|
||||
Gcc however allows:
|
||||
|
||||
struct S { int i:33; };
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
In K&R-1 there is no restriction against comments crossing include file
|
||||
boundaries. Gcc however doesn't allow this, even when in -traditional mode.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
Regarding the length of identifiers, K&R-1 (2.2) says:
|
||||
|
||||
"No more than the first eight characters are significant,
|
||||
although more may be used."
|
||||
|
||||
Gcc treats all characters of identifiers as significant, even when in
|
||||
-traditional mode.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
K&R-1 (2.2) says:
|
||||
|
||||
"An identifier is a sequence of letters and digits; the first
|
||||
character must be a letter. The underscore _ counts as a letter."
|
||||
|
||||
Gcc also allows dollar signs in identifiers. (This may also be an issue
|
||||
for the -pedantic option.)
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
This is a collection of things that test suites have
|
||||
said were "wrong" with GCC--but that I don't agree with.
|
||||
|
||||
First, test suites sometimes test for compatibility with
|
||||
traditional C. GCC with -traditional is not completely
|
||||
compatible with traditional C, and in some ways I think it
|
||||
should not be.
|
||||
|
||||
* K&R C allowed \x to appear in a string literal (or character
|
||||
literal?) even in cases where it is *not* followed by a sequence of
|
||||
hex digits. I'm not convinced this is desirable.
|
||||
|
||||
* K&R compilers allow comments to cross over an inclusion boundary (i.e.
|
||||
started in an include file and ended in the including file).
|
||||
I think this would be quite ugly and can't imagine it could
|
||||
be needed.
|
||||
|
||||
Sometimes tests disagree with GCC's interpretation of the ANSI standard.
|
||||
|
||||
* One test claims that this function should return 1.
|
||||
|
||||
enum {A, B} foo;
|
||||
|
||||
func (enum {B, A} arg)
|
||||
{
|
||||
return B;
|
||||
}
|
||||
|
||||
I think it should return 0, because the definition of B that
|
||||
applies is the one in func.
|
||||
|
||||
* Some tests report failure when the compiler does not produce
|
||||
an error message for a certain program.
|
||||
|
||||
ANSI C requires a "diagnostic" message for certain kinds of invalid
|
||||
programs, but a warning counts as a diagnostic. If GCC produces
|
||||
a warning but not an error, that is correct ANSI support.
|
||||
When test suites call this "failure", the tests are broken.
|
||||
|
||||
42
gcc/gcc.texi
42
gcc/gcc.texi
|
|
@ -1312,6 +1312,11 @@ ANSI C does not permit such a construct. It would make sense to support
|
|||
it when @samp{-traditional} is used, but it is too much work to
|
||||
implement.
|
||||
|
||||
@item
|
||||
K&R compilers allow comments to cross over an inclusion boundary (i.e.
|
||||
started in an include file and ended in the including file). I think
|
||||
this would be quite ugly and can't imagine it could be needed.
|
||||
|
||||
@cindex external declaration scope
|
||||
@cindex scope of external declarations
|
||||
@cindex declaration scope
|
||||
|
|
@ -1345,6 +1350,23 @@ flag cannot alter it.
|
|||
PCC allows typedef names to be used as function parameters. The
|
||||
difficulty described immediately above applies here too.
|
||||
|
||||
@item
|
||||
When in @samp{-traditional} mode, GCC allows the following erroneous
|
||||
pair of declarations to appear together in a given scope:
|
||||
|
||||
@example
|
||||
typedef int foo;
|
||||
typedef foo foo;
|
||||
@end example
|
||||
|
||||
@item
|
||||
GCC treats all characters of identifiers as significant, even when in
|
||||
@samp{-traditional} mode. According to K&R-1 (2.2), ``No more than the
|
||||
first eight characters are significant, although more may be used.''.
|
||||
Also according to K&R-1 (2.2), ``An identifier is a sequence of letters
|
||||
and digits; the first character must be a letter. The underscore _
|
||||
counts as a letter.'', but GCC also allows dollar signs in identifiers.
|
||||
|
||||
@cindex whitespace
|
||||
@item
|
||||
PCC allows whitespace in the middle of compound assignment operators
|
||||
|
|
@ -1379,8 +1401,10 @@ return. But in systems with ANSI C headers, @code{time} is declared to
|
|||
return @code{time_t}, and if that is not the same as @code{long}, then
|
||||
@samp{long time ();} is erroneous.
|
||||
|
||||
The solution is to change your program to use @code{time_t} as the return
|
||||
type of @code{time}.
|
||||
The solution is to change your program to use appropriate system headers
|
||||
(@code{<time.h>} on systems with ISO C headers) and not to declare
|
||||
@code{time} if the system header files declare it, or failing that to
|
||||
use @code{time_t} as the return type of @code{time}.
|
||||
|
||||
@cindex @code{float} as function value type
|
||||
@item
|
||||
|
|
@ -2079,6 +2103,20 @@ Strictly speaking, there is no prohibition in the ANSI C standard
|
|||
against allowing structures with volatile fields in registers, but
|
||||
it does not seem to make any sense and is probably not what you wanted
|
||||
to do. So the compiler will give an error message in this case.
|
||||
|
||||
@item
|
||||
Making certain warnings into errors by default.
|
||||
|
||||
Some ISO C testsuites report failure when the compiler does not produce
|
||||
an error message for a certain program.
|
||||
|
||||
ISO C requires a ``diagnostic'' message for certain kinds of invalid
|
||||
programs, but a warning is defined by GCC to count as a diagnostic. If
|
||||
GCC produces a warning but not an error, that is correct ISO C support.
|
||||
If test suites call this ``failure'', they should be run with the GCC
|
||||
option @samp{-pedantic-errors}, which will turn these warnings into
|
||||
errors.
|
||||
|
||||
@end itemize
|
||||
|
||||
@node Warnings and Errors
|
||||
|
|
|
|||
Loading…
Reference in New Issue