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

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

Getting sensible information from gdb

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

Contents

  Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-11 21:21 +0200
    Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 14:47 -0700
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 00:07 +0200
        Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:15 -0700
          Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-11 21:02 -0400
            Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 18:55 -0700
              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:04 +0200
                Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 19:37 -0700
                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 05:16 +0200
              Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:01 -0400
                Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 06:06 +0200
                  Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:48 -0400
                    Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 07:08 +0200
            Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-11 18:56 -0700
      Re: Getting sensible information from gdb Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-11 18:14 -0400
        Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 00:20 +0200
          Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-11 21:07 -0400
            Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 03:59 +0200
              Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 23:21 -0700
                Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 23:32 -0700
                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:42 +0200
                    Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-12 17:13 +0100
                      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 23:50 +0200
                        Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 01:39 +0100
                          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 03:04 +0200
                            Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 14:13 +0100
                              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 16:26 +0200
                                Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 17:16 +0100
                                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 18:27 +0200
                                    Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 00:17 +0100
                                      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 02:26 +0200
                                        Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 03:59 +0200
                                          Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:04 +0100
                                            Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:48 +0200
                Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:41 +0200
        Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:18 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 01:22 +0200
            Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:42 -0700
              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 02:16 +0200
    Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 18:59 -0700
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:09 +0200
        Re: Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 19:28 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:59 +0200
            Re: Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-12 07:10 -0700
              Re: Getting sensible information from gdb Rosario19 <Ros@invalid.invalid> - 2015-10-12 19:41 +0200
    Re: Getting sensible information from gdb Ian Collins <ian-news@hotmail.com> - 2015-10-12 17:59 +1300
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 07:36 +0200
        Re: Getting sensible information from gdb Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 22:59 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:27 +0200
            Re: Getting sensible information from gdb Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-10-12 10:55 +0200
            Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-12 08:04 -0700
            Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-12 17:35 +0100
        Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-12 08:00 -0700
        Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 12:25 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#72587

On 12.10.2015 08:32, Geoff wrote:
> I forgot to mention that your use of:
>
>    void *current = create_xml_element();
>
> is leading you down a path where the compiler can't help you if you
> use current incorrectly.

Yes, and this is what's wanted.  *current can point to some sort of XML
element, regular or for example CDATA, or it can point to a stream of
characters (element content).

-Morten

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

#72624

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 12.10.2015 08:32, Geoff wrote:
>> I forgot to mention that your use of:
>>
>>    void *current = create_xml_element();
>>
>> is leading you down a path where the compiler can't help you if you
>> use current incorrectly.
>
> Yes, and this is what's wanted.  *current can point to some sort of XML
> element, regular or for example CDATA, or it can point to a stream of
> characters (element content).

Rather it's as designed but I don't say it's wanted.  I can't see any
reason not to use a (pointer to a) union here.  In particular, the code
would be neater if you made the generic xml_element a structure with all
the common members (type, parent and so on) when then includes a union
member with the variable parts.

-- 
Ben.

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

#72660

On 12.10.2015 18:13, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>
>> On 12.10.2015 08:32, Geoff wrote:
>>> I forgot to mention that your use of:
>>>
>>>     void *current = create_xml_element();
>>>
>>> is leading you down a path where the compiler can't help you if you
>>> use current incorrectly.
>>
>> Yes, and this is what's wanted.  *current can point to some sort of XML
>> element, regular or for example CDATA, or it can point to a stream of
>> characters (element content).
>
> Rather it's as designed but I don't say it's wanted.  I can't see any
> reason not to use a (pointer to a) union here.  In particular, the code
> would be neater if you made the generic xml_element a structure with all
> the common members (type, parent and so on) when then includes a union
> member with the variable parts.

OK, can you give a code example?

-Morten

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

#72665

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 12.10.2015 18:13, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>
>>> On 12.10.2015 08:32, Geoff wrote:
>>>> I forgot to mention that your use of:
>>>>
>>>>     void *current = create_xml_element();
>>>>
>>>> is leading you down a path where the compiler can't help you if you
>>>> use current incorrectly.
>>>
>>> Yes, and this is what's wanted.  *current can point to some sort of XML
>>> element, regular or for example CDATA, or it can point to a stream of
>>> characters (element content).
>>
>> Rather it's as designed but I don't say it's wanted.  I can't see any
>> reason not to use a (pointer to a) union here.  In particular, the code
>> would be neater if you made the generic xml_element a structure with all
>> the common members (type, parent and so on) when then includes a union
>> member with the variable parts.
>
> OK, can you give a code example?

