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 2 of 2 — ← Prev page 1 [2]

#149947

On 2020-02-10, Mehdi Ahmini wrote:
> On 2/8/20 8:49 AM, James Kuyper wrote:
>> On 2/7/20 9:41 AM, Mehdi Amini wrote: >>> * 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)) 
...
>> 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? 
...
> 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 

Why in the world are you specifying every option 3 times?
As other people have already pointed out, -Weverything is not recommended
- it turns on every warning that clang is capable of producing,  including
many warnings about things that aren't actually problems.
...
> /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__ 
>         ^ 

That, however, is not an example. Identifiers starting with 2 underscores are reserved to
the implementation. GTK should not be using such identifiers, unless it's claiming to be
an (extended) part of the implementation. However, if that is what it's claiming, then
these messages mean that clang (which IS part of the implementation) isn't buying it.
In any event, while this is a defect in the GTK library,  it's not likely to actually cause
any problems. 
...
> error: Callback to invoke when an error occurs. 

The 1 error I asked you about was the one mentioned in the compilation summary line
you gave us, which is quoted above. That message doesn't sound like a compiler error.
In particular, it seems to be lacking the source file name and line number that clang
normally prefixes error messages with. Did you remove that prefix? If so, could you
restore it? If not, are you sure that isn't actually a runtime error message? If it is, could
you please locate the compiler error message I asked you about?

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

#149968

On 2/11/20 7:54 PM, James Kuyper wrote:
> On 2020-02-10, Mehdi Ahmini wrote:
>> On 2/8/20 8:49 AM, James Kuyper wrote:
>>> On 2/7/20 9:41 AM, Mehdi Amini wrote: >>> * 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))
> ...
>>> 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?
> ...
>> 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
> 
> Why in the world are you specifying every option 3 times?
> As other people have already pointed out, -Weverything is not recommended
> - it turns on every warning that clang is capable of producing,  including
> many warnings about things that aren't actually problems.

I removed two sets, in Code::Blocks BuildOptions>temp and 
BuildOptions>Release is this better :


-------------- Clean: Release in Temp (compiler: LLVM Clang Compiler 9 
GTK Library)---------------

Cleaned "Temp - Release"

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

clang -m64 -pedantic -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 
-Wextra  -c /home/mehdi/Documents/Code_Blocks_Projects/Temp/Main.c -o 
obj/Release/Main.o

> ...
>> /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__
>>          ^
> 
> That, however, is not an example. Identifiers starting with 2 underscores are reserved to
> the implementation. GTK should not be using such identifiers, unless it's claiming to be
> an (extended) part of the implementation. However, if that is what it's claiming, then
> these messages mean that clang (which IS part of the implementation) isn't buying it.
> In any event, while this is a defect in the GTK library,  it's not likely to actually cause
> any problems.
> ...
>> error: Callback to invoke when an error occurs.
> 
> The 1 error I asked you about was the one mentioned in the compilation summary line
> you gave us, which is quoted above. That message doesn't sound like a compiler error.
> In particular, it seems to be lacking the source file name and line number that clang
> normally prefixes error messages with. Did you remove that prefix? If so, could you
> restore it? If not, are you sure that isn't actually a runtime error message? If it is, could
> you please locate the compiler error message I asked you about?
> 

Now after reducing warnings , I get no error at all.

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

Farewell.

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

#149974

