Jarmo Paavilainen wrote:
>
> Hi,
>
> ...
> > > Wrong forum but Im a newbie in Linux and this is a Linux
> ...
> > linux-gcc is the correct list for such problems.
>
> Okey... where can I find it?
Same place as the newbie list (vger). You can subscribe that list the
same way you subscribed to newbie list (send a message to
[EMAIL PROTECTED] with subscribe linux-gcc in the body (double
check this)).
>
> > I can't see anything wrong in this code, but more info may help. Is
> > 'pek' destroyed at the first iteration, or is it destroyed after the
>
> Im not sure when it is destroid. But I do know that if a match is found then
> "pek" is preserved.
>
Then the code portion which is executing when no match is found may have
some error. There is nothing unusual in this code to make me think that
the source of the problem is gcc.
> > first ? Also, this code assumes that tList.Append makes a new copy of
> > the object it is appending, is it so?
>
> Actually Append(...) is creating a class (Node) that has a member of type
> sDNS (a struct), somthing like this:
>
> typedef struct tagDNS{ .... } sDNS, psDNS;
>
> Append( const sDNS& s )
> {
> psDNS pHolder; pHolder = new sDNS;
> *pHolder = s;
> }
>
> And nothing should matter..."pek" should never ever be changed anyway.
It may. If you have dangling pointers pointing to random places, or some
buffers in stack which may overflow, 'pek' may change.
This Append does not append anything by the way, it just creates a
memory object, and forgets it. I still believe that Append is the source
of your problem (may be the part which actually modifies tList).
I also assume that getXXX methods do not have any side effects. If they
have, getXXX calls may cause some problems too.
>
> Im using g++ not gcc. But arent they the same.
>
> ...
> > > The code looks something like this:
> > >
> > > ///////////////////////////////////////
> > > //
> > > const char *pek;
> > > for( loopIP = IPList.GetFirstNode(); loopIP; loopIP =
> > loopIP->GetNext())
> > > {
> > > if( bMajor ) pek =
> rchr(
> > loopIP->GetHolder().strDNS, '.' );
> > > else pek = strchr( loopIP->GetHolder().strDNS, '.' );
> > > if( !pek ) pek = " <N/A> ";
> > >
> > > fprintf( stderr, "1) pek = \"%s\"\n", pek ); // ** Still ok here **
> > >
> > > for( loopDNS = tList.GetFirstNode(); loopDNS; loopDNS =
> > > loopDNS->GetNext())
> > > {
> > > if( strcmp( pek,
> > loopDNS->GetHolder().strDNS ) == 0 ) break;
> > > else fprintf( stderr, "2) pek =
> > \"%s\"\n", pek ); // ** NOT here **
> > > }
> > >
> > > fprintf( stderr, "3) pek = \"%s\"\n", pek ); // If point 2 was
> > executed then
> > > pek is fucked up here
> > >
> > > if( loopDNS ) loopDNS->GetPointer()->iCount +=
> > loopIP->GetHolder().iCount;
> > > else
> > > {
> > > sDNS sTemp;
> > > if( strlen( pek ) < sizeof( sTemp.strDNS ) - 1)
> > > {
> > > fprintf( stderr, "4) pek = \"%s\"\n", pek ); // If point 2 was
> > executed then
> > > pek is still bad
> > > strcpy( sTemp.strDNS, pek );
> > > sTemp.iCount =
> > loopIP->GetHolder().iCount;
> > > tList.Append( sTemp );
> > > fprintf( stderr, "5) pek = \"%s\"\n", pek ); // Pek is the same
> > here as it
> > > was at point 1, but the bad data is allready copied to sTemp.strDNS
> > > }
> > > else fprintf( stderr, "** ERROR **
> > Overflow detected." );
> > > }
> > > }
> > >
> > > //
> > > ///////////////////////////////////////
> > >
> > > It seems that "pek" is moved by strcmp(...) to point at bogus
> > data if the
> > > strings are not the same. But after a few commands the compiler
> > restores the
> > > value. Maybe strcmp(...) does not restore all registers at
> > exit. And after a
> > > while the compiler desides to restore them instead.
> > >
> > > Or Im I doing something wrong?
> > >
> > > // Jarmo
> >
