Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #149676 > unrolled thread

Warnings/Debugger

Back to article view | Back to comp.lang.c

Contents

  Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-03 18:38 +0330
    Re: Warnings/Debugger Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-03 17:44 +0000
      Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-04 17:09 +0330
        Re: Warnings/Debugger Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 01:45 +0000
          Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-06 17:03 +0330
            Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-06 05:51 -0800
              Re: Warnings/Debugger Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-06 06:57 -0800
                Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-06 08:15 -0800
                  Re: Warnings/Debugger Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-06 09:01 -0800
            Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-06 21:47 -0500
              Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-07 18:11 +0330
                Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-07 07:35 -0800
                Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-08 00:19 -0500
                  Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-10 15:49 +0330
                    Re: Warnings/Debugger Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-10 16:26 +0000
                      Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-11 17:56 +0330
                        Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-11 06:28 -0800
                        Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-11 22:55 -0500
                        Re: Warnings/Debugger Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-12 07:05 +0000
                      Re: Warnings/Debugger Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 08:36 -0800
                    Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-11 08:24 -0800
                      Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-12 16:11 +0330
                        Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-12 05:39 -0800
            Re: Warnings/Debugger Ian Collins <ian-news@hotmail.com> - 2020-02-07 16:14 +1300
    Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 12:56 -0500
      Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-04 17:24 +0330
        Re: Warnings/Debugger James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 10:03 -0500
    Re: Warnings/Debugger Öö Tiib <ootiib@hot.ee> - 2020-02-03 11:41 -0800
      Re: Warnings/Debugger Mehdi Amini <atorrses@gmail.com> - 2020-02-04 17:29 +0330
        Re: Warnings/Debugger Paul <nospam@needed.invalid> - 2020-02-04 13:18 -0500
          Re: Warnings/Debugger David Brown <david.brown@hesbynett.no> - 2020-02-04 21:29 +0100
          Re: Warnings/Debugger Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-05 10:05 +0000
            Re: Warnings/Debugger chad <cdalten@gmail.com> - 2020-02-05 06:05 -0800
            Re: Warnings/Debugger Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-05 08:39 -0800
              Re: Warnings/Debugger Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 16:49 +0000
    Re: Warnings/Debugger Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2020-02-18 16:41 +0000

Page 1 of 2  [1] 2  Next page →

#149676 — Warnings/Debugger

Hi,

Following the discussion here:

https://discourse.gnome.org/t/transient-warning/2553

1.Is it my fault that I can not get the warnings work correctly ?

2. Is it so that I should be using a debugger , as otherwise others may
not help me ?

-- 
www.my-c-codes.com/

Farewell.

[toc] | [next] | [standalone]

#149687

Mehdi Amini <atorrses@gmail.com> writes:

> Following the discussion here:
>
> https://discourse.gnome.org/t/transient-warning/2553
>
> 1.Is it my fault that I can not get the warnings work correctly ?

It's not clear what you mean.  Do you just get too many warnings using
-Wall from the rest of the code?  If so, can you keep your changes in a
separate source file, at least during development?

> 2. Is it so that I should be using a debugger , as otherwise others may
> not help me ?

The person who suggested gdb also suggested a memory sanitiser and/or
valgrind.  Did you try either of these?

People will naturally suggest you try what works for them, and if you
can't or won't do that they will stop making suggestions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149722

On 2/3/20 9:14 PM, Ben Bacarisse wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
> 
>> Following the discussion here:
>>
>> https://discourse.gnome.org/t/transient-warning/2553
>>
>> 1.Is it my fault that I can not get the warnings work correctly ?
> 
> It's not clear what you mean.  Do you just get too many warnings using
> -Wall from the rest of the code?  If so, can you keep your changes in a
> separate source file, at least during development?
> 

If I compile my code using GTK+ (self made) static library two cases
happen:

* Without warning flags , compiles less than 10sec. Seems static library
  working correctly.

* With warning flags , compilation takes more than 2min , thousands of
  GTK+ warnings shown. I guess GTK+ compiles from source each time.

By the way , may you explain that suggestion more ?

