Seg fault even though address space is accessible

[Ajay]

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

[user923005]

On Jul 29, 2:52*pm, Ajay <[e-mail]:

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
776 * * * * * * * * * * vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 *checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
#1 *0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
* * peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 *0x080522c1 in main (argc=11, argv=0x8047348)
* * at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

Maybe an alignment problem.
Did you try the GNU groups?
http://www.nabble.com/Gnu---gdb-f1618.html
news:gnu.gdb.bug

[Ajay]

On Jul 29, 6:01*pm, user923005 <[e-mail]:

On Jul 29, 2:52*pm, Ajay <[e-mail]:

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
776 * * * * * * * * * * vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 *checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
#1 *0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
* * peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 *0x080522c1 in main (argc=11, argv=0x8047348)
* * at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

Maybe an alignment problem.
Did you try the GNU groups?http://www.nabble.com/Gnu---gdb-f1618.html
news:gnu.gdb.bug

Hmmm! I haven't, Let me try that.
But, how can I find if its an alignment problem?

However, I checked the address space which are function parameters.
And it appears it is aligned. :(

-Ajay.

[Ben Bacarisse]

Ajay <aj***********@gmail.comwrites:

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

The usual advice is to post code. Ideally code you have cut right
down but which still exhibits the problem. Doing this often isolates
the issue anyway, but without code to see it is tough...

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

To me, this does not show anything interesting. The fault is with
'vector' not 'BFVecList' which is the only thing that has the value
0x84187a0 (as far as I can see). Did you miss out the 'print vector'
output showing it to be equal to 'BFVecList'? Why not just try to
print vector->nextVector rather than using some mysterious (to me)
address?

--
Ben.

[Richard Heathfield]

Ajay said:

Hi All,

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

There's a guy around here somewhere who can debug your problem (no matter
what it is) using only the debugger. Impressive. But if by some strange
chance he doesn't have time to answer your question, you'll have to rely
on the rest of us, and I'm afraid we tend to need to see the source code.

Without it, the most I can suggest is that you may have violated the bounds
of your array. The fact that gdb lets you look at an address outside the
array doesn't mean anything with regard to your program's correctness.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Jens Thoms Toerring]

Ajay <aj***********@gmail.comwrote:

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

Wich is rather useless without seeing the code. Without it the
gdb output is mostly meaningless.

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
776 vector = vector->nextVector;

What value has 'vector here? Did you check that it's an
address you can legally use as a pointer? Without seeing
your code there's nothing that indicates that 'vector'
has anything to do with the address 0x84187a0.

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
at compute_sticky_IP_per_ASN.c:776
#1 0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 0x080522c1 in main (argc=11, argv=0x8047348)
at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector

I don't understand what you're doing here. Doing

p ((bitfieldItemStruct *) 0x84187a0)->nextVector
p ((struct bitfieldItem *) 0x84187a0)->nextVector

looks suspicious. Note that you use the same address in
both cases, just casting it to a different type - or is
it the same? If yes, why do you think it's relevant to
check the same thing twice?

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Ajay]

Hi All,

Thanks for all your replays.

I am posting the code here.
typedef struct bitfieldItem {
uint32_t BFVector;
const struct bitfieldItem *nextVector;
} bitfieldItemStruct, *bitfieldItemStructPtr;

main()
{
***
buildBFVectorList(currPeerDetailItem->bitfieldStr,
&(currPeerDetailItem->bitfieldVector));
checkBFVectorList(currPeerDetailItem->bitfieldVector,
currPeerDetailItem->bitfieldLength);

***

}
int checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int
BFlen)
{
bitfieldItemStruct *vector = *BFVecList;
float numVectors = ceil((float)BFlen/32.0);
float vector_id = 0;
printf ("Verifying BF vector\n");
printf ("BFlen = %d, numvectors = %f\n", BFlen, numVectors);
printf ("The BF vector is: ");
while (vector != NULL)
{
printf ("%d ", vector->BFVector);
vector = vector->nextVector;
vector_id++;
}
printf ("\nvector_id = %d\n", vector_id);
assert (vector_id == numVectors);
return 1;
}

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));
BFVecHead->BFVector = 0;
BFVecHead->nextVector = NULL;
currBFVec = BFVecHead;
num_vectors = 1;
printf ("Before %u\n", BFVecHead->BFVector);

while (bit != NULL)
{
if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
if (num_bits_pushed >= 32) {
printf ("\nAfter %u\n", currBFVec->BFVector);
if (tmpBFVec = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *)) == NULL) {
printf ("Memory reallocation failed for object of type
'bitfieldItemStruct*'.\n");
exit(-1);
}
tmpBFVec->BFVector= 0;
tmpBFVec->nextVector = NULL;
currBFVec->nextVector = tmpBFVec;
currBFVec = tmpBFVec;
num_bits_pushed = 0;
num_vectors++;
printf ("Before %u\n", currBFVec->BFVector);
}

