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 1 of 3  [1] 2 3  Next page →

#72506 — Getting sensible information from gdb

Hi.

I'm encountering a segmentation violation in my code, and running
gdb on it doesn't help much, as I can't seem to find out what's
wrong anyway.

The gdb session goes like this:

"""
(gdb) watch count
Hardware watchpoint 2: count
(gdb) break decode_xml.c:934 if count == 5
Breakpoint 3 at 0x804a089: file decode_xml.c, line 934.
(gdb) cont
Continuing.
                 <print_unicode: bfafed50
entry  65,6e,74,72,79,
end print_unicode
 >
print_tree, 2, bfafed7c, 3
                 <print_unicode: bf9fecf0
entry  65,6e,74,72,79,
end print_unicode
 >
print_tree, 2, bf9fed1c, 4
                 <print_unicode: bf8fec90
entry  65,6e,74,72,79,
end print_unicode
 >
print_tree, 2, bf8fecbc, 5

Breakpoint 3, print_tree (start=0x80509c0, level=2, count=5)
     at decode_xml.c:935
935         print_tree(start->next, level, count+1);
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x08049ec5 in print_tree (
     start=<error reading variable: Cannot access memory at address 
0xbf7fec5c>, level=2, count=6) at decode_xml.c:914
914     void print_tree(struct xml_element* start, int level, int count) {
(gdb)
"""

And when poking around in gdb after that, I can't see anything
that can be the cause of this error.

The version of the project that gives this error is here:

https://github.com/morphex/smash_xml/tree/25221c21d163ec106abca704b0619e1375e5409c

Is there something I can do to get information of what's going on?

-Morten

[toc] | [next] | [standalone]

#72521

On Sun, 11 Oct 2015 21:21:43 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>The version of the project that gives this error is here:
>
>https://github.com/morphex/smash_xml/tree/25221c21d163ec106abca704b0619e1375e5409c
>
>Is there something I can do to get information of what's going on?

I don't even get past the C startup code that passes control to main()
in my systems. If you're not even in main yet, gdb isn't going to help
you.

Your fault is here, as I have said previously:

>/*
>
>  The amount of characters to read from a char stream at a time.
>
>  The amount of bytes we can read.
>
>*/
>#define READ_AMOUNT 4096
>#define READ_BYTES 1024*1024*100
>#if (READ_BYTES % READ_AMOUNT)
>  #error READ_BYTES must be divisible by READ_AMOUNT
>#endif

This is unsafe and unnecessary. Large static buffers are not going to
protect you. 

If you _must_ do silly things like this then dispense with the
cross-check of the sizes and simply write:

#define READ_AMOUNT 4096
#define READ_BYTES READ_AMOUNT * 100

However, this is still unsafe when handling uncontrolled user input.
You should have learned those principles in your Python practice.

>#define CHAR_SIZE sizeof(char)

>#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.

The macros themselves are completely unnecessary. Get rid of them.

I don't know where you got these macros from but they are not helping
you at all. This is called cargo cult programming where I come from.
You're using stuff without a fundamental understanding of why and
where it should be used. 

Your test driver program is just that, a test driver. Write your
diagnostics output messages as simple printf() statements and be done
with it. Every test in your driver code should evaluate the returns
from your library functions and only when the return is invalid per
the test, terminate or issue a message. Your library should never
explicitly terminate for any reason if you are going to meet your
stated design goals.

If you insist on using FAIL-type functionality learn to use assert()
instead. Your FAIL macro is interfering with the proper functioning of
your library code. Even assert would be wrong for many of your
functions. What you should be doing is coding your library to return
errors to the calling function if and only if they can fail. You
should always write your callers to check the return values from your
library functions and only then should the caller exit the program,
your library should NEVER terminate the program.

Every FAIL call is a failure on your part to properly plan and code
your library functions to handle errors properly.