>> 2. Is it so that I should be using a debugger , as otherwise others may
>> not help me ?
> 
> The person who suggested gdb also suggested a memory sanitiser and/or
> valgrind.  Did you try either of these?
> 
> People will naturally suggest you try what works for them, and if you
> can't or won't do that they will stop making suggestions.
> 

In the past I used Cppcheck. Once someone used Valgrind and found a rare 
bug in my code. Here in comp.lang.c . I do not object helpers using such 
tools but for my case , I believe in different concepts.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#149746

Mehdi Amini <atorrses@gmail.com> writes:

> On 2/3/20 9:14 PM, Ben Bacarisse wrote:
>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>>> Following the discussion here:
>>>
>>> https://discourse.gnome.org/t/transient-warning/2553
>>>
>>> 1.Is it my fault that I can not get the warnings work correctly ?
>>
>> It's not clear what you mean.  Do you just get too many warnings using
>> -Wall from the rest of the code?  If so, can you keep your changes in a
>> separate source file, at least during development?
>>
>
> If I compile my code using GTK+ (self made) static library two cases
> happen:

I don't understand "using GTK+".

> * Without warning flags , compiles less than 10sec. Seems static library
>  working correctly.
>
> * With warning flags , compilation takes more than 2min , thousands of
>  GTK+ warnings shown. I guess GTK+ compiles from source each time.

Why are you compiling GTK+ at all, let alone every time?

Anyway, in what way are warnings not working correctly?

> By the way , may you explain that suggestion more ?

I don't think it's relevant anymore.  Something odd is going on because
you are compiling GTK+ "every time".

>>> 2. Is it so that I should be using a debugger , as otherwise others may
>>> not help me ?
>>
>> The person who suggested gdb also suggested a memory sanitiser and/or
>> valgrind.  Did you try either of these?
>>
>> People will naturally suggest you try what works for them, and if you
>> can't or won't do that they will stop making suggestions.
>
> In the past I used Cppcheck. Once someone used Valgrind and found a
> rare bug in my code. Here in comp.lang.c . I do not object helpers
> using such tools but for my case , I believe in different concepts.

How is that working out?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149788

On 2/5/20 5:15 AM, Ben Bacarisse wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
> 
>> On 2/3/20 9:14 PM, Ben Bacarisse wrote:
>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>
>>>> Following the discussion here:
>>>>
>>>> https://discourse.gnome.org/t/transient-warning/2553
>>>>
>>>> 1.Is it my fault that I can not get the warnings work correctly ?
>>>
>>> It's not clear what you mean.  Do you just get too many warnings using
>>> -Wall from the rest of the code?  If so, can you keep your changes in a
>>> separate source file, at least during development?
>>>
>>
>> If I compile my code using GTK+ (self made) static library two cases
>> happen:
> 
> I don't understand "using GTK+".

I include and use GTK+.

#include <gtk/gtk.h>
// C code that uses GTK

> 
>> * Without warning flags , compiles less than 10sec. Seems static library
>>   working correctly.
>>
>> * With warning flags , compilation takes more than 2min , thousands of
>>   GTK+ warnings shown. I guess GTK+ compiles from source each time.
> 
> Why are you compiling GTK+ at all, let alone every time?
> 
> Anyway, in what way are warnings not working correctly?
> 

I suspect every time I include and use GTK , warnings on , GTK headers
are compiled. That is not good for me , as I want to call GTK from a
static library. I have produced that static library and I can use it.
Only when warnings are off that static library seems to co-operate. At-
least time taken warnings on/off is drastically different.


>> By the way , may you explain that suggestion more ?
> 
> I don't think it's relevant anymore.  Something odd is going on because
> you are compiling GTK+ "every time".
> 
>>>> 2. Is it so that I should be using a debugger , as otherwise others may
>>>> not help me ?
>>>
>>> The person who suggested gdb also suggested a memory sanitiser and/or
>>> valgrind.  Did you try either of these?
>>>
>>> People will naturally suggest you try what works for them, and if you
>>> can't or won't do that they will stop making suggestions.
>>
>> In the past I used Cppcheck. Once someone used Valgrind and found a
>> rare bug in my code. Here in comp.lang.c . I do not object helpers
>> using such tools but for my case , I believe in different concepts.
> 
> How is that working out?
> 