On Wednesday, February 12, 2020 at 4:41:56 AM UTC-8, Mehdi Amini Valashani son of Bahram wrote:
> On 2/11/20 7:54 PM, James Kuyper wrote:
> > On 2020-02-10, Mehdi Ahmini wrote:
> >> On 2/8/20 8:49 AM, James Kuyper wrote:
> >>> On 2/7/20 9:41 AM, Mehdi Amini wrote: >>> * 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))
> > ...
> >>> 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?
> > ...
> >> 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
> > 
> > Why in the world are you specifying every option 3 times?
> > As other people have already pointed out, -Weverything is not recommended
> > - it turns on every warning that clang is capable of producing,  including
> > many warnings about things that aren't actually problems.
> 
> I removed two sets, in Code::Blocks BuildOptions>temp and 
> BuildOptions>Release is this better :
> 
> 
> -------------- Clean: Release in Temp (compiler: LLVM Clang Compiler 9 
> GTK Library)---------------
> 
> Cleaned "Temp - Release"
> 
> -------------- Build: Release in Temp (compiler: LLVM Clang Compiler 9 
> GTK Library)---------------
> 
> clang -m64 -pedantic -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 
> -Wextra  -c /home/mehdi/Documents/Code_Blocks_Projects/Temp/Main.c -o 
> obj/Release/Main.o
> 
> > ...
> >> /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__
> >>          ^
> > 
> > That, however, is not an example. Identifiers starting with 2 underscores are reserved to
> > the implementation. GTK should not be using such identifiers, unless it's claiming to be
> > an (extended) part of the implementation. However, if that is what it's claiming, then
> > these messages mean that clang (which IS part of the implementation) isn't buying it.
> > In any event, while this is a defect in the GTK library,  it's not likely to actually cause
> > any problems.
> > ...
> >> error: Callback to invoke when an error occurs.
> > 
> > The 1 error I asked you about was the one mentioned in the compilation summary line
> > you gave us, which is quoted above. That message doesn't sound like a compiler error.
> > In particular, it seems to be lacking the source file name and line number that clang
> > normally prefixes error messages with. Did you remove that prefix? If so, could you
> > restore it? If not, are you sure that isn't actually a runtime error message? If it is, could
> > you please locate the compiler error message I asked you about?
> > 
> 
> Now after reducing warnings , I get no error at all.
> 
> -- 

And during this entire shitshow, I managed to use an OCR (Optical Character Recognition) library to get the camera on my smartphone to read the text displayed by the timeclock and work, and based on this text, have the phone remind me when I need to return to work.

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

#149813

On 07/02/2020 02:33, Mehdi Amini 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.

While it is commendable to try and practice TDD without a debugger 
(reverting small code changes is much easier than debugging then), none 
of us are perfect.  It is often useful to know why a change breaks things.

Rejecting the tools on offer is more and case of stubbornness than good 
practice.

-- 
Ian

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

#149688

On 2/3/20 10:08 AM, Mehdi Amini wrote:
> 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 ?

It might be - it depends upon the reason why they didn't work correctly.
As far as I can tell, that had not yet been determined by the end of
that thread.

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

Helping you is something people do voluntarily. It's up to each helper
to decide the conditions under which they're willing to help you. You
can accept their help by meeting those terms, or refuse to meet their
terms and accept the fact that you're not going to get their help - its
your choice.

Debuggers can be powerful, useful tools for figuring out why a program
isn't doing what you intended it to do. Refusing to use them has a
corresponding cost. I can sympathize with someone being unwilling to
help if you're not willing to cooperate with the single most useful way
he could suggest to investigate further.

For myself, I would not require use of a debugger. I would, however,
require a complete compilable program that demonstrates the problem,
preferably as small as possible. I'd also require identification of the
toolchain used to created the program, and identification of the options
chosen for each tool in the chain. Not being particularly familiar with
gtk, I couldn't guarantee being able to fix the problem even if you did
provide all of those things - but someone else might.

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

#149723

On 2/3/20 9:26 PM, James Kuyper wrote:
> On 2/3/20 10:08 AM, Mehdi Amini wrote:
>> 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 ?
> 
> It might be - it depends upon the reason why they didn't work correctly.
> As far as I can tell, that had not yet been determined by the end of
> that thread.
> 

I mentioned reasons in another answer in this thread.

>> 2. Is it so that I should be using a debugger , as otherwise others may
>> not help me ?
> 
> Helping you is something people do voluntarily. It's up to each helper
> to decide the conditions under which they're willing to help you. You
> can accept their help by meeting those terms, or refuse to meet their
> terms and accept the fact that you're not going to get their help - its
> your choice.
> 

One person there , AFAIK spoke instead of all helpers. My point being
other helpers may not agree with him.