Speaking of checking return values, you need to learn to handle the C
library functions properly. You fail to check the return value of
malloc(), realloc() and fopen().

You needlessly initialize your buffer and file pointers to NULL, then
you fail to check that malloc and fopen returned valid pointers. If
they are going to fail, they are going to be NULL anyway, but then you
proceed to use them without checking them first.

Write:

  unicode_char *buffer = NULL;  // needless initialization
  source_buffer_index read = 0;
  small_fast_int valid_unicode = 0;
  
  buffer = (unicode_char*)malloc(READ_BYTES);
  if (!buffer) {
    printf("ERROR: buffer allocation failed\n");
    exit(1);
  }
	  
  FILE *file = NULL;		// another needless initialization
  file = fopen("test.xml", "rb+");
  if (file == NULL) {
    printf("ERROR: XML file not opened\n");
    exit(1);
  }

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

#72523

On 11.10.2015 23:47, Geoff wrote:
> On Sun, 11 Oct 2015 21:21:43 +0200, "Morten W. Petersen"
> <morphex@gmail.com> wrote:
[...]
> Your fault is here, as I have said previously:
>
>> /*
>>
>>   The amount of characters to read from a char stream at a time.
>>
>>   The amount of bytes we can read.
>>
>> */
>> #define READ_AMOUNT 4096
>> #define READ_BYTES 1024*1024*100
>> #if (READ_BYTES % READ_AMOUNT)
>>   #error READ_BYTES must be divisible by READ_AMOUNT
>> #endif
>
> This is unsafe and unnecessary. Large static buffers are not going to
> protect you.
>
> If you _must_ do silly things like this then dispense with the
> cross-check of the sizes and simply write:
>
> #define READ_AMOUNT 4096
> #define READ_BYTES READ_AMOUNT * 100
>
> However, this is still unsafe when handling uncontrolled user input.
> You should have learned those principles in your Python practice.
>
>> #define CHAR_SIZE sizeof(char)
>
>> #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.
>
> The macros themselves are completely unnecessary. Get rid of them.

Ah right, I remember some talk about this and I forgot about it.

> I don't know where you got these macros from but they are not helping
> you at all. This is called cargo cult programming where I come from.
> You're using stuff without a fundamental understanding of why and
> where it should be used.

Or I bump my head into things until I get it. :)

I think most or all of these FAIL and HANDLE_ERROR instances are
conditional, that is they pop up at the end of something if one
shouldn't get to the end (it should return earlier), or they pop
up within an if statement with a following section of code in brackets..

So regardless of where a variable has been defined in a function,
it may be allocated at the very beginning of the function call?

> Your test driver program is just that, a test driver. Write your
> diagnostics output messages as simple printf() statements and be done
> with it. Every test in your driver code should evaluate the returns
> from your library functions and only when the return is invalid per
> the test, terminate or issue a message. Your library should never
> explicitly terminate for any reason if you are going to meet your
> stated design goals.

Mm, OK.

> If you insist on using FAIL-type functionality learn to use assert()
> instead. Your FAIL macro is interfering with the proper functioning of
> your library code. Even assert would be wrong for many of your
> functions. What you should be doing is coding your library to return
> errors to the calling function if and only if they can fail. You
> should always write your callers to check the return values from your
> library functions and only then should the caller exit the program,
> your library should NEVER terminate the program.
>
> Every FAIL call is a failure on your part to properly plan and code
> your library functions to handle errors properly.
>
> Speaking of checking return values, you need to learn to handle the C
> library functions properly. You fail to check the return value of
> malloc(), realloc() and fopen().

OK.  Yes that's true, I should get some handling in there for failing
memory allocations.  I was thinking of having a function that could
reorganize/pack the memory allocations.

As for fopen, I'm thinking the design should go towards dealing with
streams, so the file will already be open.  And the fopen in the test
suite, if it fails, will fail the test and that will be an indication
of failure in that part.