If you mean how , without a debugger one might code, as I already said
in another post in this thread , For me there is a classical coding way
and the modern one. Like some old books , classical way is to use
capabilities like printf/assert/... to produce code. Modern style means
using Test Driven Development (TDD). I have already used CUnit for this
one.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#149790

On Thursday, February 6, 2020 at 5:33:42 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> On 2/5/20 5:15 AM, Ben Bacarisse wrote:
> > Mehdi Amini <atorrses@gmail.com> writes:
> > 
> >> On 2/3/20 9:14 PM, Ben Bacarisse wrote:
> >>> Mehdi Amini <atorrses@gmail.com> writes:
> >>>
> >>>> Following the discussion here:
> >>>>
> >>>> https://discourse.gnome.org/t/transient-warning/2553
> >>>>
> >>>> 1.Is it my fault that I can not get the warnings work correctly ?
> >>>
> >>> It's not clear what you mean.  Do you just get too many warnings using
> >>> -Wall from the rest of the code?  If so, can you keep your changes in a
> >>> separate source file, at least during development?
> >>>
> >>
> >> If I compile my code using GTK+ (self made) static library two cases
> >> happen:
> > 
> > I don't understand "using GTK+".
> 
> I include and use GTK+.
> 
> #include <gtk/gtk.h>
> // C code that uses GTK
> 
> > 
> >> * Without warning flags , compiles less than 10sec. Seems static library
> >>   working correctly.
> >>
> >> * With warning flags , compilation takes more than 2min , thousands of
> >>   GTK+ warnings shown. I guess GTK+ compiles from source each time.
> > 
> > Why are you compiling GTK+ at all, let alone every time?
> > 
> > Anyway, in what way are warnings not working correctly?
> > 
> 
> I suspect every time I include and use GTK , warnings on , GTK headers
> are compiled. That is not good for me , as I want to call GTK from a
> static library. I have produced that static library and I can use it.
> Only when warnings are off that static library seems to co-operate. At-
> least time taken warnings on/off is drastically different.
> 
> 
> >> By the way , may you explain that suggestion more ?
> > 
> > I don't think it's relevant anymore.  Something odd is going on because
> > you are compiling GTK+ "every time".
> > 
> >>>> 2. Is it so that I should be using a debugger , as otherwise others may
> >>>> not help me ?
> >>>
> >>> The person who suggested gdb also suggested a memory sanitiser and/or
> >>> valgrind.  Did you try either of these?
> >>>
> >>> People will naturally suggest you try what works for them, and if you
> >>> can't or won't do that they will stop making suggestions.
> >>
> >> In the past I used Cppcheck. Once someone used Valgrind and found a
> >> rare bug in my code. Here in comp.lang.c . I do not object helpers
> >> using such tools but for my case , I believe in different concepts.
> > 
> > How is that working out?
> > 
> 
> If you mean how , without a debugger one might code, as I already said
> in another post in this thread , For me there is a classical coding way
> and the modern one. Like some old books , classical way is to use
> capabilities like printf/assert/... to produce code. Modern style means
> using Test Driven Development (TDD). I have already used CUnit for this
> one.
> 

Again, besides the fact that I don't think that you SHOULDN'T be allowed near a computer, printf() doesn't always work. This is because as far as I understand it, something like printf() is line buffered. But there are cases when the output is either fully buffered or unbuffered. In which cases, depending on the situation, printf() might block in its call.


I think that is how the explanation goes. Or at least it's close. It's been well over a decade since I've done this kind of stuff. These days I mainly do OOP on the cloud because that is the cool and hip thing. Besides that, it pays the bills.

[toc] | [prev] | [next] | [standalone]

#149792

