Re: Wrong snprintf optimalization

[Marek Polacek]

On Sat, Apr 21, 2018 at 11:47:52AM +0200, Dávid Bolvanský wrote:
> Hello,
> 
> #include 
> int main(void)
> {
> char buf[10];
> return snprintf(buf, 0, "string");
> }
> 
> GCC simplifies it to
> main:
> mov eax, 6
> ret
> 
> but 0 is correct I think.

No, 6 seems to be the correct value:
If the output was truncated due to this limit, then the return value
is the number of characters (excluding the terminating null byte) which would 
have been  written
to  the  final  string if enough space had been available.

Marek

Re: [Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect

[Marek Polacek]

On Tue, May 06, 2014 at 06:33:03PM +, peter_e at gmx dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081
> 
> --- Comment #2 from Peter Eisentraut  ---
> No, these "functions" need to have a usable return value, because someone 
> could
> write
> 
> if (!sigemptyset(...))
> weirderror();

So would the following work for you?
#define sigemptyset(set) (__extension__ ({ *(set) = 0; 0; }))

Re: Segmentation fault since 7fc49a5777943aab11e227136d00a836f28f12b2

[Marek Polacek via Gcc-bugs]

On Tue, Sep 15, 2020 at 10:41:31PM +0100, Nuno Gonçalves via Gcc-bugs wrote:
> Hi Jason et al,
> 
> After a bisect I found that the commit
> 7fc49a5777943aab11e227136d00a836f28f12b2 causes a segmentation fault
> during my compilation:

This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805

> sqlpp11/include/sqlpp11/where.h: In substitution of ‘template WhereRequired> template template
> using _new_statement_t = sqlpp::new_statement_t sqlpp::no_where_t, T> [with Check =
> sqlpp::consistent_t; T = sqlpp::where_t;
> Policies = Policies; bool WhereRequired = WhereRequired]’:
> sqlpp11/include/sqlpp11/where.h:320:99:   required from here
> sqlpp11/include/sqlpp11/where.h:320:99: internal compiler error:
> Segmentation fault
>   320 |   auto unconditionally() const ->
> _new_statement_t>
>   |
>^~
> 0xc9978f crash_signal
> ../../gcc/toplev.c:328
> 0x692b05 pop_nested_class()
> ../../gcc/cp/class.c:8184
> 0x7a3157 instantiate_template_1
> ../../gcc/cp/pt.c:20853
> 0x79e0b4 instantiate_template(tree_node*, tree_node*, int)
> ../../gcc/cp/pt.c:20908
> 0x79e0b4 instantiate_alias_template
> ../../gcc/cp/pt.c:20946
> 0x79e0b4 tsubst(tree_node*, tree_node*, int, tree_node*)
> ../../gcc/cp/pt.c:15147
> 0x7a451f lookup_template_class_1
> ../../gcc/cp/pt.c:9853
> 0x7a4bfc lookup_template_class(tree_node*, tree_node*, tree_node*,
> tree_node*, int, int)
> ../../gcc/cp/pt.c:10119
> 0x7c154d finish_template_type(tree_node*, tree_node*, int)
> ../../gcc/cp/semantics.c:3408
> 0x768b7d cp_parser_template_id
> ../../gcc/cp/parser.c:16739
> 0x768dec cp_parser_class_name
> ../../gcc/cp/parser.c:23713
> 0x765b21 cp_parser_qualifying_entity
> ../../gcc/cp/parser.c:6776
> 0x765b21 cp_parser_nested_name_specifier_opt
> ../../gcc/cp/parser.c:6458
> 0x76d126 cp_parser_simple_type_specifier
> ../../gcc/cp/parser.c:18134
> 0x753e0d cp_parser_type_specifier
> ../../gcc/cp/parser.c:17792
> 0x7673c9 cp_parser_type_specifier_seq
> ../../gcc/cp/parser.c:22402
> 0x761954 cp_parser_type_id_1
> ../../gcc/cp/parser.c:22219
> 0x7606ff cp_parser_trailing_type_id
> ../../gcc/cp/parser.c:22325
> 0x7606ff cp_parser_late_return_type_opt
> ../../gcc/cp/parser.c:22129
> 0x7606ff cp_parser_direct_declarator
> ../../gcc/cp/parser.c:21258
> 
> I hope this is enough since I am not experienced in GCC development.
> 
> Thanks,
> Nuno
> 

Marek

Re: Possible gcc bug

[Marek Polacek via Gcc-bugs]

On Wed, Jul 06, 2022 at 10:15:51AM +1000, Norman wrote:
> Hi all,
> 
> Consider this bit of code:
> 
> unsigned int d=1,e=2,f;
> 
>     if((d-e) < 0)
>     {
>     f=d-e;
>     printf("f=%i",f);
>     }
> 
> gcc  -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c
> 
> gcc compiles this without a whimper.
> 
> However the expression (d-e) < 0 always evaluates to false (0). gcc type
> casts (d-e) as unsigned.

You need to include -Wextra to get the warning.

Marek

Re: Bug in ignoring function call

[Marek Polacek via Gcc-bugs]

On Wed, Nov 20, 2024 at 09:43:46PM +0530, AKASH MISHRA via Gcc-bugs wrote:
> Hi Team,
> there is a bug , compiler not reporting error or warning while calling a
> function with parentheses.
> 
> For ex:
> 
> void func()
> {
> printf("Hi i am in func");
> }
> 
> main()
> {
> // call the func here without parentheses
> 
> func; // here even though we miss parentheses, no error reported , neither
> function got called
> }
> 
> Regards,
> Akash Mishra
> 

Not a bug; you need to use -Wall to get "warning: statement with no effect".

Also please don't email gcc-bugs directly, see .

Marek