currBFVec->BFVector = currBFVec->BFVector << 1;
printf ("%u", atoi(bit));
currBFVec->BFVector += atoi(bit);
num_bits_pushed++;
total_num_bits_pushed++;
bit = (char *) strtok(NULL, ",");
}
printf ("\nAfter %u\n", currBFVec->BFVector);
*BFVecList = BFVecHead;
printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
return 1;
}

On Jul 29, 6:18*pm, Ben Bacarisse <[e-mail]:

Ajay <[e-mail]:

I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

The usual advice is to post code. *Ideally code you have cut right
down but which still exhibits the problem. *Doing this often isolates
the issue anyway, but without code to see it is tough...

However if I am able successfully access the structure using the
address from the gdb output
after it seg faulted. Output from gdb also give below.

Any idea y this is happening?
yes I am trying to access the structure element from where it seg
faulted.

I am surely missing something.
Any help is appreciated!

Thanks,
Ajay.

$$$$$$$$$$$$$ SEG FAULT $$$$$$$$$$$$$$$$$

Program received signal SIGSEGV, Segmentation fault.
checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
776 * * * * * * * * * * vector = vector->nextVector;

$$$$$$$$$$$$$$$$ BT $$$$$$$$$$$$$$$$$$$$

(gdb) bt
#0 *checkBFVectorList (BFVecList=0x84187a0, BFlen=699)
* * at compute_sticky_IP_per_ASN.c:776
#1 *0x08051bb3 in buildPeerDetailStructFromLine (line=0x8418dd0 "566",
* * peerStruct=0x8047124) at compute_sticky_IP_per_ASN.c:752
#2 *0x080522c1 in main (argc=11, argv=0x8047348)
* * at compute_sticky_IP_per_ASN.c:179

$$$$$$$$$$$$$$$$$$$$ ACCESSING STRUCTURE $$$$$$$$$$$$$$$$$$$

(gdb) p *(bitfieldItemStruct *) 0x84187a0
$1 = {BFVector = 3309413121, nextVector = 0x84187b0}
(gdb) p ((bitfieldItemStruct *) 0x84187a0)->nextVector
$2 = (struct bitfieldItem *) 0x84187b0
(gdb) p ((struct bitfieldItem *) 0x84187a0)->nextVector
$3 = (struct bitfieldItem *) 0x84187b0

To me, this does not show anything interesting. *The fault is with
'vector' not 'BFVecList' which is the only thing that has the value
0x84187a0 (as far as I can see). *Did you miss out the 'print vector'
output showing it to be equal to 'BFVecList'? *Why not just try to
print vector->nextVector rather than using some mysterious (to me)
address?

--
Ben.

[Ben Bacarisse]

Ajay <aj***********@gmail.comwrites:

I am posting the code here.

Makes all the difference... BTW, top-posting is not in favour in the
group.

typedef struct bitfieldItem {
uint32_t BFVector;
const struct bitfieldItem *nextVector;
} bitfieldItemStruct, *bitfieldItemStructPtr;

<snip>

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));

This is wrong. There is no need for calloc (you set the memory
immediately), the cast is unnecessary, and you don't check the result.
However, the reason things go really wrong is the size is not right.

The comp.lang.c approved method is to write:

BFVecHead = malloc(sizeof *BFVecHead);

This way you can see the size is right (provided the type of the
pointer is correct) and you will get an error message if you have
forgotten to include stdlib.h.

BFVecHead->BFVector = 0;
BFVecHead->nextVector = NULL;
currBFVec = BFVecHead;
num_vectors = 1;
printf ("Before %u\n", BFVecHead->BFVector);

while (bit != NULL)
{
if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
if (num_bits_pushed >= 32) {
printf ("\nAfter %u\n", currBFVec->BFVector);
if (tmpBFVec = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *)) == NULL) {

Ditto.

printf ("Memory reallocation failed for object of type
'bitfieldItemStruct*'.\n");
exit(-1);
}
tmpBFVec->BFVector= 0;
tmpBFVec->nextVector = NULL;
currBFVec->nextVector = tmpBFVec;
currBFVec = tmpBFVec;
num_bits_pushed = 0;
num_vectors++;
printf ("Before %u\n", currBFVec->BFVector);
}

currBFVec->BFVector = currBFVec->BFVector << 1;
printf ("%u", atoi(bit));
currBFVec->BFVector += atoi(bit);
num_bits_pushed++;
total_num_bits_pushed++;
bit = (char *) strtok(NULL, ",");
}
printf ("\nAfter %u\n", currBFVec->BFVector);
*BFVecList = BFVecHead;
printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
return 1;
}

--
Ben.

[Ajay]

On Jul 29, 7:25*pm, Ben Bacarisse <[e-mail]:

Ajay <[e-mail]:

I am posting the code here.

Makes all the difference... *BTW, top-posting is not in favour in the
group.

typedef struct bitfieldItem {
* * uint32_t * *BFVector;
* * const struct bitfieldItem *nextVector;
} bitfieldItemStruct, *bitfieldItemStructPtr;

<snip>

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
* * bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
* * char * bit;
* * unsigned int num_bits_pushed = 0;
* * unsigned int total_num_bits_pushed = 0;
* * unsigned int num_vectors = 0;

* * if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
* * bit = (char *) strtok(BFStr, ",");
* * BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));