On Thursday, 6 February 2020 13:51:35 UTC, chad  wrote:
> On Thursday, February 6, 2020 at 5:33:42 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> >
> > If you mean how , without a debugger one might code, as I already said
> > in another post in this thread , For me there is a classical coding way
> > and the modern one. Like some old books , classical way is to use
> > capabilities like printf/assert/... to produce code. Modern style means
> > using Test Driven Development (TDD). I have already used CUnit for this
> > one.
> > 
> 
> Again, besides the fact that I don't think that you SHOULDN'T be allowed 
> near a computer, printf() doesn't always work. This is because as far as 
> I understand it, something like printf() is line buffered. But there are 
> cases when the output is either fully buffered or unbuffered. In which 
> cases, depending on the situation, printf() might block in its call.
> 
One strategy is to develop functions in a Linux shell or equivalent,
where you can compile with a simple gcc *.c, and get test and debug
output to the shell. Then when the function is tested and debugged,
move it to formal source. However that doesn't work for functions which
need the environment of the whole program in which to run, only for ones
which can be isolated. Which is a better way of writing functions, but
not always possible.

[toc] | [prev] | [next] | [standalone]

#149796

On Thursday, February 6, 2020 at 6:57:46 AM UTC-8, Malcolm McLean wrote:
> On Thursday, 6 February 2020 13:51:35 UTC, chad  wrote:
> > On Thursday, February 6, 2020 at 5:33:42 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> > >
> > > If you mean how , without a debugger one might code, as I already said
> > > in another post in this thread , For me there is a classical coding way
> > > and the modern one. Like some old books , classical way is to use
> > > capabilities like printf/assert/... to produce code. Modern style means
> > > using Test Driven Development (TDD). I have already used CUnit for this
> > > one.
> > > 
> > 
> > Again, besides the fact that I don't think that you SHOULDN'T be allowed 
> > near a computer, printf() doesn't always work. This is because as far as 
> > I understand it, something like printf() is line buffered. But there are 
> > cases when the output is either fully buffered or unbuffered. In which 
> > cases, depending on the situation, printf() might block in its call.
> > 
> One strategy is to develop functions in a Linux shell or equivalent,
> where you can compile with a simple gcc *.c, and get test and debug
> output to the shell. Then when the function is tested and debugged,
> move it to formal source. However that doesn't work for functions which
> need the environment of the whole program in which to run, only for ones
> which can be isolated. Which is a better way of writing functions, but
> not always possible.

I've seen some people write an isolated function and then put it in private library when the function is needed for the entire program. 

[toc] | [prev] | [next] | [standalone]

#149797

On Thursday, 6 February 2020 16:15:53 UTC, chad  wrote:
> On Thursday, February 6, 2020 at 6:57:46 AM UTC-8, Malcolm McLean wrote:
> > On Thursday, 6 February 2020 13:51:35 UTC, chad  wrote:
> > > On Thursday, February 6, 2020 at 5:33:42 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> > > >
> > > > If you mean how , without a debugger one might code, as I already said
> > > > in another post in this thread , For me there is a classical coding way
> > > > and the modern one. Like some old books , classical way is to use
> > > > capabilities like printf/assert/... to produce code. Modern style means
> > > > using Test Driven Development (TDD). I have already used CUnit for this
> > > > one.
> > > > 
> > > 
> > > Again, besides the fact that I don't think that you SHOULDN'T be allowed 
> > > near a computer, printf() doesn't always work. This is because as far as 
> > > I understand it, something like printf() is line buffered. But there are 
> > > cases when the output is either fully buffered or unbuffered. In which 
> > > cases, depending on the situation, printf() might block in its call.
> > > 
> > One strategy is to develop functions in a Linux shell or equivalent,
> > where you can compile with a simple gcc *.c, and get test and debug
> > output to the shell. Then when the function is tested and debugged,
> > move it to formal source. However that doesn't work for functions which
> > need the environment of the whole program in which to run, only for ones
> > which can be isolated. Which is a better way of writing functions, but
> > not always possible.
> 
> I've seen some people write an isolated function and then put it in 
> private library when the function is needed for the entire program.
>
Trivial functions like mystrdup() I often make local to the file, if
by doing so I can make it independent. Even if that means adding a lot
of copies of the ssme function in the same program.

[toc] | [prev] | [next] | [standalone]

#149812

On 2/6/20 8:33 AM, Mehdi Amini wrote:
...
> I suspect every time I include and use GTK , warnings on , GTK headers
> are compiled.