> Debuggers can be powerful, useful tools for figuring out why a program
> isn't doing what you intended it to do. Refusing to use them has a
> corresponding cost. I can sympathize with someone being unwilling to
> help if you're not willing to cooperate with the single most useful way
> he could suggest to investigate further.
> 
> For myself, I would not require use of a debugger. I would, however,
> require a complete compilable program that demonstrates the problem,
> preferably as small as possible. I'd also require identification of the
> toolchain used to created the program, and identification of the options
> chosen for each tool in the chain. Not being particularly familiar with
> gtk, I couldn't guarantee being able to fix the problem even if you did
> provide all of those things - but someone else might.
> 

IMHO the are two C coding ways. The classical one and the modern one.
The classical uses output(printf) as a path to trace and eliminate bugs.
The modern one is called Test Driven Development (TDD). I am suspect of
debugging technique for my own coding in either way.

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

Farewell.

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

#149725

On 2/4/20 8:54 AM, Mehdi Amini wrote:
> On 2/3/20 9:26 PM, James Kuyper wrote:
>> On 2/3/20 10:08 AM, Mehdi Amini wrote:
>>> 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 ?
>>
>> It might be - it depends upon the reason why they didn't work correctly.
>> As far as I can tell, that had not yet been determined by the end of
>> that thread.
>>
> 
> I mentioned reasons in another answer in this thread.

You mentioned the reasons why you were asking for help. I'm talking
about the reason why you're getting all of those warning messages. As
far as I can tell, no one knows the answer to that question. That's
primarily because you've provided insufficient information to make a guess.

>>> 2. Is it so that I should be using a debugger , as otherwise others may
>>> not help me ?
>>
>> Helping you is something people do voluntarily. It's up to each helper
>> to decide the conditions under which they're willing to help you. You
>> can accept their help by meeting those terms, or refuse to meet their
>> terms and accept the fact that you're not going to get their help - its
>> your choice.
>>
> 
> One person there , AFAIK spoke instead of all helpers. My point being
> other helpers may not agree with him.

Of course other helpers may not agree with him; one of the least likely
things to run into is a large number of people behaving exactly the same
way.
Have you had many others offering to help you? It's entirely possible
that the one who wanted you to use a debugger is one of the most
qualified people to answer your question - or maybe not.

>> Debuggers can be powerful, useful tools for figuring out why a program
>> isn't doing what you intended it to do. Refusing to use them has a
>> corresponding cost. I can sympathize with someone being unwilling to
>> help if you're not willing to cooperate with the single most useful way
>> he could suggest to investigate further.
>>
>> For myself, I would not require use of a debugger. I would, however,
>> require a complete compilable program that demonstrates the problem,
>> preferably as small as possible. I'd also require identification of the
>> toolchain used to created the program, and identification of the options
>> chosen for each tool in the chain. Not being particularly familiar with
>> gtk, I couldn't guarantee being able to fix the problem even if you did
>> provide all of those things - but someone else might.

There's a reason why I insist on such information. I need it in order to
provide any useful advice. As it stands, I don't have any idea why you
are getting those warning messages.

> IMHO the are two C coding ways. The classical one and the modern one.
> The classical uses output(printf) as a path to trace and eliminate bugs.
> The modern one is called Test Driven Development (TDD). I am suspect of
> debugging technique for my own coding in either way.

There's a lot more than two ways; I use neither of those. That is to
say, I can use printf()s if I need to, and I'm quite good at figuring
out where to place them and what to print out to maximize my speed in
tracking down bugs. However, I only do that when I don't have access to
an adequate debugger.

You've given no better reason than personal preference for avoiding
debuggers, which leaves the rest of us with no reason to think that your
preference has any rational basis.

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

#149691

On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son of Bahram  wrote:
> 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 ?

The whole point of engineering is to make some things that do not
work well to work better. It is no ones fault that all things can
be made to work better. It is our blessing, our everyday's bread. 
That however takes years to learn. Consider it as amusing puzzle,
otherwise you will be very frustrated and unhappy software engineer.

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