> You needlessly initialize your buffer and file pointers to NULL, then
> you fail to check that malloc and fopen returned valid pointers. If
> they are going to fail, they are going to be NULL anyway, but then you
> proceed to use them without checking them first.
>
> Write:
>
>    unicode_char *buffer = NULL;  // needless initialization
>    source_buffer_index read = 0;
>    small_fast_int valid_unicode = 0;
>
>    buffer = (unicode_char*)malloc(READ_BYTES);
>    if (!buffer) {
>      printf("ERROR: buffer allocation failed\n");
>      exit(1);
>    }
> 	
>    FILE *file = NULL;		// another needless initialization
>    file = fopen("test.xml", "rb+");
>    if (file == NULL) {
>      printf("ERROR: XML file not opened\n");
>      exit(1);
>    }

My thinking was that I should never leave a pointer uninitialized,
so I'll switch to declaring and initializing to a value in the same
go.

-Morten

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

#72533

On Mon, 12 Oct 2015 00:07:46 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>On 11.10.2015 23:47, Geoff wrote:
>> On Sun, 11 Oct 2015 21:21:43 +0200, "Morten W. Petersen"
>> <morphex@gmail.com> wrote:
>[...]
>> Your fault is here, as I have said previously:
>>
>>> /*
>>>
>>>   The amount of characters to read from a char stream at a time.
>>>
>>>   The amount of bytes we can read.
>>>
>>> */
>>> #define READ_AMOUNT 4096
>>> #define READ_BYTES 1024*1024*100
>>> #if (READ_BYTES % READ_AMOUNT)
>>>   #error READ_BYTES must be divisible by READ_AMOUNT
>>> #endif
>>
>> This is unsafe and unnecessary. Large static buffers are not going to
>> protect you.
>>
>> If you _must_ do silly things like this then dispense with the
>> cross-check of the sizes and simply write:
>>
>> #define READ_AMOUNT 4096
>> #define READ_BYTES READ_AMOUNT * 100
>>
>> However, this is still unsafe when handling uncontrolled user input.
>> You should have learned those principles in your Python practice.
>>
>>> #define CHAR_SIZE sizeof(char)
>>
>>> #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.
>>
>> The macros themselves are completely unnecessary. Get rid of them.
>
>Ah right, I remember some talk about this and I forgot about it.
>

I don't blame you for losing track, that topic drifted quite badly.

>> I don't know where you got these macros from but they are not helping
>> you at all. This is called cargo cult programming where I come from.
>> You're using stuff without a fundamental understanding of why and
>> where it should be used.
>
>Or I bump my head into things until I get it. :)
>

So, there is hope..

>I think most or all of these FAIL and HANDLE_ERROR instances are
>conditional, that is they pop up at the end of something if one
>shouldn't get to the end (it should return earlier), or they pop
>up within an if statement with a following section of code in brackets..
>
>So regardless of where a variable has been defined in a function,
>it may be allocated at the very beginning of the function call?
>

Get rid of the macros and you don't need to be concerned about it.

Suffice to say, on typical x86 implementations of C, there is a stack
frame for every function and it's sized to accommodate all local
variables of that function. Your essentially expand to inline code and
those local variables add to the burden.

>> Your test driver program is just that, a test driver. Write your
>> diagnostics output messages as simple printf() statements and be done
>> with it. Every test in your driver code should evaluate the returns
>> from your library functions and only when the return is invalid per
>> the test, terminate or issue a message. Your library should never
>> explicitly terminate for any reason if you are going to meet your
>> stated design goals.
>
>Mm, OK.
>
>> If you insist on using FAIL-type functionality learn to use assert()
>> instead. Your FAIL macro is interfering with the proper functioning of
>> your library code. Even assert would be wrong for many of your
>> functions. What you should be doing is coding your library to return
>> errors to the calling function if and only if they can fail. You
>> should always write your callers to check the return values from your
>> library functions and only then should the caller exit the program,
>> your library should NEVER terminate the program.
>>
>> Every FAIL call is a failure on your part to properly plan and code
>> your library functions to handle errors properly.
>>
>> Speaking of checking return values, you need to learn to handle the C
>> library functions properly. You fail to check the return value of
>> malloc(), realloc() and fopen().
>
>OK.  Yes that's true, I should get some handling in there for failing
>memory allocations.  I was thinking of having a function that could
>reorganize/pack the memory allocations.
>