This is wrong. *There is no need for calloc (you set the memory
immediately), the cast is unnecessary, and you don't check the result.
However, the reason things go really wrong is the size is not right.

The comp.lang.c approved method is to write:

* * BFVecHead = malloc(sizeof *BFVecHead);

This way you can see the size is right (provided the type of the
pointer is correct) and you will get an error message if you have
forgotten to include stdlib.h.

* * BFVecHead->BFVector = 0;
* * BFVecHead->nextVector = NULL;
* * currBFVec = BFVecHead;
* * num_vectors = 1;
* * printf ("Before %u\n", BFVecHead->BFVector);

* * while (bit != NULL)
* * {
* * * * if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
* * * * if (num_bits_pushed >= 32) {
* * * * * * printf ("\nAfter %u\n", currBFVec->BFVector);
* * * * * * if (tmpBFVec = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *)) == NULL) {

Ditto.

* * * * * * * * printf ("Memory reallocation failed forobject of type
'bitfieldItemStruct*'.\n");
* * * * * * * * exit(-1);
* * * * * * }
* * * * * * tmpBFVec->BFVector= 0;
* * * * * * tmpBFVec->nextVector = NULL;
* * * * * * currBFVec->nextVector = tmpBFVec;
* * * * * * currBFVec = tmpBFVec;
* * * * * * num_bits_pushed = 0;
* * * * * * num_vectors++;
* * * * * * printf ("Before %u\n", currBFVec->BFVector);
* * * * }

* * * * currBFVec->BFVector = currBFVec->BFVector << 1;
* * * * printf ("%u", atoi(bit));
* * * * currBFVec->BFVector += atoi(bit);
* * * * num_bits_pushed++;
* * * * total_num_bits_pushed++;
* * * * bit = (char *) strtok(NULL, ",");
* * }
* * printf ("\nAfter %u\n", currBFVec->BFVector);
* * *BFVecList = BFVecHead;
* * printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
* * return 1;
}

--
Ben.

Hi Ben,

Thanks for your replay!
I was using malloc but after the error appeared, I tried using calloc.
I changed back the code to using malloc.
The Seg. fault error still persists.
The new code is posted below:

Thanks,
Ajay.

int
checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int BFlen)
{
bitfieldItemStruct *vector = *BFVecList;
float numVectors = ceil((float)BFlen/32.0);
float vector_id = 0;
printf ("Verifying BF vector\n");
printf ("BFlen = %d, numvectors = %f\n", BFlen, numVectors);
printf ("The BF vector is: ");
while (vector != NULL)
{
/* if (vector->BFVector != NULL) printf ("%u ", vector-

>BFVector);

else { printf ("Error occured\n"); exit(-1); } */
/* printf ("%d ", vector->BFVector);*/
vector = vector->nextVector;
vector_id++;
}
printf ("\nvector_id = %d\n", vector_id);
assert (vector_id == numVectors);
return 1;
}

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)
{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
char * bit;
unsigned int num_bits_pushed = 0;
unsigned int total_num_bits_pushed = 0;
unsigned int num_vectors = 0;

if (verboseLevel >= 7) printf ("The BF string is %s\n", BFStr);
bit = (char *) strtok(BFStr, ",");
BFVecHead = malloc(sizeof(*BFVecHead));
if (BFVecHead == NULL) {
perror("Error: Memory could not be allocated:");
exit(-1);
}
BFVecHead->BFVector = 0;
BFVecHead->nextVector = NULL;
currBFVec = BFVecHead;
num_vectors = 1;
printf ("Before %u\n", BFVecHead->BFVector);

while (bit != NULL)
{
if (verboseLevel >= 9) printf ("%d: Current bit is %s\n",
total_num_bits_pushed+1, bit);
if (num_bits_pushed >= 32) {
printf ("\nAfter %u\n", currBFVec->BFVector);
tmpBFVec = malloc(sizeof(*tmpBFVec));
if (tmpBFVec == NULL) {
perror("Error: Memory could not be allocated:");
exit(-1);
}
tmpBFVec->BFVector= 0;
tmpBFVec->nextVector = NULL;
currBFVec->nextVector = tmpBFVec;
currBFVec = tmpBFVec;
num_bits_pushed = 0;
num_vectors++;
printf ("Before %u\n", currBFVec->BFVector);
}

currBFVec->BFVector = currBFVec->BFVector << 1;
printf ("%u", atoi(bit));
currBFVec->BFVector += atoi(bit);
num_bits_pushed++;
total_num_bits_pushed++;
bit = (char *) strtok(NULL, ",");
}
printf ("\nAfter %u\n", currBFVec->BFVector);
*BFVecList = BFVecHead;
printf ("The total number of bits in the BFvector is %d and num
vectors is %d.\n", total_num_bits_pushed, num_vectors);
return 1;
}

[Ike Naar]

In article <5e**********************************@d1g2000hsg.g ooglegroups.com>,
Ajay <aj***********@gmail.comwrote:

>{
bitfieldItemStruct *BFVecHead, *currBFVec, *tmpBFVec;
[snip]
BFVecHead = (bitfieldItemStruct *) calloc(1,
sizeof(bitfieldItemStruct *));

This looks suspicious.
You allocate room for one pointer instead of room for one struct.
Also, the cast is unnecessary.

Regards,
Ike

[Ben Bacarisse]

Ajay <aj***********@gmail.comwrites:

Thanks for your replay!
I was using malloc but after the error appeared, I tried using calloc.
I changed back the code to using malloc.
The Seg. fault error still persists.
The new code is posted below:

Are you sure you are posting code you have compiled?

int
checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int BFlen)

int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)