Sort of - the headers get #included in your source code file(s?), and
those source code files do get compiled. However, all that should be
declared in the GTK headers is the interface to the GTK library. That's
not the library itself, which should not be getting recompiled each time
you compile your own code.

Here's a simple test. Create and compile a file containing the following
code:

  #include "gtk/gtk.h"
  int main(void) { return 0; }

If you get warnings from that compilation, there's a problem that might
be in the gtk headers, but is more likely to be in your choice of
compiler options.
If that code works, and yours doesn't, the warnings are almost certainly
due to problems in your code - and no one is going to be able to help
you track them down without a lot more information than you've deigned
to give us.

[toc] | [prev] | [next] | [standalone]

#149822

On 2/7/20 6:17 AM, James Kuyper wrote:
> On 2/6/20 8:33 AM, Mehdi Amini wrote:

[...]

> Here's a simple test. Create and compile a file containing the following
> code:
> 
>    #include "gtk/gtk.h"
>    int main(void) { return 0; }
> 
> If you get warnings from that compilation, there's a problem that might
> be in the gtk headers, but is more likely to be in your choice of
> compiler options.
> If that code works, and yours doesn't, the warnings are almost certainly
> due to problems in your code - and no one is going to be able to help
> you track them down without a lot more information than you've deigned
> to give us.
> 

I tired this code:

#include "gtk/gtk.h"
int main(void)
{
     return 0;
}

* Warnings on:
-------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9 
GTK Library)---------------
Process terminated with status 0 (0 minute(s), 12 second(s))
1 error(s), 1962 warning(s) (0 minute(s), 12 second(s))

* Warnings off:
-------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10 
GTK Library Warnings_Disabled)---------------
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#149826

On Friday, February 7, 2020 at 6:41:40 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> On 2/7/20 6:17 AM, James Kuyper wrote:
> > On 2/6/20 8:33 AM, Mehdi Amini wrote:
> 
> [...]
> 
> > Here's a simple test. Create and compile a file containing the following
> > code:
> > 
> >    #include "gtk/gtk.h"
> >    int main(void) { return 0; }
> > 
> > If you get warnings from that compilation, there's a problem that might
> > be in the gtk headers, but is more likely to be in your choice of
> > compiler options.
> > If that code works, and yours doesn't, the warnings are almost certainly
> > due to problems in your code - and no one is going to be able to help
> > you track them down without a lot more information than you've deigned
> > to give us.
> > 
> 
> I tired this code:
> 
> #include "gtk/gtk.h"
> int main(void)
> {
>      return 0;
> }
> 
> * Warnings on:
> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9 
> GTK Library)---------------
> Process terminated with status 0 (0 minute(s), 12 second(s))
> 1 error(s), 1962 warning(s) (0 minute(s), 12 second(s))
> 
> * Warnings off:
> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10 
> GTK Library Warnings_Disabled)---------------
> Process terminated with status 0 (0 minute(s), 0 second(s))
> 0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
> 
> -- 
> www.my-c-codes.com/
> 
> Farewell.

I hope to god that you never made it beyond tech support.

[toc] | [prev] | [next] | [standalone]

#149845

On 2/7/20 9:41 AM, Mehdi Amini wrote:
> On 2/7/20 6:17 AM, James Kuyper wrote:
>> On 2/6/20 8:33 AM, Mehdi Amini wrote:
> 
> [...]
> 
>> Here's a simple test. Create and compile a file containing the following
>> code:
>>
>>    #include "gtk/gtk.h"
>>    int main(void) { return 0; }
>>
>> If you get warnings from that compilation, there's a problem that might
>> be in the gtk headers, but is more likely to be in your choice of
>> compiler options.
>> If that code works, and yours doesn't, the warnings are almost certainly
>> due to problems in your code - and no one is going to be able to help
>> you track them down without a lot more information than you've deigned
>> to give us.
>>
> 
> I tired this code:
> 
> #include "gtk/gtk.h"
> int main(void)
> {
>      return 0;
> }
> 
> * Warnings on:
> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9 
> GTK Library)---------------
> Process terminated with status 0 (0 minute(s), 12 second(s))
> 1 error(s), 1962 warning(s) (0 minute(s), 12 second(s))

