[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 --- Comment #7 from Rui Maciel --- Why is this bug marked as RESOLVED INVALID ?
[Bug c/57205] New: unfinished function declaration and inclusion of assert.h causes compiler errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57205 Bug #: 57205 Summary: unfinished function declaration and inclusion of assert.h causes compiler errors Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rui.mac...@gmail.com If gcc is used to compile a source file which includes assert.h and contains an incomplete function declaration, the compiler throws errors blamed on assert.h. Here's an example which is able to reproduce this bug: #include int foo(FILE *file, #include "test.h" #include rui@kubuntu:tmp$ gcc test.c In file included from test.c:3:0: /usr/include/assert.h:71:13: error: storage class specified for parameter ‘__assert_fail’ /usr/include/assert.h:76:13: error: storage class specified for parameter ‘__assert_perror_fail’ /usr/include/assert.h:84:13: error: storage class specified for parameter ‘__assert’ test.c:3:0: error: expected declaration specifiers or ‘...’ at end of input This is a small reproducible example, but in real world code the string of error messages attributed to assert.h is even longer and more egregious.
[Bug c++/55767] New: flowing off end of function which returns a value isn't treated as an error by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55767
Bug #: 55767
Summary: flowing off end of function which returns a value
isn't treated as an error by default
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
#include
int& foo() {}
int main(void)
{
foo() = 1 + 1;
std::cout << foo() << std::endl;
return 0;
}
Function foo() returns a value, which is a reference to an int, and in spite of
no return statement being provided, g++ compiles the above code without
throwing any error. It does throw a warning when compiling with -Wall.
In the C++ standard, in section 6.6.3, it is stated that "A return statement
without an expression can be used only in functions that do not return a
value". It is also stated that "Flowing off the end of a function is
equivalent to a return with no value", following that "this results in
undefined behavior in a value-returning function."
In spite of this behavior being explicitly left in the standard as "undefined
behavior", this loophole contradicts other behavior specifications made by the
standard. Even then, its definition of "permissible undefined behavior" the
standard also includes "terminating a translation or execution (with the
issuance of a diagnostic message)".
As the example above shows, by ignoring the situation completely without even
issuing any diagnostic message, g++ is opening the doors to results which
aren't easily explained or expected, which constitutes a problem.
I've noticed that clang++ throws a warning by default for this particular
example, and I've read reports that MSVC++ 2010 actually throws a compiler
error, which is the best possible result for this kind of problem.
It would be nice if g++ handled functions that flowed off the end as errors
instead of silently accepting them by default.
[Bug c/55613] New: Better warning for reference to struct type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55613
Bug #: 55613
Summary: Better warning for reference to struct type
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
struct Foo
{
int i;
};
int main(void)
{
Foo foo;
return 0;
}
When compiled with gcc 4.6.3, the following error message is displayed:
main.c: In function ‘main’:
main.c:8:2: error: unknown type name ‘Foo’
The problem with this code is that Foo isn't preceded by the keyword "struct".
Yet, as the compiler only returns a vague message about Foo being an unknown
type name, it may mislead the programmer into assuming that the problem might
lie somewhere else, such as a typo somewhere, particularly if the code contains
a significant number of typedef structs.
A significantly better way to handle this error is to warn that the "struct"
keyword is missing. This happens to be the way other compilers, such as clang,
handle this error. The following is clang's error message for this scenario:
main.c:8:2: error: must use 'struct' tag to refer to type 'Foo'
Foo foo;
^
struct
1 error generated.
It would be great if gcc improved its error diagnostics for this error.
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 --- Comment #2 from Rui Maciel 2012-06-15 13:08:01 UTC --- (In reply to comment #1) > (In reply to comment #0) > > If, in the test program, std::u16string is replaced with std::u32string, the > > program is successfully compiled. > > That's surprising - it shouldn't work (and doesn't with G++ 4.7) > > > It would be nice if std::cout also supported std::u16string objects. > > std::cout is for char > > You could use std::wstring_convert to convert a std::u16string to std::string > for output (but GCC doesn't have wsring_convert yet, I plan to work on it next > week.) You are absolutely right. I assumed that the definition of std::ostream also included definitions for operator<< that supported definitions of basic_string with a charT other than char, but it appears my assumptions were completely baseless. In that case, is it possible to tweak gcc to return a friendlier error message? The current one is a bit long and frightening. For example, is it possible define an operator<< that throws a compiler error with any message similar to "basic_ostream doesn't provide an operator<< for basic_string"? This sort of error message would be a whole lot easier to digest.
[Bug c++/53683] New: cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
Bug #: 53683
Summary: cout doesn't support std::u16string
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following test program:
#include
#include
int main(void)
{
std::u16string test;
std::cout << test << std::endl;
return 0;
}
When compiling this code with g++ 4.6.3, with the flags -std=c++0x -Wall
-pedantic, the following error message is displayed:
main.c++: In function ‘int main()’:
main.c++:9:15: error: no match for ‘operator<<’ in ‘std::cout << test’
main.c++:9:15: note: candidates are:
/usr/include/c++/4.6/ostream:110:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char,
_Traits = std::char_traits, std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:110:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to
‘std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&) {aka std::basic_ostream&
(*)(std::basic_ostream&)}’
/usr/include/c++/4.6/ostream:119:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ios_type&
(*)(std::basic_ostream<_CharT, _Traits>::__ios_type&)) [with _CharT = char,
_Traits = std::char_traits, std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream, std::basic_ostream<_CharT,
_Traits>::__ios_type = std::basic_ios]
/usr/include/c++/4.6/ostream:119:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to
‘std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&) {aka std::basic_ios&
(*)(std::basic_ios&)}’
/usr/include/c++/4.6/ostream:129:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT,
_Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char,
_Traits = std::char_traits, std::basic_ostream<_CharT,
_Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:129:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to ‘std::ios_base&
(*)(std::ios_base&)’
/usr/include/c++/4.6/ostream:167:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long
int) [with _CharT = char, _Traits = std::char_traits,
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:167:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to ‘long int’
/usr/include/c++/4.6/ostream:171:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long
unsigned int) [with _CharT = char, _Traits = std::char_traits,
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:171:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to ‘long unsigned int’
/usr/include/c++/4.6/ostream:175:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(bool)
[with _CharT = char, _Traits = std::char_traits,
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:175:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to ‘bool’
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: std::basic_ostream<_CharT,
_Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with
_CharT = char, _Traits = std::char_traits]
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: no known conversion for
argument 1 from ‘std::u16string {aka std::basic_string}’ to ‘short
int’
/usr/include/c++/4.6/ostream:182:7: note: std::basic_ostream<_CharT,
_Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(short
unsigned int) [with _CharT = char, _Traits = std::char_traits,
std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]
/usr/include/c++/4.6/ostream:182:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_string}’ to ‘short unsigned int’
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: std::basic_ostream<_CharT,
_Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT =
char, _Traits = std::char_traits]
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: no known conversion for
argument 1 from ‘std::u16string {aka std::basic_string}’ to ‘int’
/
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
--- Comment #3 from Rui Maciel 2012-05-09
11:47:49 UTC ---
(In reply to comment #2)
> I think it is only undefined behaviour to access the pointer after the
> life-time of y has finished, however, the following probably isn't, no?
>
> void g()
> {
> ...
>*x = 2;
>...
> }
As x hasn't been declared at that point, it should throw a compiler error.
If x was a global pointer which was declared previously then a similar problem
would arise. Take, for example, the following code:
#include
int *x = 0;
void f(void)
{
int a = 2;
x = &a;
}
int main(void)
{
f();
printf("Value: %d\n",*x);
return 0;
}
Again, x is set to the address of a local variable, which is then accessed at a
point where the local variable's lifetime has ended. This behaviour is
explicitly left undefined in ISO 9899:1999 6.2.4 2. Therefore, it would be
nice if the compiler warned about that.
> void f()
> {
>...
>x = &y;
>...
>g();
>...
>x = NULL;
> }
>
> The C/C++ FE cannot distinguish between these two cases.
>
> Do you have a suggestion about how to implement this?
>From the user's point of view, it would be nice if the compiler warned if an
object was being accessed after its lifetime. This should happen at least when
the user explicitly specified the use of a standard which stated that this
behaviour is undefined.
Granted, this might not be an easy thing to implement. As I don't have any
knowledge on gcc's inner workings, I'm not in a position to suggest how this
might be done.
[Bug c/50476] Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476 --- Comment #1 from Rui Maciel 2012-05-08 13:35:33 UTC --- This issue is still present in gcc 4.6.3.
[Bug c++/50359] poor error message for an undeclared identifier in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50359 --- Comment #2 from Rui Maciel 2012-05-08 13:33:57 UTC --- This issue is still present in g++ 4.6.3.
[Bug c++/53281] poor error message for calling a non-const method from a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
--- Comment #1 from Rui Maciel 2012-05-08
13:27:24 UTC ---
The same suggestion applies to the cases where a non-const method is called
from a const method, such as in the example below:
class Foo {
void bar1() {}
void bar2() const {
bar1();
}
};
int main()
{
return 0;
}
The same error message is returned:
main.c++: In member function ‘void Foo::bar2() const’:
main.c++:4:22: error: passing ‘const Foo’ as ‘this’ argument of ‘void
Foo::bar1()’ discards qualifiers [-fpermissive]
[Bug c++/53281] New: poor error message for calling a non-const method from a const object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
Bug #: 53281
Summary: poor error message for calling a non-const method from
a const object
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
class Foo {
void bar1() {}
void bar2(Foo const &foo) {
foo.bar1();
}
};
int main()
{
return 0;
}
When this code is compiled with g++, the following error message is shown:
main.c++: In member function ‘const void Foo::bar2(const Foo&)’:
main.c++:4:26: error: passing ‘const Foo’ as ‘this’ argument of ‘const void
Foo::bar1()’ discards qualifiers [-fpermissive]
The error message is technically correct. Yet, it is too cryptic and a bit
unhelpful, to the point it may be considered that the point of this error
message is entirely missed.
As an alternative, it would be nice if g++ displayed an error message which
would actually be straight-forward and provided a clear description of the
problem at hand, such as "trying to call a non-const method from a const
object".
[Bug c/50476] New: Warn of pointer set to object whose lifetime is limited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
Bug #: 50476
Summary: Warn of pointer set to object whose lifetime is
limited
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
#include
int *x = NULL;
void f(void)
{
int y = 1;
x = &y;
}
int main(void)
{
f();
printf("int: %d\n", *x);
return 0;
}
Function f() assigns a global pointer to a local object, so that the global
pointer refers to the local object's address even when the object's lifetime
ends. This represents undefined behaviour, and therefore can be a potential
source of problems. It would be great if gcc at least threw a warning
informing the user of this problem, similar to how Bug 14156 handles it's use
case.
[Bug c++/50359] New: poor error message for an undeclared identifier in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50359
Bug #: 50359
Summary: poor error message for an undeclared identifier in
constructor
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following code:
struct Foo
{
public:
Foo(int);
};
Foo::Foo(undeclared)
{
}
int main(void)
{
Foo f(1);
return 0;
}
When compiling the above code, the following error message is shown:
main.c++:8:9: error: expected constructor, destructor, or type conversion
before ‘(’ token
Although the error consists of a poorly defined parameter, which may actually
be a simple typo, g++ complains instead about the code which was parsed before
the '(' token, which is actually (at least to the best of my knowledge)
correct.
It would be nice if GCC informed the user about an undeclared identifier
instead of throwing a cryptic message regarding the portion of the code which
is valid.
[Bug c++/16663] Poor parse error recovery with mispelled type in function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16663 Rui Maciel changed: What|Removed |Added CC||rui.maciel at gmail dot com --- Comment #7 from Rui Maciel 2011-09-11 19:29:02 UTC --- (In reply to comment #4) > In GCC 4.4 we have: > > pr16663.C:2: error: variable or field ‘Foo’ declared void > pr16663.C:2: error: ‘misspelled’ was not declared in this scope > pr16663.C:2: error: expected primary-expression before ‘char’ > pr16663.C:2: error: expected primary-expression before ‘bool’ > pr16663.C:2: error: expected primary-expression before ‘float’ > > This is not easy to fix since that statement can be a function declaration but > also a variable declaration and initialization. We try to parse tentatively > the > first case, fail, then we parse the second case and see that 'void' is not > allowed and that 'misspelled' is not declared. If 'void' is not allowed and 'misspelled' is not declared, then wouldn't it be better to recognize that case as an undeclared 'misspelled' instead of an impossible (or, at least, highly improbable) declaration of a variable of type void? As things stand, GCC outputs a cryptic error message that is based on the expectation that a variable being declared with type void is both correct and the expected behaviour, and this isn't helpful.
[Bug c/50330] New: Misleading error message with struct declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50330
Bug #: 50330
Summary: Misleading error message with struct declaration
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
struct t {
int x;
}
int main(void)
{
return 0;
}
This code, compiled with gcc, produces the following error message:
rui@Kubuntu:tmp$ gcc main.c
main.c:5:1: error: two or more data types in declaration specifiers
main.c: In function ‘main’:
main.c:7:10: error: incompatible types when returning type ‘int’ but ‘struct t’
was expected
The same code, when compiled with g++, produces the following error message:
rui@Kubuntu:tmp$ g++ main.c
main.c:1:1: error: new types may not be defined in a return type
main.c:1:1: note: (perhaps a semicolon is missing after the definition of ‘t’)
main.c:5:14: error: two or more data types in declaration of ‘main’
gcc's error message is cryptic and doesn't help the user. g++'s error message,
on the other hand, although it is still cryptic it provides useful clues to the
user, which makes it considerably more helpful. Nonetheless, both error
messages are needlessly cryptic and could be considerable improved, so that the
user gets a much clearer idea on where the error lies.
As a comparison, here is clang's error message:
rui@Kubuntu:tmp$ clang main.c
main.c:3:2: error: expected ';' after struct
}
^
;
1 error generated.
This error message is clear, concise and to the point.
It would be great if GCC improved the error message for this scenario.