You are not at that stage yet. Anything you implement at this point
will just be more cargo cult or copy-paste programming.

Go down the line on each of the functions in decode_xml.c, eliminate
all FAIL calls, refactor the functions to return error conditions
where needed. 

Or more simply use:
    printf("Error not handled in function: %s \n", __FUNCTION__,
__FILE__); 

This is C90 compliant and consistent with your project. You can
annotate this with a comment that you're coming back to it later.

>As for fopen, I'm thinking the design should go towards dealing with
>streams, so the file will already be open.  And the fopen in the test
>suite, if it fails, will fail the test and that will be an indication
>of failure in that part.
>

Deal with that issue later. For now your sole goal should be to get
your test driver working and you are wasting time otherwise.

>> You needlessly initialize your buffer and file pointers to NULL, then
>> you fail to check that malloc and fopen returned valid pointers. If
>> they are going to fail, they are going to be NULL anyway, but then you
>> proceed to use them without checking them first.
>>
>> Write:
>>
>>    unicode_char *buffer = NULL;  // needless initialization
>>    source_buffer_index read = 0;
>>    small_fast_int valid_unicode = 0;
>>
>>    buffer = (unicode_char*)malloc(READ_BYTES);
>>    if (!buffer) {
>>      printf("ERROR: buffer allocation failed\n");
>>      exit(1);
>>    }
>> 	
>>    FILE *file = NULL;		// another needless initialization
>>    file = fopen("test.xml", "rb+");
>>    if (file == NULL) {
>>      printf("ERROR: XML file not opened\n");
>>      exit(1);
>>    }
>
>My thinking was that I should never leave a pointer uninitialized,
>so I'll switch to declaring and initializing to a value in the same
>go.
>
That's not necessary if you check their proper initialization before
use. (Critics would say it's defensive programming in some cases but
if a function can return a NULL pointer then you MUST test it's not
NULL before you can dereference it.)

Concentrate on declaring, checking, and dereferencing them in
proximity to their use, as above, I have shown you two cases where the
pointer is declared, initialized and checked after initialization and
two idioms of the checks. There is also errno for diagnostics but for
your test harness this is redundant, IMO.

What you should be concentrating on is structuring your functions to
return an error value if they can fail and return the proper object
when they succeed. I saw a lot of cases where you were returning
nothing but the function definitions said they were returning a
pointer.

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

#72542

On 10/11/2015 07:15 PM, Geoff wrote:
...
> Or more simply use:
>     printf("Error not handled in function: %s \n", __FUNCTION__,
> __FILE__); 
> 
> This is C90 compliant and consistent with your project. You can
> annotate this with a comment that you're coming back to it later.

Unlike __FILE__, __FUNCTION__ is not one the identifiers that the C
standard requires an implementation to pre#define, nor is it an
identifier that the user has permission to define, not in any context.
__func__ was added in C99, is that what you were thinking of? If
__FUNCTION__ is a compiler-specific extension to C, you should identify
at least one of the compilers that supports it.
-- 
James Kuyper

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

#72547

On Sun, 11 Oct 2015 21:02:32 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 10/11/2015 07:15 PM, Geoff wrote:
>...
>> Or more simply use:
>>     printf("Error not handled in function: %s \n", __FUNCTION__,
>> __FILE__); 
>> 
>> This is C90 compliant and consistent with your project. You can
>> annotate this with a comment that you're coming back to it later.
>
>Unlike __FILE__, __FUNCTION__ is not one the identifiers that the C
>standard requires an implementation to pre#define, nor is it an
>identifier that the user has permission to define, not in any context.
>__func__ was added in C99, is that what you were thinking of? If
>__FUNCTION__ is a compiler-specific extension to C, you should identify
>at least one of the compilers that supports it.