That implies either that gtk.h is seriously defective, or you're
compiling with the wrong compiler options for working with the GTK
library. So, what compiler options did you select? What version of the
GTK are you trying to use? Most importantly, why are you bring this up
here rather than in a forum devoted to GTK? You're likely to get better
answers in such a forum than you're likely to get here.

Also, what was the 1 error message?
Just to give us an idea of what's going wrong, what was the very first
warning message?

[toc] | [prev] | [next] | [standalone]

#149913

On 2/8/20 8:49 AM, James Kuyper wrote:
> On 2/7/20 9:41 AM, Mehdi Amini wrote:
>> On 2/7/20 6:17 AM, James Kuyper wrote:
>>> On 2/6/20 8:33 AM, Mehdi Amini wrote:
>>
>> [...]
>>
>>> Here's a simple test. Create and compile a file containing the following
>>> code:
>>>
>>>     #include "gtk/gtk.h"
>>>     int main(void) { return 0; }
>>>
>>> If you get warnings from that compilation, there's a problem that might
>>> be in the gtk headers, but is more likely to be in your choice of
>>> compiler options.
>>> If that code works, and yours doesn't, the warnings are almost certainly
>>> due to problems in your code - and no one is going to be able to help
>>> you track them down without a lot more information than you've deigned
>>> to give us.
>>>
>>
>> I tired this code:
>>
>> #include "gtk/gtk.h"
>> int main(void)
>> {
>>       return 0;
>> }
>>
>> * Warnings on:
>> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9
>> GTK Library)---------------
>> Process terminated with status 0 (0 minute(s), 12 second(s))
>> 1 error(s), 1962 warning(s) (0 minute(s), 12 second(s))
> 
> That implies either that gtk.h is seriously defective, or you're
> compiling with the wrong compiler options for working with the GTK
> library. So, what compiler options did you select? What version of the
> GTK are you trying to use? Most importantly, why are you bring this up
> here rather than in a forum devoted to GTK? You're likely to get better
> answers in such a forum than you're likely to get here.
> 
> Also, what was the 1 error message?
> Just to give us an idea of what's going wrong, what was the very first
> warning message?
> 

Compiler:
-------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10 
GTK Library Warnings_Disabled)---------------

clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall 
-std=c11 -m64 -w -std=c11 -pthread -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -c 
/home/mehdi/Documents/Code_Blocks_Projects/Temp/Main.c -o obj/Release/Main.o
clang  -o bin/Release/Temp obj/Release/Main.o  -m64 -lfftw3l -lcunit 
-pthread -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype 
-lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 
-lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject 
-lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
/home/mehdi/Documents/Code_Blocks_Projects/GTK3_SL/bin/Release/libGTK3_SL.a
Output file is bin/Release/Temp with size 18.13 KB
Process terminated with status 0 (0 minute(s), 3 second(s))
0 error(s), 0 warning(s) (0 minute(s), 3 second(s))

With warnings:
-------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9 
GTK Library)---------------

clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall 
-std=c11 -m64 -pedantic -Weverything -Wall -std=c11 -pthread 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -c 
/home/mehdi/Documents/Code_Blocks_Projects/Temp/Main.c -o obj/Release/Main.o
In file included from 
/home/mehdi/Documents/Code_Blocks_Projects/Temp/Main.c:12:
/usr/include/gtk-3.0/gtk/gtk.h:26:9: warning: macro name is a reserved 
identifier [-Wreserved-id-macro]
#define __GTK_H__
         ^
/usr/include/gtk-3.0/gtk/gtk.h:28:9: warning: macro name is a reserved 
identifier [-Wreserved-id-macro]
#define __GTK_H_INSIDE__
         ^

error: Callback to invoke when an error occurs.

It is GTK version 3.

I posted a question on GTK forum , it has no answer in two days.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#149924

