Old source code dereferencing non-pointer

Hi all

I have some really old code for a PIC16 microprocessor, compiler not 100% known but it might be ccs, that in a couple of parts does the following:

Code:

---

int16 p_16;
int8 eeadr=73; //70..73
int8 i;
p_16=&variable;    // variable is of type int32
for (i=1;i<=4;++i)
{
  *p_16=read_eeprom (eeadr);
    p_16++;
    eeadr--;
}

---

I know this isn't legal C but bear in mind that the source code initially was case insensitive so...

My question is, does anybody see any potential that this can cause issues with an ever growing stack etc. Or any other issues (apart from not correct C)? int16 is NOT typedefed/defined to a pointer type, it is used as a value type in other parts of the same source file.

The microcontroller is reset every now and then, because of (what we hear) stability issues, and we are trying to find out what can cause that, and this snippet of code stood out.

Anybody has any tips/leads/something/anything?

Are there any known compilers where a p_ prefix to variables will cause the variable to actually be a pointer (thus the code is a non-issue)?

int16, int8, etc... appear to be data types in C#, not C or C++. I know nothing about C#, and don't ever want to. You should ask about these questions n the C# forum.

Code:

---

int16 p_16;
int8 eeadr=73; //70..73
int8 i;
p_16=&variable;    // variable is of type int32

---

Shouldn't the first line be int16 *p_16;?

You'll also need to post the code for read_eeprom().

Quote:

---

I know this isn't legal C but bear in mind that the source code initially was case insensitive so...

---

Why do you think this is not legal C? If the intxx types are properly defined it should be legal, other than the pointer issue.

You really should post the smallest possible complete program that illustrates the problem.

Jim

Quote:

---

Originally Posted by rstanley

int16, int8, etc... appear to be data types in C#, not C or C++. I know nothing about C#, and don't ever want to. You should ask about these questions n the C# forum.

---

Quote:

---

Originally Posted by jimblumberg

[code]

Why do you think this is not legal C? If the intxx types are properly defined it should be legal, other than the pointer issue.

You really should post the smallest possible complete program that illustrates the problem.

Jim

---

My bet is int16 and int8, ect. are all typedefs for fixed width integers. This would be C (and not c# Stanley), and they should be defined in a header file the OP has. e.g. something like typdef __int16 int16.

Quote:

---

Originally Posted by AndrewHunter

My bet is int16 and int8, ect. are all typedefs for fixed width integers. This would be C (and not c# Stanley), and they should be defined in a header file the OP has. e.g. something like typdef __int16 int16.

---

I believe they are predefined in C# as equivalent to the standard types. Yes, they also could be defined as typedefs in some unknown C header file.

Yes they are predefined in C#, my post was more pointing to the OP did in fact post to the correct forum and his code is C code not C#.

You should also post the complete part number of the device in question.

Since memory layout in many of those devices are straightforward, it's not unusual to see direct manipulation of memory locations - although care must be taken when doing so. And honestly, it's usually not necessary. The sample you posted contains more hoo-doo than is absolutely necessary.

As I said, this is NOT modern C, this is NOT legal C, it IS C, int8 and int16 are VALUE types, they are NOT defined/typedefed as pointer types anywhere, they are used as value types in other parts of the source code. The source code was initially case insensitive, a variable named Var and one named var was the treated as the same. This should give you some indication on what kind of voodoo they somehow managed to force through a compiler.

I will come back with exact part number tomorrow, but as I said, I am more interested in if anybody has experience with this kind of voodoo and forcing this through a compiler somehow, and if this can in the long run cause problems with for instance the stack etc.

Quote:

---

Originally Posted by AndrewHunter

My bet is int16 and int8, ect. are all typedefs for fixed width integers. This would be C (and not c# Stanley), and they should be defined in a header file the OP has. e.g. something like typdef __int16 int16.

---

Quote:

---

Originally Posted by Shakti

As I said, this is NOT modern C, this is NOT legal C, it IS C, int8 and int16 are VALUE types, they are NOT defined/typedefed as pointer types anywhere, they are used as value types in other parts of the source code.

---

I did not say they were pointers, I said they were fixed width integer types that were most likely typedefs. Most microcontrollers come with header files and libraries so the C compiler can produce the appropriate output. This really has nothing to do with standard C or not. I am not sure of how else the types are used since you did not provide any additional information. However, if they are some old school controller Fixed Width Value Type than the code could look something like this:

Code:

---

int main(void)
{
       
        typedef char int_8[1];

        int_8 num1;
        int num2 = 10;

        *num1 = num2;

        printf("Number is: %d", *num1);
       
        return 0;
}

---

In fact based on this line of code:

Code:

---

p_16=&variable;

---

I would say they are defined something like I showed above.

Quote:

---

Originally Posted by jimblumberg

Code:

---

int16 p_16;
int8 eeadr=73; //70..73
int8 i;
p_16=&variable;    // variable is of type int32

---

Shouldn't the first line be int16 *p_16;?

You'll also need to post the code for read_eeprom().


Why do you think this is not legal C? If the intxx types are properly defined it should be legal, other than the pointer issue.

You really should post the smallest possible complete program that illustrates the problem.

Jim

---

I agree that it should be "int16 *p_16;"; but if the address bus is 16 bit it would often work without the star on many cpu and MCU.
Not sure if this is true for "Harvard architecture" used by many PICs. Harvard architecture - Wikipedia, the free encyclopedia

Tim S.

The exact PIC model is PIC18F4520 (sorry, thought it was a PIC16 but that was wrong when I double checked).

AndrewHunter: The problem with that approach is when the same typedef is used like this

Code:

---

int16 daytimer=8640;

---

The exact PIC model is PIC18F4520 (sorry, thought it was a PIC16 but that was wrong when I double checked).

AndrewHunter: The problem with that approach is when the same typedef is used like this

Code:

---

int16 daytimer=8640;

---

Ok well I found some documentation here. Also I missed this last time:

Code:

---

int16 p_16; //16 bit number

int8 eeadr=73; //70..73
int8 i;

//put the address of variable into the 16 it number. Treat it like a pointer
p_16=&variable; 


for (i=1;i<=4;++i)
{
  //treat p_16 as a pointer
    *p_16=read_eeprom (eeadr);
    p_16++;
   
    eeadr--;
}

---

So for a non ansi compiler with 0 type checking, this could conceivably work. as Stathta01 pointed out, assuming a 16 bit address bus, which the doc says it could be, then the star wouldn't be needed.