There are lots of variations and I've not looked at how you use these
structures in enough detail to be sure, but based on the declarations
themselves you might try something like this:

  struct xml_item {
       small_int type;
       struct xml_item *parent, *next, *previous;
   
       union {
            struct xml_element {
                 unicode_char *name;
                 struct xml_attribute *attributes;
                 struct xml_item *child; 
            } element;
   
            struct xml_attribute {
                 unicode_char *name, *characters;
            } attribute;
   
            struct xml_text {
                 unicode_char *characters;
            } text;
       };
  };

You can either allocate all objects as struct xml_item which is simple
but wastes a few bytes for those types that are not as long as the
longest, or you can allocate the right amount of space using the rather
cumbersome

  offsetof(struct xml_item, text) + sizeof (struct xml_text)

but that can be turned into a macro:

  #define XML_SIZE_OF(type) \
      (offsetof(struct xml_item, type) + sizeof (struct xml_ ## type))

-- 
Ben.

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

#72669

On 13.10.2015 02:39, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> OK, can you give a code example?
>
> There are lots of variations and I've not looked at how you use these
> structures in enough detail to be sure, but based on the declarations
> themselves you might try something like this:
>
>    struct xml_item {
>         small_int type;
>         struct xml_item *parent, *next, *previous;
>
>         union {
>              struct xml_element {
>                   unicode_char *name;
>                   struct xml_attribute *attributes;
>                   struct xml_item *child;
>              } element;
>
>              struct xml_attribute {
>                   unicode_char *name, *characters;
>              } attribute;
>
>              struct xml_text {
>                   unicode_char *characters;
>              } text;
>         };
>    };
>
> You can either allocate all objects as struct xml_item which is simple
> but wastes a few bytes for those types that are not as long as the
> longest, or you can allocate the right amount of space using the rather
> cumbersome
>
>    offsetof(struct xml_item, text) + sizeof (struct xml_text)
>
> but that can be turned into a macro:
>
>    #define XML_SIZE_OF(type) \
>        (offsetof(struct xml_item, type) + sizeof (struct xml_ ## type))

Aha.  :)

So using this approach, I don't need to cast into different types,
rather the type of the union struct will be found based on the name of
the struct member being accessed?

-Morten

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

#72697

"Morten W. Petersen" <morphex@gmail.com> writes:
<snip union example>
> So using this approach, I don't need to cast into different types,
> rather the type of the union struct will be found based on the name of
> the struct member being accessed?

Yes.  And you can, if you like, add access functions that check the type
member on every access.

In another organisation you can define all the separate structues (I'd
still use a common struct for the common elements rather than
duplicating the declarations) and then you put them all in a union for
those cases where you need a generic object.  I'm not sure which would
suit you better.

-- 
Ben.

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

#72702

On 13.10.2015 15:13, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
> <snip union example>
>> So using this approach, I don't need to cast into different types,
>> rather the type of the union struct will be found based on the name of
>> the struct member being accessed?
>
> Yes.  And you can, if you like, add access functions that check the type
> member on every access.

OK, cool.

> In another organisation you can define all the separate structues (I'd
> still use a common struct for the common elements rather than
> duplicating the declarations) and then you put them all in a union for
> those cases where you need a generic object.  I'm not sure which would
> suit you better.

Well getting rid of all those casts is a good enough reason to use this
type of struct.

As for having a generic object, I don't quite like the idea of
allocating a full-size struct and then resizing it by some bytes
if they aren't necessary.

But I could create factory functions for this then, that allocate
memory for the largest possible struct and then give it the right
memory allocation before passing it back.  Or not?

-Morten

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

#72712

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 13.10.2015 15:13, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>> <snip union example>
>>> So using this approach, I don't need to cast into different types,
>>> rather the type of the union struct will be found based on the name of
>>> the struct member being accessed?
>>
>> Yes.  And you can, if you like, add access functions that check the type
>> member on every access.
>
> OK, cool.
>
>> In another organisation you can define all the separate structues (I'd
>> still use a common struct for the common elements rather than
>> duplicating the declarations) and then you put them all in a union for
>> those cases where you need a generic object.  I'm not sure which would
>> suit you better.
>
> Well getting rid of all those casts is a good enough reason to use this
> type of struct.
>
> As for having a generic object, I don't quite like the idea of
> allocating a full-size struct and then resizing it by some bytes
> if they aren't necessary.

That's not what I meant, but if you are likely to use the first outline
there's no point in drilling down into the second scheme.

> But I could create factory functions for this then, that allocate
> memory for the largest possible struct and then give it the right
> memory allocation before passing it back.  Or not?

I don't follow, but, as I said above, if this is about my "other
organisation" there is no need to use it if you prefer the one I
sketched in code.

-- 
Ben.

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

#72717

On 13.10.2015 18:16, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> Well getting rid of all those casts is a good enough reason to use this
>> type of struct.
>>
>> As for having a generic object, I don't quite like the idea of
>> allocating a full-size struct and then resizing it by some bytes
>> if they aren't necessary.
>
> That's not what I meant, but if you are likely to use the first outline
> there's no point in drilling down into the second scheme.
>
>> But I could create factory functions for this then, that allocate
>> memory for the largest possible struct and then give it the right
>> memory allocation before passing it back.  Or not?
>
> I don't follow, but, as I said above, if this is about my "other
> organisation" there is no need to use it if you prefer the one I
> sketched in code.

Well, a union allocates space for the largest data type it can contain,
the smallest data type in that union has one pointer, while the largest
has three.

Being able to address members of a struct without casting is nice, so
I want to do that.

However, if it is a text element, there is space for two pointers there,
which are not needed.

So, at the end of the factory function which allocates memory and
initializes the struct, it can do something like

   realloc(sizeof(xml_item) - (sizeof(void*)*0 or 1 or 2))

Right?

-Morten

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

#72759

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 13.10.2015 18:16, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> Well getting rid of all those casts is a good enough reason to use this
>>> type of struct.
>>>
>>> As for having a generic object, I don't quite like the idea of
>>> allocating a full-size struct and then resizing it by some bytes
>>> if they aren't necessary.
>>
>> That's not what I meant, but if you are likely to use the first outline
>> there's no point in drilling down into the second scheme.
>>
>>> But I could create factory functions for this then, that allocate
>>> memory for the largest possible struct and then give it the right
>>> memory allocation before passing it back.  Or not?
>>
>> I don't follow, but, as I said above, if this is about my "other
>> organisation" there is no need to use it if you prefer the one I
>> sketched in code.
>
> Well, a union allocates space for the largest data type it can contain,
> the smallest data type in that union has one pointer, while the largest
> has three.

A union allocates nothing.  The size of a union is sufficient to hold
it's largest member but you are not obliged use the size of the union to
allocate space.

> Being able to address members of a struct without casting is nice, so
> I want to do that.
>
> However, if it is a text element, there is space for two pointers there,
> which are not needed.
>
> So, at the end of the factory function which allocates memory and
> initializes the struct, it can do something like
>
>   realloc(sizeof(xml_item) - (sizeof(void*)*0 or 1 or 2))
>
> Right?

It's not a very good idea to realloc to a slightly smaller size.  For
one thing, it make make no change at all, but even it does why take the
time and risk the fragmentation and/or copying when you can allocate the
right size to start with?

-- 
Ben.

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

#72763

On 14.10.2015 01:17, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> Being able to address members of a struct without casting is nice, so
>> I want to do that.
>>
>> However, if it is a text element, there is space for two pointers there,
>> which are not needed.
>>
>> So, at the end of the factory function which allocates memory and
>> initializes the struct, it can do something like
>>
>>    realloc(sizeof(xml_item) - (sizeof(void*)*0 or 1 or 2))
>>
>> Right?
>
> It's not a very good idea to realloc to a slightly smaller size.  For
> one thing, it make make no change at all, but even it does why take the
> time and risk the fragmentation and/or copying when you can allocate the
> right size to start with?

OK, so malloc to the right size from the beginning then.

-Morten

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

#72773

On 14.10.2015 02:26, Morten W. Petersen wrote:
> On 14.10.2015 01:17, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> Being able to address members of a struct without casting is nice, so
>>> I want to do that.
>>>
>>> However, if it is a text element, there is space for two pointers there,
>>> which are not needed.
>>>
>>> So, at the end of the factory function which allocates memory and
>>> initializes the struct, it can do something like
>>>
>>>    realloc(sizeof(xml_item) - (sizeof(void*)*0 or 1 or 2))
>>>
>>> Right?
>>
>> It's not a very good idea to realloc to a slightly smaller size.  For
>> one thing, it make make no change at all, but even it does why take the
>> time and risk the fragmentation and/or copying when you can allocate the
>> right size to start with?
>
> OK, so malloc to the right size from the beginning then.

Alright, got that changed and synced to the repository, works fine.

I changed the characters name to contents on xml_attribute as I
thought I could do xml->contents, but found out that it had to be
xml->attribute.contents.

But maybe that's a better name anyway.

-Morten

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

#72826

"Morten W. Petersen" <morphex@gmail.com> writes:

<snip>
> I changed the characters name to contents on xml_attribute as I
> thought I could do xml->contents, but found out that it had to be
> xml->attribute.contents.

C11 makes official a very common extension -- that of anonymous structs
and unions.  Provided the individual sub-member names are unique, a
contained struct or union need not have a member name itself:

  union union_example {
       struct { int a; double b; };
       struct { double f; int i; };
  } u;
   
  struct struct_example {
       struct { int a; double b; };
       struct { double f; int i; };
  } s;

You can now refer to u.b and s.i without ambiguity.  Obviously you won't
be doing this since you've opted for C90.

> But maybe that's a better name anyway.

Yes, I'd say so.  In fact, there could be an argument for collecting the
common parts into a structure with a name, but since I can't come up
with one that's really convincing, maybe not.  (The point would be that
you'd write this->xml.parent, next->xml.previous and so on, but names
like "xml", "header" and "common" don't carry much helpful meaning.)

-- 
Ben.

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

#72933

On 14.10.2015 14:04, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>
> <snip>
>> I changed the characters name to contents on xml_attribute as I
>> thought I could do xml->contents, but found out that it had to be
>> xml->attribute.contents.
>
> C11 makes official a very common extension -- that of anonymous structs
> and unions.  Provided the individual sub-member names are unique, a
> contained struct or union need not have a member name itself:
>
>    union union_example {
>         struct { int a; double b; };
>         struct { double f; int i; };
>    } u;
>
>    struct struct_example {
>         struct { int a; double b; };
>         struct { double f; int i; };
>    } s;
>
> You can now refer to u.b and s.i without ambiguity.  Obviously you won't
> be doing this since you've opted for C90.

Yeah, and that's OK.

>> But maybe that's a better name anyway.
>
> Yes, I'd say so.  In fact, there could be an argument for collecting the
> common parts into a structure with a name, but since I can't come up
> with one that's really convincing, maybe not.  (The point would be that
> you'd write this->xml.parent, next->xml.previous and so on, but names
> like "xml", "header" and "common" don't carry much helpful meaning.)

Well I found that before using this struct you suggested, debugging was
a bit tedious as I had to cast and mess around with parenthesizes, so
this is a much better approach.

I also saw that the debugger displayed the type of the struct as well
so I don't see any need for ->xml, people can use a debugger, an IDE or
read a few lines.

-Morten

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

#72586

On 12.10.2015 08:21, Geoff wrote:
[...]

OK.

> P.S. I'm a bit unclear about where parse_file() fits into your scheme.
> Is it a library function or part of your test harness? If it's a test
> function then it properly belongs in tests.c.
>
> PPS: Whether you settle on file or stream input won't matter to the
> structure of your library, all it should know or care about is that
> the data comes in and to that extent your library will be event
> driven.

Well keeping things on the stream level will remove the need to take
platform-specific file handling into account.

So yes, parse_file and maybe another function belongs in the tests.c
file.

-Morten

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

#72534

On Sun, 11 Oct 2015 18:14:53 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 10/11/2015 5:47 PM, Geoff wrote:
>> On Sun, 11 Oct 2015 21:21:43 +0200, "Morten W. Petersen"
>> <morphex@gmail.com> wrote:
>>[...]
>>> #define HANDLE_ERROR(message, ...) char* _message = message;\
>>>   char buffer[1024*1024];\
>>>   sprintf(buffer, _message, __VA_ARGS__);\
>>>   printf("Error: %s\n", message)
>>
>>> #define FAIL(message, ...) char* _message = message;\
>>>   char buffer__abc[1024*1024];\
>>>   sprintf(buffer__abc, _message, __VA_ARGS__);\
>>>   printf("\n%s\n", buffer__abc); fflush(NULL);	\
>>>   exit(1)
>>
>> These macros use unnecessarily large buffers. Use 1024, not 1024*1024.
>> Every invocation of these macros adds to the stack space used by your
>> test program, eventually your program smashes its own stack. Your
>> program is living up to its name.
>
>     You've pointed this out to him before, and he asked "Is there a
>better alternative?"  I told him of one, and you chipped in with an
>even simpler alternative.
>
>     That was two weeks ago.
>

Was that the vprintf suggestion? It's been so long I'm not sure.

>     And he's still using his bloated, unnecessary, silly buffers.
>
>     I give up.

I'm not surprised. 

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

#72535

On 12.10.2015 01:18, Geoff wrote:
> On Sun, 11 Oct 2015 18:14:53 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
[...]
>>      And he's still using his bloated, unnecessary, silly buffers.
>>
>>      I give up.
>
> I'm not surprised.

Well I think you both have a negative attitude.  Maybe you should
code less and get out more.

-Morten

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

#72537

On Mon, 12 Oct 2015 01:22:40 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>On 12.10.2015 01:18, Geoff wrote:
>> On Sun, 11 Oct 2015 18:14:53 -0400, Eric Sosman
>> <esosman@comcast-dot-net.invalid> wrote:
>[...]
>>>      And he's still using his bloated, unnecessary, silly buffers.
>>>
>>>      I give up.
>>
>> I'm not surprised.
>
>Well I think you both have a negative attitude.  Maybe you should
>code less and get out more.
>

Free advice is worth what you pay for it. This is Usenet.

But I've spent some time looking at your code and I've given you very
concrete advice about how to fix your code so it will execute and not
immediately crash. I've even re-written tests.c and decode_xml.c and a
set of proper headers just to see how it can be done and to prove out
my advice to you and you have ignored mine, Eric's and others. But I
also saw you distracted by the drifted threads.

The group often goes off on tangential discussions and hijacks a topic
as it did two weeks ago but you are doing yourself no favors by
sniping at those who offer you their specific advice. Most in this
group probably stopped looking at your code when they saw your rat
variable and the collections of test booleans crammed with commas.

Take my advice or not, but don't be snide with me because I'm
impatient when you ignore it more than once.

If you choose to ignore it and you still can't get your program to run
without crashing, don't expect anyone to respond when you ask the same
question again.

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

#72538

On 12.10.2015 01:42, Geoff wrote:
> On Mon, 12 Oct 2015 01:22:40 +0200, "Morten W. Petersen"
> <morphex@gmail.com> wrote:
>
>> On 12.10.2015 01:18, Geoff wrote:
>>> On Sun, 11 Oct 2015 18:14:53 -0400, Eric Sosman
>>> <esosman@comcast-dot-net.invalid> wrote:
>> [...]
>>>>       And he's still using his bloated, unnecessary, silly buffers.
>>>>
>>>>       I give up.
>>>
>>> I'm not surprised.
>>
>> Well I think you both have a negative attitude.  Maybe you should
>> code less and get out more.
>>
>
> Free advice is worth what you pay for it. This is Usenet.
>
> But I've spent some time looking at your code and I've given you very
> concrete advice about how to fix your code so it will execute and not
> immediately crash. I've even re-written tests.c and decode_xml.c and a
> set of proper headers just to see how it can be done and to prove out
> my advice to you and you have ignored mine, Eric's and others. But I
> also saw you distracted by the drifted threads.
>
> The group often goes off on tangential discussions and hijacks a topic
> as it did two weeks ago but you are doing yourself no favors by
> sniping at those who offer you their specific advice. Most in this
> group probably stopped looking at your code when they saw your rat
> variable and the collections of test booleans crammed with commas.

I'm not criticizing your feedback on code which is correct, it's about
the way you and Eric behave in this thread.

It's not a big surprise though, I've seen my share of coders that
lack basic social skills and maybe you two have been treated like
this in your past and think it is OK.

But it's not.

Fine, offer me piece of cake but don't sprinkle it with shit.

-Morten

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

#72550

Morten W. Petersen wrote:
> Is there something I can do to get
> information of what's going on?

Switch to Visual Studio and use a real debugger.
You'll be amazed how much more capable that
toolset is over gcc+gdb, and how much more
productive you are with the Code Definition
window, watches, autos, etc.  There is no comparison.
Microsoft's VS buries all tools on *nix by an order
of magnitude in my opinion.

After you get it debugged, switch back.

Best regards,
Rick C. Hodgin

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web