From: sparhawk AT eunet DOT at (Gerhard Gruber)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Strange Function Behavior
Date: Fri, 07 Aug 1998 22:08:36 GMT
Organization: EUnet Austria
Lines: 71
Message-ID: <35d34cb2.2092661@news.Austria.EU.net>
References: <6qdq5j$as2 AT nnrp2 DOT farm DOT idt DOT net>
NNTP-Posting-Host: e026.dynamic.vienna.at.eu.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Date: 7 Aug 1998 22:10:05 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Content-Transfer-Encoding: 8bit
Precedence: bulk

Destination: "Chia" <chia AT top DOT net>
From: Gruber Gerhard
Group: comp.os.msdos.djgpp
Date: Thu, 6 Aug 1998 21:54:20 -0500:

>    Then I started work on the menus, and "&File" worked. I was making the
>menu options.  These options, too, used the & symbol for the underlining.  I
>needed some way to test my menu, and I used "&Show Barquie" and "&Hide
>Barquie".
>
>    This didn't work at all.  I began to suspect the compiler was being
>screwy and I posted a message about how when I passed these strings it lost
>the & sign.
>
>    Well, I commented out code and found that in parseTitle, I found that
>the loop
>
>       for(int c = i; c < (int)strlen(name);c++) name[c] = name[c + 1];
>
>    was causing the problems.
>
>    I rewrote the function to use strcpy() and use a temporary string, then
>copy the string over, and it worked ok.
>
>    Does anyone know what was happening in the original code?  I don't
>understand why it would act that way.  I figure it was probably something
>with the name[c + 1] running over the boundaries or something, but I don't
>have any idea why this would do that.

DOS compilers usually don't have this problem, but in UNIX environments this
is a pretty common error for people that don't know about how the memory is
organized in the executables (no offense intended). I don't know if this is
the problem here, but since this port is coming from UNIX I guess that might
be the problem.

When you use static strings then they are usually placed in a seperate
segement that is write protected (I think these segments are easier to handle
on swapping but don't know the exact reason behind this). In your code you
define a static string and then you manipulate it by writing to it. This
causes the protected mode environment to issue a segmentation violation. When
you copied the string to a private arrea with strcpy you didn't use a write
protected memory as a target and that's why it works now.

When you use any kind of static data then it is always a good idea to copy it
to a writable location if you have to manipulate it.

--
Bye,
   Gerhard

email: sparhawk AT eunet DOT at
       g DOT gruber AT sis DOT co DOT at

Spelling corrections are appreciated.