Oops, my mistake. 

Yes, I've used __func__ on MSVC and Linux GCC in the past. I tested
__FUNCTION__ on Microsoft VS2010 and 2013 and it also worked on LLVM
on the MacBook with the compiler set to -ansi before I posted the code
so I assumed it was supported on his gcc implementation. I clearly
overstated the compatibility, however. 

Looking at the Microsoft documentation I see __FUNCTION__ is Microsoft
specific in their documentation but in the Xcode documentation it's
been in there since C99 and in gcc "for a long time" and clearly
supported there. While not strictly C90, I'm sure Morton's compiler
will handle it and he'll be better off without the FAIL macro and all
its defects.

There, you see Morton? You can always count on someone raising some
niggling point about something completely unhelpful to solving the
problem raised by the OP and correcting what someone else wrote. It's
all about the disciplined mind set and the necessity of absolute
obedience to the language and the law of the ever-changing standard.

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

#72551

On 12.10.2015 03:55, Geoff wrote:
[...]
> There, you see Morton? You can always count on someone raising some
> niggling point about something completely unhelpful to solving the
> problem raised by the OP and correcting what someone else wrote. It's
> all about the disciplined mind set and the necessity of absolute
> obedience to the language and the law of the ever-changing standard.

It's Morten, not Morton, by the way.

-Morten

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

#72555

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

>On 12.10.2015 03:55, Geoff wrote:
>[...]
>> There, you see Morton? You can always count on someone raising some
>> niggling point about something completely unhelpful to solving the
>> problem raised by the OP and correcting what someone else wrote. It's
>> all about the disciplined mind set and the necessity of absolute
>> obedience to the language and the law of the ever-changing standard.
>
>It's Morten, not Morton, by the way.
>
>-Morten

Sorry, perhaps it was the salty disposition? :)

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

#72562

On 12.10.2015 04:37, Geoff wrote:
> On Mon, 12 Oct 2015 04:04:43 +0200, "Morten W. Petersen"
> <morphex@gmail.com> wrote:
>
>> On 12.10.2015 03:55, Geoff wrote:
>> [...]
>>> There, you see Morton? You can always count on someone raising some
>>> niggling point about something completely unhelpful to solving the
>>> problem raised by the OP and correcting what someone else wrote. It's
>>> all about the disciplined mind set and the necessity of absolute
>>> obedience to the language and the law of the ever-changing standard.
>>
>> It's Morten, not Morton, by the way.
>>
>> -Morten
>
> Sorry, perhaps it was the salty disposition? :)

I have some mineral salt in my kitchen cabinet which is 50% regular
salt, then some potassium chloride and some other things.

That helps the blood pressure down. :)

-Morten

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

#72564

On 10/11/2015 09:55 PM, Geoff wrote:
...
> There, you see Morton? You can always count on someone raising some
> niggling point about something completely unhelpful to solving the
> problem raised by the OP and correcting what someone else wrote.

Thanks, I do what I can! :-)
Which, as far as I can tell, does not include coming up with any advice
significantly different from that which he's already chosen to ignore.
-- 
James Kuyper

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

#72565

On 12.10.2015 06:01, James Kuyper wrote:
> On 10/11/2015 09:55 PM, Geoff wrote:
> ...
>> There, you see Morton? You can always count on someone raising some
>> niggling point about something completely unhelpful to solving the
>> problem raised by the OP and correcting what someone else wrote.
>
> Thanks, I do what I can! :-)
> Which, as far as I can tell, does not include coming up with any advice
> significantly different from that which he's already chosen to ignore.