elsewhere you posted:

| main()
| {
| ***
| buildBFVectorList(currPeerDetailItem->bitfieldStr,
| &(currPeerDetailItem->bitfieldVector));
| checkBFVectorList(currPeerDetailItem->bitfieldVector,
| currPeerDetailItem->bitfieldLength);
|
| ***
|
| }

The types here do not match up -- the compiler should reject it.

--
Ben.

[Ajay]

On Jul 29, 8:22*pm, Ben Bacarisse <[e-mail]:

Ajay <[e-mail]:

Thanks for your replay!
I was using malloc but after the error appeared, I tried using calloc.
I changed back the code to using malloc.
The Seg. fault error still persists.
The new code is posted below:

Are you sure you are posting code you have compiled?

int
checkBFVectorList(bitfieldItemStruct **BFVecList, unsigned int BFlen)
int
buildBFVectorList(char *BFStr, bitfieldItemStruct **BFVecList)

elsewhere you posted:

| main()
| {
| * ****
| *buildBFVectorList(currPeerDetailItem->bitfieldStr,
| &(currPeerDetailItem->bitfieldVector));
| *checkBFVectorList(currPeerDetailItem->bitfieldVector,
| currPeerDetailItem->bitfieldLength);
|
| ****
|
| }

The types here do not match up -- the compiler should reject it.

--
Ben.

Yes, you are right. The compiler did gave warning which I did not
notice.

Thanks a lot!
-Ajay.

[Martin Ambuhl]

Ajay wrote:

I am posting the code here.

What you posted isn't anywhere close to compilable.
I started trying to turn this mess into something that I could address,
but gave up.
That means it cannot possibly exhibit the problem you claim.
Please try again, and actually try compiling it and checking to see if
it exhibits the problem before posting.

[Antoninus Twink]

On 29 Jul 2008 at 22:29, Richard Heathfield wrote:

Ajay said:

>I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

There's a guy around here somewhere who can debug your problem (no matter
what it is) using only the debugger. Impressive. But if by some strange
chance he doesn't have time to answer your question, you'll have to rely
on the rest of us, and I'm afraid we tend to need to see the source code.

Yes Heathfield, very amusing, how we all admire your cleverness and wit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

[Richard]

Antoninus Twink <no****@nospam.invalidwrites:

On 29 Jul 2008 at 22:29, Richard Heathfield wrote:

>Ajay said:

>>I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

There's a guy around here somewhere who can debug your problem (no matter
what it is) using only the debugger. Impressive. But if by some strange
chance he doesn't have time to answer your question, you'll have to rely
on the rest of us, and I'm afraid we tend to need to see the source code.

Yes Heathfield, very amusing, how we all admire your cleverness and
wit.

He really is an arrogant twit.

>
Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and

Exactly.

many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

Me too. Now cue one of his sycophantic friends to quote Kernighan or
somesuch telling us how much more difficult it is to debug a system than to
program it correctly the first time. Sigh.

[Flash Gordon]

Richard wrote, On 30/07/08 19:18:

Antoninus Twink <no****@nospam.invalidwrites:

>On 29 Jul 2008 at 22:29, Richard Heathfield wrote:

>>Ajay said:
I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

<snip>

>many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

Me too. Now cue one of his sycophantic friends to quote Kernighan or
somesuch telling us how much more difficult it is to debug a system than to
program it correctly the first time. Sigh.

Obviously the person who managed to identify the bugs from just a couple
of snippets in this thread really managed to get hold of the entire
source without the rest of us seeing it.
--
Flash Gordon
Yes, I know, I should not reply to trolls.

[Richard]

Flash Gordon <sp**@flash-gordon.me.ukwrites:

Richard wrote, On 30/07/08 19:18:

>Antoninus Twink <no****@nospam.invalidwrites:

>>On 29 Jul 2008 at 22:29, Richard Heathfield wrote:
Ajay said:
I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

<snip>

>>many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger. I call bullshit on that.

Me too. Now cue one of his sycophantic friends to quote Kernighan or
somesuch telling us how much more difficult it is to debug a system than to
program it correctly the first time. Sigh.

Obviously the person who managed to identify the bugs from just a
couple of snippets in this thread really managed to get hold of the
entire source without the rest of us seeing it.

I'm not sure what your point is. This is usenet. The code needed was
small. It in no way invalidates the benefits a debugger brings. Or in
this case paying attention to compiler warnings. of course some people
pulled the "can't compile it so cant help" line. others read the
code. Which was not insurmountable since it was about 20 lines.

[Chris Dollin]

Antoninus Twink wrote:

