[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 184
  • Last Modified:

C array problems. Compiler bug? or not.

Ok, right now im working with Watcom C Version 10.0a
and ive either found some sort of bug (hope not) or
ive missed something very obvious.

The following code is what ive writen, and i'll outline the
problem after.
-----

#include <stdio.h>

int main()
{
  char string[10];

  string[0] = 0;
  printf("String[0] = %d",string[0]);

  return 0;
}

Ok, the code above ive had no problem with at all, no errors etc etc, BUT the code below buggers up BIG time! :(

#include <stdio.h>
#include <stdlib.h>

int main()
{
  char *string;

  string = (char *)malloc(10);

  // for the sake of peoples getting through the code
  // quickly, just note, i KNOW there is enough memory
  // avail. And string has never been NULL yet.

  string[0] = 0;
  printf("String[0] = %d",string[0]);

  return 0;
}

Ok, now this code prints '0' to the stdout, as it should.
BUT ive done other things with this and ended up needing to
go into WD (Watcom Debugger) and traced through the code,
the problem is this,

The first code segment included sets string[0] to 0, Perfect!, But setting the var string[0] to 0 in the second segment of code seems to cause problems!, WD is has the value of string[0] as ????

(Note: all other elements in the allocated array are set-able and work fine except the first one!, and some of my functions get very confused with the value of ???? whatever that is!, although printf STILL outputs a '0' to stdout for it.)

Also remember setting string[0] for the static array works fine, not the allocated one.

HELP!!! what is going on?!, I really need to find out how
to get past this, as i cant use static var's for what i want to do, its just an example! ;)

Thanks for your help.

Chris.
0
ccheek
Asked:
ccheek
1 Solution
 
jos010697Commented:
Are the code snippets above a verbatim copy of the code
that's giving you trouble? If so, your debugger or compiler
is broken (quite unlikely, but possible ...)

If not, could you supply a (short) snippet of code that's
actually giving you problems?

kind regards,

Jos aka jos@and.nl
0
 
terrycjCommented:
it doesn't look like it's your fault, but on the other hand, something
as basic as this should not be failing. in the meantime, you can
do something like this which may allow you to keep working
until you get a real solution:

#define my_malloc(n) (malloc((n) + 1) + 1)

then just use my_malloc instead of malloc. if it's really only
the first byte that's inaccessible, this will work fine.

terry.

0
 
meessenCommented:
I still don't understand what the problem is.
This ???? may just be a debugger problem.
There may be a printf problem, or there may be a malloc problem.
it is not possible to know with the given information.

We have first to understand where the problem is comming from.

First check if the stored value in string[0] is the expected value. Also check with explicit casting like string[0] = (char)5;
Then test if(string[0] == 5).
Check with different values and of course with 0.
After that you should be sure about the string buffer content.
If there is something here it may be the malloc function.
I think you have a tool to display memory content. Look at the location string points to to see what is stored there. make sure it is really what you expect.

If everything is ok there, then check the printf function.
This function is tricky because it uses vararg. And you pass it a char type value. You should try casting explicitely the string[0] to an int like this: printf( "string[0] = %d\n", (int)string[0] ); Strange and unexpected things may happen with printf.

If everything is ok there, check the debugger. Well there is not much to do about it then. And this should normally not confuse your functions.


0
 
rbrCommented:
I also think this could be a debugger bug. What does your debugger print out if you print instead of string[0] *string. If this is 0 all should be ok.
0
 
ccheekAuthor Commented:
Yeah, it could be a Debugger bug, although my program has problems with the very code itself anyway.

I use the following computer system, surly no flaw with the computer itself?

Pentium Pro 200 (TX chipset i believe.)
32meg RAM (EDO)

Oh well, thanks everyone that added comments etc.


0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now