This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

About pointer to a huge table in C

Hi,

I am a bit confused about writing codes with a poitner pointed to a huge table in C with Keil compiler (for C166 MCU).

First if i want to define a pointer pointed to a huge table, naturally i would do:

int huge (*ptable)[256];

However the complier does not allow to write in this way. The only way to pass the compiling is:

int (huge *ptable)[256];

The codes seem to work like this. But i am not really sure if i defined the pointer in a correct way, Can someone confirm me about it?

Second question about type cast. If i want to convert something into a pointer, I found i can do both type casts:

long addr;
int (huge *ptable)[256];

ptable = (int huge (*)[256])(&addr);
ptable = (int (huge *)[256])(&addr);

Both of the 2 lines above seem to work. But i am confused why the complier allows to define a point only in 1 way but allows type cast in 2 different ways? Does anyone knows the story under the hood?

Thanks for the help.

Regards,
Xiang

Parents
  • ok, by saying "naturally" i meant my understanding to the keyword "huge", not about how to define a pointer. Because the (*ptable) is already a pointer, defining in the way like "int huge (*ptable)[x]" is more logicall to me, compare to "int (huge *ptable)[x]".

    The thread is asking about how to use the huge keyword in combine with defining and type casting a pointer to an array type variables. Now about how should someone use a pointer.

    And i do really want a pointer to an exact size of array, such that the compiler can make a double check, when the memory size is not correctly allocated.

    your way

    int huge *ptable;
    


    define only a pointer to an int type, which can ofc work with array, but it is not what i want.

Reply
  • ok, by saying "naturally" i meant my understanding to the keyword "huge", not about how to define a pointer. Because the (*ptable) is already a pointer, defining in the way like "int huge (*ptable)[x]" is more logicall to me, compare to "int (huge *ptable)[x]".

    The thread is asking about how to use the huge keyword in combine with defining and type casting a pointer to an array type variables. Now about how should someone use a pointer.

    And i do really want a pointer to an exact size of array, such that the compiler can make a double check, when the memory size is not correctly allocated.

    your way

    int huge *ptable;
    


    define only a pointer to an int type, which can ofc work with array, but it is not what i want.

Children
  • Sorry, I didn't realize that one could declare a pointer to an array with specified size. Is this a feature introduced in C99? Note that C166 does not claim C99 compliance.
    The behavior of the compiler does look odd. As for verifying if the declared pointer is really a pointer to huge int, you can look at disassembly of data accesses with this pointer.
    Besides, huge is a compiler-specific language extension. It doesn't necessarily behave the same way the normal type qualifiers do. Which is a shame, really.

  • Is this a feature introduced in C99?

    I know keil c166 compiler only supports C90 but not C99. But i don't have those standards (no time to study and no money to buy), although i'd really like to spend some time to understand the C standrads.

    From the draft of C99 from this link: www.open-std.org/.../n1256.pdf
    It mentioned the use of pointer to a table, like in page 122:

    3 EXAMPLE:
    (d) int (*)[3]
    (d) pointer to an array of three ints
    

    I cannot find C90 texts anywhere. But the Keil compiler does support this feature. So i guess it is already included in C90.

    Normally i prefer to use a pointer to a table when there is a need to pass a table as a function parameter. This reminds me and other people to be careful to use correct memory objects when calling sth like:

    extern void func(int (*conversion_table)[10]);
    int table_to_send[10];
    
    func(&table_to_send);
    

    In fact the Keil compiler doesn't check the table size, it passes the compiling if doing:

    extern void func(int (*conversion_table)[10]);
    int table_to_send[9];
    
    func(&table_to_send);
    

    So the way I am doing is more like just a note for myself to send right table when calling a function.

    About the huge (and far/xhuge) keyword, I just checked with assembly codes that it works in this way to define a pointer to a huge table:

    int (huge *ptable)[10];
    

  • Sorry, I didn't realize that one could declare a pointer to an array with specified size.

    Then, with all due respect, I suggest you take the time to revisit your C textbooks' chapters' on pointers.

    Is this a feature introduced in C99?

    Not at all. It's been like that for as long as C exists.

    A more easily mangeable way of defining an object like this, avoiding the possible misunderstandings of pointer-to-array vs. array-of-pointers as nice side effect, is this:

    typedef huge bigarray[SIZE];
    
    bigarray *pointer_to_big_array;
    

    The rationale behind this is that if you define a pointer to any even moderately complicated type, it's quite certain that you're going to do other things with that same type. So save yourself the hassle of getting the type's definition right multiple times, in different places all over the source: typedef it once and for all!

  • Then, with all due respect, I suggest you take the time to revisit your C textbooks' chapters' on pointers.

    Thank you, I just did. Apparently, I wasn't paying enough attention when reading it the first time. Pointers to arrays are discussed briefly in K&R in connection with multidimensional arrays and function arguments. I guess it's my turn to eat the humble pie.
    In relation to the original poster's intention, it appears that pointers to arrays are not designed to facilitate out-of-bounds checking. Moreover, it appears that they can only be useful when working with multidimensional arrays.

  • In relation to the original poster's intention, it appears that pointers to arrays are not designed to facilitate out-of-bounds checking. Moreover, it appears that they can only be useful when working with multidimensional arrays.

    Both those appearances are incorrect.