What, that I forgot about something?  Is there something in particular
I'm ignoring?

-Morten

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

#72570

On 10/12/2015 12:06 AM, Morten W. Petersen wrote:
> On 12.10.2015 06:01, James Kuyper wrote:
>> On 10/11/2015 09:55 PM, Geoff wrote:
>> ...
>>> There, you see Morton? You can always count on someone raising some
>>> niggling point about something completely unhelpful to solving the
>>> problem raised by the OP and correcting what someone else wrote.
>>
>> Thanks, I do what I can! :-)
>> Which, as far as I can tell, does not include coming up with any advice
>> significantly different from that which he's already chosen to ignore.
> 
> What, that I forgot about something?

If you can ask the following question, then you must have forgotten
something.

>  Is there something in particular
> I'm ignoring?

My first message in this thread was a response to one by Geoff repeating
a bunch of advice he and others had previously given you, that you were,
at that point, still ignoring. As far as I can see, you never responded
to that message, so I presume that advice is still being ignored. If
not, a message thanking him for the advice would be appropriate.
-- 
James Kuyper

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

#72573

On 12.10.2015 06:48, James Kuyper wrote:
> On 10/12/2015 12:06 AM, Morten W. Petersen wrote:
[...]
>>
>> What, that I forgot about something?
>
> If you can ask the following question, then you must have forgotten
> something.
>
>>   Is there something in particular
>> I'm ignoring?
>
> My first message in this thread was a response to one by Geoff repeating
> a bunch of advice he and others had previously given you, that you were,
> at that point, still ignoring. As far as I can see, you never responded
> to that message, so I presume that advice is still being ignored. If
> not, a message thanking him for the advice would be appropriate.

OK.  Well I responded to the buffer size for the macros, and had decided
way back to do something about those macros as well it but it slipped.

As for the thread where the attitude was mentioned, I don't like
a negative attitude and would rather not get any suggestions if
they come with negativity as well.

As for saying thanks, I like to say thanks for food etc. that's good,
what we have here are many discussions and an exchange where things go
back and forth, and I don't find myself saying thanks or wow I learned
something fantastic unless it feels like it warrants it.

Maybe you can setup some rules, keep score etc. and so on if this
is important to you?

-Morten

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

#72548

James Kuyper <jameskuyper@verizon.net> writes:
> On 10/11/2015 07:15 PM, Geoff wrote:
> ...
>> Or more simply use:
>>     printf("Error not handled in function: %s \n", __FUNCTION__,
>> __FILE__); 
>> 
>> This is C90 compliant and consistent with your project. You can
>> annotate this with a comment that you're coming back to it later.
>
> Unlike __FILE__, __FUNCTION__ is not one the identifiers that the C
> standard requires an implementation to pre#define, nor is it an
> identifier that the user has permission to define, not in any context.
> __func__ was added in C99, is that what you were thinking of? If
> __FUNCTION__ is a compiler-specific extension to C, you should identify
> at least one of the compilers that supports it.

__FUNCTION__ is a gcc extension, equivalent to __func__.  The gcc
documention mentions that older versions of gcc recognize __FUNCTION__
but not __func__, but recommends using __func__.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#72525

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.

     And he's still using his bloated, unnecessary, silly buffers.

     I give up.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#72526

On 12.10.2015 00:14, Eric Sosman wrote:
[...]
>      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.
>
>      And he's still using his bloated, unnecessary, silly buffers.
>
>      I give up.

Yes, why don't you take your negative attitude that ruins the fun
and go somewhere else?

-Morten

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

#72545

On 10/11/2015 06:20 PM, Morten W. Petersen wrote:
> On 12.10.2015 00:14, Eric Sosman wrote:
> [...]
>>      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.
>>
>>      And he's still using his bloated, unnecessary, silly buffers.
>>
>>      I give up.
> 
> Yes, why don't you take your negative attitude that ruins the fun
> and go somewhere else?