On 29 Jul 2008 at 22:29, Richard Heathfield wrote:

>Ajay said:

>>I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

There's a guy around here somewhere who can debug your problem (no matter
what it is) using only the debugger. Impressive. But if by some strange
chance he doesn't have time to answer your question, you'll have to rely
on the rest of us, and I'm afraid we tend to need to see the source code.

Yes Heathfield, very amusing, how we all admire your cleverness and wit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard Heathfield]

Chris Dollin said:

Antoninus Twink wrote:

>On 29 Jul 2008 at 22:29, Richard Heathfield wrote:

>>Ajay said:
I got a segmentation fault while accessing a structure element.
I pasted the output from gdb and the backtrace.

There's a guy around here somewhere who can debug your problem (no
matter what it is) using only the debugger. Impressive. But if by some
strange chance he doesn't have time to answer your question, you'll
have to rely on the rest of us, and I'm afraid we tend to need to see
the source code.

Yes Heathfield, very amusing, how we all admire your cleverness and wit.

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

Well, he can't, Chris, can he? The best he can do is quote himself or some
other troll pretending that I made such a claim.

Incidentally, I find it very strange that the trolls have no objection to
extending other people's positions, but don't like their own positions to
be extended.

Yes, I did extend the position held by one of the trolls that the debugger
is an essential tool - I forget whether it's Twink or Noname - to the
position that it *suffices* in all cases, and source code is never
required, which I think we can all agree is an untenable proposition. Of
course, this would have been dishonest, had I not pointed out what I had
done in that very same article.

Conclusions:

(1) our resident trolls either can't or won't read an entire article for
comprehension;
(2) they don't like being trolled;
(3) they can't grasp simple facts;
(4) they can't reason very well.

It's just as well I have them killfiled, really, or I'd waste huge amounts
of time arguing with them. I know they don't believe I've killfiled them,
but that's just another demonstration of (3).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Chris Dollin <ch**********@hp.comwrites:

Antoninus Twink wrote:

[more of the same]

Cite three instances that fit this claim.

Chris, why on Earth would you ask a troll to post *more* crap?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Dollin]

Keith Thompson wrote:

Chris Dollin <ch**********@hp.comwrites:

>Antoninus Twink wrote:

[more of the same]

>Cite three instances that fit this claim.

Chris, why on Earth would you ask a troll to post *more* crap?

Paranoid terror that some poor sod will believe their
hysterically extreme claims.

(Additional evidence suggests I'm on a downer at the moment.)

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[CBFalconer]

Chris Dollin wrote:

Antoninus Twink wrote:

.... snip ...

>

>Fact is, *noone* has claimed to be able to debug code using only
a debugger and not seeing the source code. *You* on the other
hand (and many of your lackeys and lickspittles) have claimed on
many occasions that you can debug any problem using only a
printout of the source code and never a debugger.

Cite three instances that fit this claim.

Well, answering the twinkletroll is pointless. However, many have
performed this awesome feat of legerdomain and successfully patched
the object code. It does require understanding machine code. It
may also require understanding the structure of the loadable code
module.

Admittedly, it is somewhat harder than reading source.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ajay]

On Jul 31, 9:58*am, CBFalconer <[e-mail]:

Chris Dollin wrote:

Antoninus Twink wrote:

... snip ...

Fact is, *noone* has claimed to be able to debug code using only
a debugger and not seeing the source code. *You* on the other
hand (and many of your lackeys and lickspittles) have claimed on
many occasions that you can debug any problem using only a
printout of the source code and never a debugger.

Cite three instances that fit this claim.

Well, answering the twinkletroll is pointless. *However, many have
performed this awesome feat of legerdomain and successfully patched
the object code. *It does require understanding machine code. *It
may also require understanding the structure of the loadable code
module.

Admittedly, it is somewhat harder than reading source.

--
*[mail]: Chuck F (cbfalconer at maineline dot net)
*[page]: <http://cbfalconer.home.att.net>
* * * * * * Try the download section.

Thanks for all your replays and time.
The Seg fault is now resolved. Just a summary.

I was making two big blunders.
1. I was passing pointer to a structure instead of pointer to pointer
of a structure.
2. I was allocating memory to a pointer to structure instead of
structure.

They just creeped in due to my 'lazy programming'.

I am posting gcc compiled code.
Since I was using strict compiler options (including -ansi -pedantic)
and throwing out all the warnings.
So I was ignoring the argument mis-match warnings along with other
warnings.

I haven't figured out what are best compiler options yet.
But I can make sure next time that I go thru the list warning msgs.

Thanks,
Ajay.

[31349 83652]

Ajay wrote:

I haven't figured out what are best compiler options yet.

I can't help you there (and the options may change for
each translation unit), but maybe you'd like to try
gcc -Werror ...

-Werror
Make all warnings into errors.

:P

[Antoninus Twink]

On 31 Jul 2008 at 6:45, Chris Dollin wrote:

Antoninus Twink wrote:

>Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

Happily. In fact, here are five.

Malcolm Maclean, <Xq******************************@bt.com>