On Mon, 2020-02-10, Mehdi Amini wrote:
> On 2/8/20 8:49 AM, James Kuyper wrote:
...
>> Also, what was the 1 error message?
>> Just to give us an idea of what's going wrong, what was the very first
>> warning message?
>> 
>
> Compiler:
> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10 
> GTK Library Warnings_Disabled)---------------
>
> clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall 
> -std=c11 -m64 -w -std=c11 -pthread -I/usr/include/gtk-3.0 
...
> #define __GTK_H__
>          ^
> /usr/include/gtk-3.0/gtk/gtk.h:28:9: warning: macro name is a reserved 
> identifier [-Wreserved-id-macro]

You probably shouldn't use -Weverything.  I never heard of it before,
but it seems to enable every warning anyone ever implemented, and
that's going to generate a lot of noise, like the warning quoted
above.

  -pedantic -Wall -Wextra -std=c11

is plenty, and quality libraries are written so their header files
don't generate any of those warnings.

> error: Callback to invoke when an error occurs.

I don't understand that one; does it really come from the compiler
at all?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#149943

On 2/10/20 7:56 PM, Jorgen Grahn wrote:
> On Mon, 2020-02-10, Mehdi Amini wrote:
>> On 2/8/20 8:49 AM, James Kuyper wrote:
> ...
>>> Also, what was the 1 error message?
>>> Just to give us an idea of what's going wrong, what was the very first
>>> warning message?
>>>
>>
>> Compiler:
>> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10
>> GTK Library Warnings_Disabled)---------------
>>
>> clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall
>> -std=c11 -m64 -w -std=c11 -pthread -I/usr/include/gtk-3.0
> ...
>> #define __GTK_H__
>>           ^
>> /usr/include/gtk-3.0/gtk/gtk.h:28:9: warning: macro name is a reserved
>> identifier [-Wreserved-id-macro]
> 
> You probably shouldn't use -Weverything.  I never heard of it before,
> but it seems to enable every warning anyone ever implemented, and
> that's going to generate a lot of noise, like the warning quoted
> above.
> 
>    -pedantic -Wall -Wextra -std=c11
> 
> is plenty, and quality libraries are written so their header files
> don't generate any of those warnings.
> 

Thanks , disabling -Weverything actually did the job.

>> error: Callback to invoke when an error occurs.
> 
> I don't understand that one; does it really come from the compiler
> at all?
> 
> /Jorgen
> 

How can I differentiate it ?

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#149944

On Tuesday, February 11, 2020 at 6:26:44 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> On 2/10/20 7:56 PM, Jorgen Grahn wrote:
> > On Mon, 2020-02-10, Mehdi Amini wrote:
> >> On 2/8/20 8:49 AM, James Kuyper wrote:
> > ...
> >>> Also, what was the 1 error message?
> >>> Just to give us an idea of what's going wrong, what was the very first
> >>> warning message?
> >>>
> >>
> >> Compiler:
> >> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10
> >> GTK Library Warnings_Disabled)---------------
> >>
> >> clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall
> >> -std=c11 -m64 -w -std=c11 -pthread -I/usr/include/gtk-3.0
> > ...
> >> #define __GTK_H__
> >>           ^
> >> /usr/include/gtk-3.0/gtk/gtk.h:28:9: warning: macro name is a reserved
> >> identifier [-Wreserved-id-macro]
> > 
> > You probably shouldn't use -Weverything.  I never heard of it before,
> > but it seems to enable every warning anyone ever implemented, and
> > that's going to generate a lot of noise, like the warning quoted
> > above.
> > 
> >    -pedantic -Wall -Wextra -std=c11
> > 
> > is plenty, and quality libraries are written so their header files
> > don't generate any of those warnings.
> > 
> 
> Thanks , disabling -Weverything actually did the job.
> 
> >> error: Callback to invoke when an error occurs.
> > 
> > I don't understand that one; does it really come from the compiler
> > at all?
> > 
> > /Jorgen
> > 
> 
> How can I differentiate it ?
> 

Again, for the 4th time, you shouldn't be allowed near a computer. Please go find something else to do. Like maybe watching porn or doing construction work.

[toc] | [prev] | [next] | [standalone]

#149962