Tracking down this SIGSEGV has been fun? I didn't get that impression.
-- 
James Kuyper

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

#72549

On 12.10.2015 03:07, James Kuyper wrote:
> On 10/11/2015 06:20 PM, Morten W. Petersen wrote:
>> On 12.10.2015 00:14, Eric Sosman wrote:
>> [...]
>>>       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.
>>>
>>>       And he's still using his bloated, unnecessary, silly buffers.
>>>
>>>       I give up.
>>
>> Yes, why don't you take your negative attitude that ruins the fun
>> and go somewhere else?
>
> Tracking down this SIGSEGV has been fun? I didn't get that impression.

Well I learned a bit more, had to get to know gdb better, took my
time and enjoyed it.

As for the buffer and SIGSEGV bit, I learned that variables that
are in conditionals use up space, which is something I didn't know,
and that's cool to know.

But it raises some questions about stack smashing; I remember a
previous discussion about stack smashing, recursion, unpredictable
results and security..

In practice this shows that it is possible to smash the stack and
most of the time that will probably result in a SIGSEGV like it did
now on Linux..  Using gdb was pointless, so I'm wondering what the
approach is to track down these errors except track down allocations
and keeping tabs on stack manually.

-Morten

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

#72578

On Mon, 12 Oct 2015 03:59:49 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>In practice this shows that it is possible to smash the stack and
>most of the time that will probably result in a SIGSEGV like it did
>now on Linux..  Using gdb was pointless, so I'm wondering what the
>approach is to track down these errors except track down allocations
>and keeping tabs on stack manually.

Probing the call stack in the debugger would have shown how far your
program got before it crashed. I don't have gdb on the Mac so I can't
tell you. Xcode's debugger posted a diagnostic from within the startup
before invoking main. Experience led me to your buffers.

The approach is to not define huge buffers arbitrarily under the
assumption that you are making things safer. Memory management in C
tends to involve more fiddling work than in other languages. The
malloc family of functions are the tools and they must be used while
understanding those tools can be used to lop off your appendages. 

Example:

Here's your create_xml_element function as you wrote it, slightly
reformatted.

struct xml_element* create_xml_element() {
  struct xml_element* my_struct =
	(struct xml_element*)malloc(sizeof(struct xml_element));
	my_struct->type = 0; /* 0 means initialized, 3 means complete */
	my_struct->next = NULL;
	my_struct->parent = NULL;
	my_struct->previous = NULL;
	my_struct->name = NULL;
	my_struct->attributes = NULL;
	my_struct->child = NULL;
	return my_struct;
}

Consider what can happen if malloc fails... my_parser == NULL.
attempting to continue will cause immediate segmentation fault.

To fix this you must write the function to only initialize the
structure if the allocation was successful and return NULL if it
wasn't. Then, at the caller's level, test the return value before
accessing the structure.

Thus:

struct xml_element* create_xml_element() {
	struct xml_element* my_struct =
		(struct xml_element*)malloc(sizeof(struct xml_element));
	if (my_struct)
	{
		/* 0 means initialized, 3 means complete */
		my_struct->type = 0; 
		my_struct->next = NULL;
		my_struct->parent = NULL;
		my_struct->previous = NULL;
		my_struct->name = NULL;
		my_struct->attributes = NULL;
		my_struct->child = NULL;
	}
	return my_struct;
}

Calling convention:
  ...
  void *current = create_xml_element();
  if(!current){
	printf("Failure: create_xml_element returned NULL\n");
    exit(1); /* or do something else to handle error */
  }
  ...

In this way your library passes the fault back up the chain of command
to the caller, allowing the user of the library to see the nature of
the fault and to take appropriate action.

I'm looking forward to seeing you get over the hump on your SEGV
problem and getting into testing the design of your library rather
than pulling in all these other issues and techniques that are only
creating more problems than they solve.

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.

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

#72584

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.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web