My view on this is that the debugger creates a very intimate
relationship with the programmer. When I first learnt C I used one.
The run / debug cycle becomes a natural way of working. Then In my
first job I got a Unix box and suddenly the debugger was taken away.
Then I got another one for a games console, but it wasn't well
designed. I decided at that point that even a good debugger was too
seductive. So now I use diagnostics almost exclusively.

Bartc, <MP******************@text.news.virginmedia.com>

I've never used debuggers either, for either hardware or software.
Tracking down an elusive bug is more like a sport; a proper debugger
would spoil the fun.

Ian Collins, <63*************@mid.individual.net>

As I've said here before, spend some time (at least a year) working in
a language without a debugger, you will very quickly adapt to life
without it.

Ed Prochik,
<50**********************************@e39g2000hsf. googlegroups.com>

>1500-2000 lines is the maximum the brain can handle.

So then keep you code size below that limit and you will not need the
debugger.

And the Prince Of Lies himself, Richard Heath Field,
<mq******************************@bt.com>

I have certainly debugged what you consider to be impossibly large
code bases without using a debugger.

>nobody believes this "I can debug without a debugger" stuff.

...except those who've done it, of course, which seems to be most of
us.

Once again, I call bullshit on Heathfield's claims to be a superhero.

We've all seen Heathfield spew out lie after lie to undermine Jacob and
try to destroy his reputation. It's no surprise that he tries to blacken
the "trolls" who've got the measure of him with the same sort of slurs.

Heathfield is a liar, morning, noon and night.

[Nick Keighley]

On 1 Aug, 00:54, Antoninus Twink <[e-mail]:

On 31 Jul 2008 at *6:45, Chris Dollin wrote:

Antoninus Twink wrote:

Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

Happily. In fact, here are five.

the key sentence in your quote is:

"You [Richard Heathfield] [...] have claimed on many occasions that
you can
debug any problem using ONLY a printout of the source code and NEVER
a
debugger"

I do not believe my elision or change in emphasis has distorted
what you say. The original is still available above.

1. RCH never said he nver used a debugger
2. none of the quotes below claim to only use a printout.
Many use diagnostics.

So you have made two untrue statements. Since you have done
this repeatedly this makes you a liar.

>
Malcolm Maclean, <[e-mail]>

My view on this is that the debugger creates a very intimate
relationship with the programmer. When I first learnt C I used one.
The run / debug cycle becomes a natural way of working. *Then In my
first job I got a Unix box and suddenly the debugger was taken away.
Then I got another one for a games console, but it wasn't well
designed. I decided at that point that even a good debugger was too
seductive. So now I use diagnostics almost exclusively.

Bartc, <MPDCj.23573$[e-mail]>

I've never used debuggers either, for either hardware or software.
Tracking down an elusive bug is more like a sport; a proper debugger
would spoil the fun.

Ian Collins, <[e-mail]>

As I've said here before, spend some time (at least a year) working in
a language without a debugger, you will very quickly adapt to life
without it.

Ed Prochik,
<[e-mail]>

1500-2000 lines is the maximum the brain can handle.

So then keep you code size below that limit and you will not need the
debugger.

And the Prince Of Lies himself, Richard Heath Field,
<[e-mail]>

I have certainly debugged what you consider to be impossibly large
code bases without using a debugger.

nobody believes this "I can debug without a debugger" stuff.

...except those who've done it, of course, which seems to be most of
us.

Once again, I call bullshit on Heathfield's claims to be a superhero.

We've all seen Heathfield spew out lie after lie to undermine Jacob and
try to destroy his reputation. It's no surprise that he tries to blacken
the "trolls" who've got the measure of him with the same sort of slurs.

Heathfield is a liar, morning, noon and night.

--
Nick Keighley

"Anyone attempting to generate random numbers by deterministic
means is, of course, living in a state of sin."
-- John Von Neumann

[Richard Heathfield]

[Sadly, this seems to be one of those times when snippage is likely to be
misinterpreted. Hence, no snippage.]

Nick Keighley said:

On 1 Aug, 00:54, Antoninus Twink <[e-mail]:

>On 31 Jul 2008 at 6:45, Chris Dollin wrote:

Antoninus Twink wrote:

>Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source
code and never a debugger.

Cite three instances that fit this claim.

Happily. In fact, here are five.

In fact, none of the five quotes fit the claim.

the key sentence in your quote is:

"You [Richard Heathfield] [...] have claimed on many occasions that
you can
debug any problem using ONLY a printout of the source code and NEVER
a
debugger"

I do not believe my elision or change in emphasis has distorted
what you say. The original is still available above.

And I have left it in place.

1. RCH never said he nver used a debugger