On 2/11/20 9:26 AM, Mehdi Amini wrote:
> On 2/10/20 7:56 PM, Jorgen Grahn wrote:
>> On Mon, 2020-02-10, Mehdi Amini wrote:
...
>>> error: Callback to invoke when an error occurs.
>>
>> I don't understand that one; does it really come from the compiler
>> at all?
>>
>> /Jorgen
>>
> 
> How can I differentiate it ?

The issue is the distinction between compile time error messages and
runtime error messages. You shouldn't have trouble differentiating
between the two.

[toc] | [prev] | [next] | [standalone]

#149963

On Tue, 2020-02-11, Mehdi Amini wrote:
> On 2/10/20 7:56 PM, Jorgen Grahn wrote:
>> On Mon, 2020-02-10, Mehdi Amini wrote:
>>> On 2/8/20 8:49 AM, James Kuyper wrote:
>> ...
>>>> Also, what was the 1 error message?
>>>> Just to give us an idea of what's going wrong, what was the very first
>>>> warning message?
>>>>
>>>
>>> Compiler:
>>> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 10
>>> GTK Library Warnings_Disabled)---------------
...

>>> error: Callback to invoke when an error occurs.
>> 
>> I don't understand that one; does it really come from the compiler
>> at all?
>
> How can I differentiate it ?

JK already replied, but another angle: it depends on what tools you
use. I use Make to build my programs, and it's pretty good[0] at
showing what output comes from the compiler, what comes from other
tools, and what comes from Make itself.

If you use an IDE to build, and maybe even hit some "build and run the
program" button, then it's the IDE's job to make it clear which tool
prints what.  You may have to read carefully at first to familiarize
yourself with the output.

/Jorgen

[0] Unless you let it build in parallel; then the output is
    all mixed up.

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150072

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Mon, 2020-02-10, Mehdi Amini wrote:
>
>> On 2/8/20 8:49 AM, James Kuyper wrote:
>
> ...
>
>>> Also, what was the 1 error message?
>>> Just to give us an idea of what's going wrong, what was the very first
>>> warning message?
>>
>> Compiler:
>> -------------- Build:  Release in Temp (compiler:  LLVM Clang Compiler 10
>> GTK Library Warnings_Disabled)---------------
>>
>> clang -pedantic -Weverything -Wall -std=c11 -pedantic -Weverything -Wall
>> -std=c11 -m64 -w -std=c11 -pthread -I/usr/include/gtk-3.0
>
> ...
>
>> #define __GTK_H__
>>          ^
>> /usr/include/gtk-3.0/gtk/gtk.h:28:9: warning: macro name is a reserved
>> identifier [-Wreserved-id-macro]
>
> You probably shouldn't use -Weverything.  I never heard of it before,
> but it seems to enable every warning anyone ever implemented, and
> that's going to generate a lot of noise, like the warning quoted
> above.

Yes.  I suppose there could be a situation where -Weverything is
called for, but this isn't one of them.

> [as to what options should be used,]
>
>   -pedantic -Wall -Wextra -std=c11
>
> is plenty,

I recommend a more incremental approach.  To start, compile with
just -pedantic-errors (and also either -std=c11 or -std=c99, as
may be preferred, but in any case an explicit choice).  Most
packages will clear this hurdle without any difficulty, but for
those that don't it's good to get an early indication of that, to
decide how to proceed further.

After clearing the -pedantic hurdle, turn on individual warnings
one or two at a time, in order of most serious type first.  One
way of doing this is to add temporarily -Wall and -Wextra, then
look through the different kinds of warnings given, pick the most
significant, and go back and add it to the list of specific
warnings options (or perhaps not, if it is deemed not important
enough).  Repeat until the set of warning options converges.

I have been following this method for fifteen or twenty years
now, and find it gives better results than turning on all the
warning options from the beginning.

> and quality libraries are written so their header files
> don't generate any of those warnings.

That is true in many cases, but there are plenty of well-regarded
libraries where using the -Wall/-Wextra options will generate
some warnings.  Also it is good to remember that -Wall/-Wextra is
a moving target:  software that clears the -Wall/-Wextra hurdle
today may very well stumble tomorrow.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web