The tools are usually made by rather good programmers and save lot of
time. If you refuse to use tools then others consider you caveman and
do not want to cooperate with you. It is essential in our industry to
cooperate with others, especially when you are not very skilled. How
else you hope to learn the finest tricks of that trade?

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

#149724

On 2/3/20 11:11 PM, Öö Tiib wrote:
> On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son of Bahram  wrote:

[...]

>> 2. Is it so that I should be using a debugger , as otherwise others may
>> not help me ?
> 
> The tools are usually made by rather good programmers and save lot of
> time. If you refuse to use tools then others consider you caveman and
> do not want to cooperate with you. It is essential in our industry to
> cooperate with others, especially when you are not very skilled. How
> else you hope to learn the finest tricks of that trade?
> 

I am considered a caveman , no matter what.


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

Farewell.

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

#149732

Mehdi Amini wrote:
> On 2/3/20 11:11 PM, Öö Tiib wrote:
>> On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son 
>> of Bahram  wrote:
> 
> [...]
> 
>>> 2. Is it so that I should be using a debugger , as otherwise others may
>>> not help me ?
>>
>> The tools are usually made by rather good programmers and save lot of
>> time. If you refuse to use tools then others consider you caveman and
>> do not want to cooperate with you. It is essential in our industry to
>> cooperate with others, especially when you are not very skilled. How
>> else you hope to learn the finest tricks of that trade?
>>
> 
> I am considered a caveman , no matter what.

If you want to last in the business, and have a long
career, you cannot afford to take any comments personally.

I've tried to use debuggers that were just awful.
I did enjoy using one which was part of an IDE.

You might have to try a few of these, before you
find one that makes you productive.

In a FOSS environment, where the IDE could open library
source modules while you single-step your code, there should
be a real benefit from debugging that way. For a really
tiny project (60 line C program), it's less clear
how much of an advantage it gives you.

*******

I've found managers don't care how the work gets done,
as long as you deliver results on time. If this week
you use a debugger, and next week you use static code
analysis, they don't care. But if you're late delivering
something, the quality is poor, you don't work well with
others, they will provide feedback about how you
can improve your skills. Even if it means "coursework".

I find it passing strange, that as a hardware engineer at work,
*I* was the one promoting the usage of debuggers and profilers.
I ran into quite a few "scowls" from co-workers when
suggesting they try new things.

One incident was hilarious. I told one of our developers,
he should try out the profiler *his friend* wrote. He just
scowled. I left his cubicle. Ten minutes later, he comes
running over to my cubicle all excited. "I found something!".
He'd taken my advice and tried running the profiler on his
current project. There was a hot spot. 25% of execution time
was in three lines of code. *The code was a copy/paste error*.
The code did not even belong in the module and was a mistake.
Well, sure, the code review would have found that, but by
passing the profiler over it, he was spared the
embarrassment of someone finding that before he did.

I would say overall, that I've seen more bad debuggers
than good ones. But don't give up, as eventually you'll
get to try a good one.

The people in this group, have God-like static code
analysis skills. While it's fun to pretend you
belong to this illustrious group, there will be
times when leaning on a crutch, helps you meet
your managers deliverables. You probably can't afford
to copy/paste your entire project into a USENET post,
and let the code analysts at it. And then using the
debugger might be the next best thing, to figuring
out the problem a bit quicker.

    Paul

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

#149736

On 04/02/2020 19:18, Paul wrote:

> 
> The people in this group, have God-like static code
> analysis skills. While it's fun to pretend you
> belong to this illustrious group, there will be
> times when leaning on a crutch, helps you meet
> your managers deliverables. You probably can't afford
> to copy/paste your entire project into a USENET post,
> and let the code analysts at it. And then using the
> debugger might be the next best thing, to figuring
> out the problem a bit quicker.
> 

He seems to want to do without any static analysis either - not even the 
most basic warnings from the compiler.

As for myself, being un-God-like, I use as much static analysis as I can 
reasonably do without obfuscating the code, and "printf debugging", and 
I also use debuggers, and write test code, and so on.  Whatever it takes 
to minimise the risk of bugs making it out of the development computer - 
there is no one answer, no single tool that covers all cases.

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

#149753