Right. It is my first port of call if a program segfaults, because it's the
fastest way to find out (assuming I don't already know!) where the symptom
is manifested. Often, from there it's pretty obvious what's gone wrong.
Furthermore, I used to make heavy use of debuggers. I didn't stop because
I became a "superhero" (as if!). I stopped because I found faster, more
effective ways to debug. That doesn't mean I *won't* use a debugger. I'm
perfectly prepared to do that if I think it worthwhile - and, on occasion,
it is; just not very often, that's all.

2. none of the quotes below claim to only use a printout.
Many use diagnostics.

None of the quotes below claim to use *even* a printout. I certainly
haven't said that I use printouts. I used to, yes - I suppose many of us
did, and perhaps some still do. But again, there are faster ways to debug
than to wait for the code base to meet the dead tree.

So you have made two untrue statements. Since you have done
this repeatedly this makes you a liar.

I'm not actually sure that he's a liar. I think he's just stupid. But of
course I could be wrong about that. Why do I think he's stupid? Well, he
can't read with understanding, he doesn't appear to comprehend the
futility of micro-optimisation, he doesn't understand the purpose of a
newsgroup for discussing C despite having been told many times, and he
doesn't have the ability to deal rationally with opposing arguments,
instead resorting to invective and mockery. But perhaps you're right -
maybe he's a liar too.

>Malcolm Maclean, <[e-mail]>

My view on this is that the debugger creates a very intimate
relationship with the programmer. When I first learnt C I used one.
The run / debug cycle becomes a natural way of working. Then In my
first job I got a Unix box and suddenly the debugger was taken away.
Then I got another one for a games console, but it wasn't well
designed. I decided at that point that even a good debugger was too
seductive. So now I use diagnostics almost exclusively.

No mention of printouts here.

>>
Bartc, <MPDCj.23573$[e-mail]>

I've never used debuggers either, for either hardware or software.
Tracking down an elusive bug is more like a sport; a proper debugger
would spoil the fun.

No mention of printouts here.

>>
Ian Collins, <[e-mail]>

As I've said here before, spend some time (at least a year) working in
a language without a debugger, you will very quickly adapt to life
without it.

No mention of printouts here.

>>
Ed Prochik,
<[e-mail]>

>1500-2000 lines is the maximum the brain can handle.

So then keep you code size below that limit and you will not need the
debugger.

No mention of printouts here.

>>
And the Prince Of Lies himself, Richard Heath Field,

A nice demonstration of begging the question (in the proper sense), and of
the inability to get people's names right. The above error is one he has
made before, and he was called on it then, so he has demonstrated, too,
that he has learning difficulties. (I strongly suspect that he can't even
get his own name right. Maybe he really is called Antoninus Twink, but
somehow I doubt it.)

><[e-mail]>

I have certainly debugged what you consider to be impossibly large
code bases without using a debugger.

>nobody believes this "I can debug without a debugger" stuff.

...except those who've done it, of course, which seems to be most of
us.

No mention of printouts here.

>>
Once again, I call bullshit on Heathfield's

Ah! Look at that! He *can* get my name right - if he tries!

>claims to be a superhero.

I have never claimed to be a superhero, and Mr Twink's apparent belief that
I have done so merely highlights the fact that he lives in some kind of
fantasy world. I don't (mostly) ignore debuggers because of any great
claim of skill - I ignore them because they're not the most effective way
for me to solve most of my debugging problems. That's common sense, not
superheroism.

>We've all seen Heathfield

And again!

>spew out lie after lie to undermine Jacob and
try to destroy his reputation.

Mr Twink seems to be making the mistake of believing his own propaganda. I
am not trying to undermine Jacob Navia or to destroy his reputation. He is
perfectly capable of doing that all by himself. I do, however,
occasionally point out errors in his articles, and it is true that I have
sometimes asked him to stop plugging his product in comp.lang.c, since it
is a technical group about the C language, not a commercial group about
implementations.

>It's no surprise that he tries to blacken
the "trolls" who've got the measure of him with the same sort of slurs.

People who can't understand what they read are bound to jump to false
conclusions on occasion, but Mr Twink seems to jump from one false
conclusion to another with the agility of a mountain goat.

>Heathfield

Well, he managed to get my name right three times out of four. I suppose I
should be grateful for small mercies.

>is a liar, morning, noon and night.

At least that leaves my afternoons free.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Ajay wrote:

>

.... snip ...

>
I haven't figured out what are best compiler options yet. But
I can make sure next time that I go thru the list warning msgs.

One line, probably wrapped, below:

*gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal
-gstabs+ -ftrapv

(you may want to replace ansi with std=c99)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 01 Aug 2008 09:52:54 -0400, CBFalconer wrote:

Ajay wrote:

>I haven't figured out what are best compiler options yet. But I can
make sure next time that I go thru the list warning msgs.

One line, probably wrapped, below:

*gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal -gstabs+
-ftrapv

(you may want to replace ansi with std=c99)

Why do you want to use -ansi if you're going to include another option
that deliberately makes the compiler fail to conform to any standard?

[CBFalconer]

Harald van D?k wrote:

CBFalconer wrote:

>Ajay wrote:

>>I haven't figured out what are best compiler options yet. But
I can make sure next time that I go thru the list warning msgs.

One line, probably wrapped, below:

*gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal
-gstabs+ -ftrapv

(you may want to replace ansi with std=c99)

Why do you want to use -ansi if you're going to include another
option that deliberately makes the compiler fail to conform to
any standard?

And what do you consider does that? A warning does not prevent
compilation.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

Harald van D?k wrote:

>CBFalconer wrote:

>>Ajay wrote:

I haven't figured out what are best compiler options yet. But
I can make sure next time that I go thru the list warning msgs.

One line, probably wrapped, below:

*gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal
-gstabs+ -ftrapv

(you may want to replace ansi with std=c99)

Why do you want to use -ansi if you're going to include another
option that deliberately makes the compiler fail to conform to
any standard?

And what do you consider does that? A warning does not prevent
compilation.

Consider the following:

void f(const char (*cp)[4]);

void g(void)
{
f(&"abc");
}

It requires a diagnostic which -Wwrite-strings suppresses.

--
Ben.

[CBFalconer]

Ben Bacarisse wrote:

CBFalconer <cb********@yahoo.comwrites:

>Harald van D?k wrote:

.... snip ...

>>>
Why do you want to use -ansi if you're going to include another
option that deliberately makes the compiler fail to conform to
any standard?

And what do you consider does that? A warning does not prevent
compilation.

Consider the following:

void f(const char (*cp)[4]);

void g(void) { f(&"abc"); } /* modified cf */

It requires a diagnostic which -Wwrite-strings suppresses.

I don't see that. Are you confused about the meaning of
-Wwrite-strings? It effectively declares every constant string as
being const, preventing writing back to it without a warning.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 01 Aug 2008 22:59:14 -0400, CBFalconer wrote:

Ben Bacarisse wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Harald van D?k wrote:

... snip ...

>>>>
Why do you want to use -ansi if you're going to include another
option that deliberately makes the compiler fail to conform to any
standard?

And what do you consider does that? A warning does not prevent
compilation.

Consider the following:

void f(const char (*cp)[4]);

void g(void) { f(&"abc"); } /* modified cf */

It requires a diagnostic which -Wwrite-strings suppresses.

I don't see that. Are you confused about the meaning of
-Wwrite-strings?

He's not.

The type of "abc" according to the standard is char[4], not const char[4].
And the type of &"abc" is char(*)[4], not const char(*)[4]. There is no
implicit conversion from char(*)[4] to const char(*)[4], so Ben's code
violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will accept
the code, but it will emit a very misleading diagnostic strongly
suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code with
your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is never
called, yet gcc will issue a hard error for it with your options. At least
you won't find this one outside of a conformance test though.

[CBFalconer]

Harald van D?k wrote:

>

.... snip ...

>
The type of "abc" according to the standard is char[4], not const
char[4]. And the type of &"abc" is char(*)[4], not const char(*)[4].
There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will
accept the code, but it will emit a very misleading diagnostic
strongly suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code
with your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is
never called, yet gcc will issue a hard error for it with your
options. At least you won't find this one outside of a conformance
test though.

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&', and
which triggers nothing:

#include <stdio.h>
void f(const char *cp) {puts(cp);}

void g(void) {f("abc");}

int main (void) {g(); return 0;}

Admittedly, the option can cause misleading diagnostics, but the
code still compiles. What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

Harald van D?k wrote:

<snip>

>There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint.

<snip>

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&',

I don't see how that alters the argument. If a set of options make a
compiler non-conforming, then re-writing the code does not make it
conforming.

With the code I posted, the options you suggest make gcc
non-conforming and you can't just re-write the parameter type and the
call to eliminate "the confusing &" without making the code quite
different.

Admittedly, the option can cause misleading diagnostics, but the
code still compiles.

And, in one case, fails to produce a required diagnostic.

What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

Yes, it is a useful option but it is more useful if you know those
cases where it makes gcc non-conforming.

--
Ben.

[Richard]

CBFalconer <cb********@yahoo.comwrites:

Harald van D?k wrote:

>>

... snip ...

>>
The type of "abc" according to the standard is char[4], not const
char[4]. And the type of &"abc" is char(*)[4], not const char(*)[4].
There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will
accept the code, but it will emit a very misleading diagnostic
strongly suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code
with your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is
never called, yet gcc will issue a hard error for it with your
options. At least you won't find this one outside of a conformance
test though.

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&', and

And now the illustrious Chuck, having been schooled in gcc command line
options, proceeds to tell us how others will write their code!

Only in c.l.c

Reading a few Heathfield and Chuckster threads on a hot summer's evening
leaves me puffing from laughter! The arrogance! The egos! Wonderful
entertainment.

And for real C schooling one can read the rest.

which triggers nothing:

#include <stdio.h>
void f(const char *cp) {puts(cp);}

void g(void) {f("abc");}

int main (void) {g(); return 0;}

Admittedly, the option can cause misleading diagnostics, but the
code still compiles. What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

--

[Chris Dollin]

Antoninus Twink wrote:

On 31 Jul 2008 at 6:45, Chris Dollin wrote:

>Antoninus Twink wrote:

>>Fact is, *noone* has claimed to be able to debug code using only a
debugger and not seeing the source code. *You* on the other hand (and
many of your lackeys and lickspittles) have claimed on many occasions
that you can debug any problem using only a printout of the source code
and never a debugger.

Cite three instances that fit this claim.

Happily. In fact, here are five.

As Richard Heathfield observes elsethread, not one of your examples
fits the claim you made. Such transparent failure is its own reward.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England