I still have no dea what you are trying to accomplish and what is the issue.

#include <htc.h>  // for PIC16F59
const char* Strings[]={"a1","bb22","ccc333"}; // define "jagged" array
char Buffer[10];
void FillBuffer(char* Dest,const char* Source);

main(void)
{
  FillBuffer(Buffer, Strings[0]);
  FillBuffer(Buffer, Strings[1]);
  FillBuffer(Buffer, Strings[2]);
}  

void FillBuffer(char* Dest, const char* Source)
{
  while ( (*Dest++ = *Source++) != 0); 
}

My problem is that it does not compile, simply put. Is that so hard to follow?

#include <htc.h>  // for PIC16F59
const char* Strings[]={"a1","bb22","ccc333"}; // define "jagged" array
char Buffer[10];
void FillBuffer(char* Dest,const char* Source);

main(void)
{
  FillBuffer(Buffer, Strings[0]);
  FillBuffer(Buffer, Strings[1]);
  FillBuffer(Buffer, Strings[2]);
}  

void FillBuffer(char* Dest, const char* Source)
{
  while ( (*Dest++ = *Source++) != 0); 
}

Quite interesting, one time a char[10] is passed as function parameter, which is declared as char*. Then the second parameter is const char*, and a const char* element is passed.

The first element also is a char*, right? The same in C as array, or almost.

However, I explicitely have to use the & operator (address operator). At least on the baseline.

I have no means to re-install older versions of MPLAB, different compiler, and see if eventually it can work using the older software.

 

My problem is that it does not compile, simply put. Is that so hard to follow?

Actually yes I cannot follow that. WHAT IS THIS "IT" YOU REFER TO?

What device are you attempting to use?

 

Actually yes I cannot follow that. WHAT IS THIS "IT" YOU REFER TO?

What device are you attempting to use?

"IT" here means passing the string in the form without address operator.

"IT" is the string element.

And "IT" also is the source code in general.

The 16f59 is used, and if I try to compile it, an error message is emitted.

So,

func1(alpha_chr[0])

does produce an error message.

On the 16f716 (for example), or 18F, it compiles.

Then I changed to

func1(&alpha_chr[0])

, which compiles for the 16f59.

But, what is returned is an 8bit element from the first level string table. Which I also have included via screenshot into the thread.

I figured out, I need to read the second element too, from the first level string table, and build a 16bit virtual address type pointer manually.

The code I use for that is also shown above in the thread, and it works as intended.

I don't understand which questions are open now.

Except maybe if there is an easier way to obtain a 16bit virtual address type pointer from a two-level string table system.

The compiler manual does not contain sufficient information about this topic.

 

This is how I contained the functionality now:

char* get_font_ptr(char* font)
{unsigned int addr;
 addr=*(font+1);addr<<=8;addr|=*(font);
 return(((const char*)(addr)));
}

tsize=0;
for(i=0;i<26;i++){tsize+=*get_font_ptr(&alpha_chr);}

and

curr_chr_size2=*get_font_ptr(&alpha_chr[chr_curr]);

work 100% as expected. So I consider the C code as correct and stable.

It is also now obvious to me dereferecing of pointers to pointers does not work as eventually expected the same way as for instance inside Visual Studio. Since 16bit virtual address is stored as RETLW instructions, however, only one 8bit value is obtained from the dereferencing.

Making a distinction when you want said 8bit value, and the 16bit virtual address, would mean a requirement to derive from standard C, as far as I understand it now. To some degree this was done, since you can pass the element literally, and one level of deferencing will be done. Just does not work on baseline for some unknown reason, at least not on my setup.

Previously, when I tried baseline MCUs with Hitech C/MPLAB 8.60, it was not able at all to use strings.

 

FYI: I've been doing some work with piontes in XC v1.00 and getting decent results, but when I upgraded to v1.01 things fell apart.

I caught this quote (from a super mod) on the MPLAB forum this morning:"There has been a number of pointer issues with XC8. Since these issues were in the core part of the compiler operation and were not trivial, they were not something that could be fixed quickly and easily and so they have persisted for longer than we would have liked. You will be pleased to know that quite a number of these issues, to the best of our knowledge, have been corrected and will make an appearance in the 1.10 release (don't confuse that with the 1.01 release). "

HELP IS ON THE WAY!