On Tue, 2020-02-04, Paul wrote:
> Mehdi Amini wrote:
>> On 2/3/20 11:11 PM, Öö Tiib wrote:
>>> On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son 
>>> of Bahram  wrote:
>> 
>> [...]
>> 
>>>> 2. Is it so that I should be using a debugger , as otherwise others may
>>>> not help me ?
...
(big snip)

> I would say overall, that I've seen more bad debuggers
> than good ones. But don't give up, as eventually you'll
> get to try a good one.

I agree with a lot of what you wrote: but a reality check: he had a
repeatable segfault, people suggested using gdb on the core dump, or
valgrind, to find out what happened, and he refused.

There are uses of debuggers that are debatable (workflows that take a
lot of energy to learn, environments that are hard to set up, stealing
focus from reading the code and maybe just seeing the problem) but this
isn't one of them.

Although really soon he would be back to understanding the APIs he's
using.

/Jorgen

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

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

#149758

On Wednesday, February 5, 2020 at 2:05:31 AM UTC-8, Jorgen Grahn wrote:
> On Tue, 2020-02-04, Paul wrote:
> > Mehdi Amini wrote:
> >> On 2/3/20 11:11 PM, Öö Tiib wrote:
> >>> On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son 
> >>> of Bahram  wrote:
> >> 
> >> [...]
> >> 
> >>>> 2. Is it so that I should be using a debugger , as otherwise others may
> >>>> not help me ?
> ...
> (big snip)
> 
> > I would say overall, that I've seen more bad debuggers
> > than good ones. But don't give up, as eventually you'll
> > get to try a good one.
> 
> I agree with a lot of what you wrote: but a reality check: he had a
> repeatable segfault, people suggested using gdb on the core dump, or
> valgrind, to find out what happened, and he refused.
> 
> There are uses of debuggers that are debatable (workflows that take a
> lot of energy to learn, environments that are hard to set up, stealing
> focus from reading the code and maybe just seeing the problem) but this
> isn't one of them.
> 
>

Oh oh, I got one. This is slightly off topic, but using a debugger with a language that has automatic garbage collection sometimes is a recipe for disaster. The one example that I can think of is that if you are trying to examine the state of an object, but then, like, every once in a while, you can't examine the state, because the object has been garbage collected before the debugger has a chance to step into the object.

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

#149763

On Wednesday, 5 February 2020 10:05:31 UTC, Jorgen Grahn  wrote:
> On Tue, 2020-02-04, Paul wrote:
> > Mehdi Amini wrote:
> >> On 2/3/20 11:11 PM, Öö Tiib wrote:
> >>> On Monday, 3 February 2020 17:08:33 UTC+2, Mehdi Amini Valashani son 
> >>> of Bahram  wrote:
> >> 
> >> [...]
> >> 
> >>>> 2. Is it so that I should be using a debugger , as otherwise others may
> >>>> not help me ?
> ...
> (big snip)
> 
> > I would say overall, that I've seen more bad debuggers
> > than good ones. But don't give up, as eventually you'll
> > get to try a good one.
> 
> I agree with a lot of what you wrote: but a reality check: he had a
> repeatable segfault, people suggested using gdb on the core dump, or
> valgrind, to find out what happened, and he refused.
> 
> There are uses of debuggers that are debatable (workflows that take a
> lot of energy to learn, environments that are hard to set up, stealing
> focus from reading the code and maybe just seeing the problem) but this
> isn't one of them.
> 
> Although really soon he would be back to understanding the APIs he's
> using.
>
The file and line where the program crashed, and a stack trace, is very
useful information. I seldom need anything more to identify crash
bug.

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

#149764

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> The file and line where the program crashed, and a stack trace, is very
> useful information. I seldom need anything more to identify crash
> bug.

This is true (in fact I often don't care about the stack trace).  The
main exception I've come across is when the bug concerns the lifetime of
allocated objects, and the pattern of allocation and freeing is
complicated.

-- 
Ben.

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

#150073

On Mon, 03 Feb 2020 18:38:23 +0330, Mehdi Amini wrote:

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

	No - it's the bugger's.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web