Global type checking errors

  • Friedrich Lobenstock

    Hi Richard!

    When I don't disable "Global type checking" in the TASKING compiler I do get
    the following errors when building:

    E163: ["..\FreeRTOS_Source\queue.c" 1171/24] "uxQueueMessagesWaiting" redeclared with a different type
    I459: ["..\FreeRTOS_Source\include/queue.h" 796/24] previous declaration of "uxQueueMessagesWaiting"
    E163: ["..\FreeRTOS_Source\queue.c" 1614/7] "vQueueAddToRegistry" redeclared with a different type
    I459: ["..\FreeRTOS_Source\include/queue.h" 1283/7] previous declaration of "vQueueAddToRegistry"
    E163: ["..\FreeRTOS_Source\include/queue.h" 1293/6] "vQueueWaitForMessageRestricted" redeclared with a different type
    I459: ["..\FreeRTOS_Source\queue.c" 1660/7] previous declaration of "vQueueWaitForMessageRestricted"
    E163: ["..\FreeRTOS_Source\queue.c" 555/15] "xQueueCreateCountingSemaphore" redeclared with a different type
    I459: ["..\FreeRTOS_Source\include/queue.h" 1244/14] previous declaration of "xQueueCreateCountingSemaphore"
    E163: ["..\FreeRTOS_Source\queue.c" 324/14] "xQueueGenericCreate" redeclared with a different type
    I459: ["..\FreeRTOS_Source\include/queue.h" 1290/14] previous declaration of "xQueueGenericCreate"
    E163: ["..\FreeRTOS_Source\include/queue.h" 1103/22] "xQueueGenericSendFromISR" redeclared with a different type
    I459: ["..\FreeRTOS_Source\queue.c" 906/22] previous declaration of "xQueueGenericSendFromISR"
    E163: ["..\FreeRTOS_Source\queue.c" 466/16] "xQueueGiveMutexRecursive" redeclared with a different type
    I459: ["..\FreeRTOS_Source\include/queue.h" 1252/15] previous declaration of "xQueueGiveMutexRecursive"

    To treat the following error

    E163: ["..\FreeRTOS_Source\portable\....\port.c" 102/35] "pxCurrentTCB" redeclared with a different type
    I459: ["..\FreeRTOS_Source\tasks.c" 111/35] previous declaration of "pxCurrentTCB"

    I've already submitted a patch.

    Now to the problems in queue.c:

    I think in queue.c, e.g., the "typedef xQUEUE * xQueueHandle;" should be
    renamed "typedef xQUEUE * xKernelQueueHandle;".

    Then queue.c can safely include queue.h and the queue handle can then be
    treated as follows, using uxQueueMessagesWaiting( ) as example:

    unsigned portBASE_TYPE uxQueueMessagesWaiting( const xQueueHandle pxQueue )
    unsigned portBASE_TYPE uxReturn;
        configASSERT( pxQueue );
            uxReturn = ((xKernelQueueHandle *)pxQueue)->uxMessagesWaiting;
        return uxReturn;

    And functions returning a queue handle should be treated as follows:

    xKernelQueueHandle xReturn = NULL;
        return (xQueueHandle)xReturn;

    What do you think?


  • Richard

    Richard - 2013-02-11

    With regards to the TCB patch, that's a no go I'm afraid.  I have updated the patch with the reason.  Not to say that a solution that avoids the warnings could not be used.

    Regards your queue suggestion. I was just looking at how this is done now.  The other alternative would be to just use (xQUEUE *) directly in the queue.c file without the additional typedef.  Either way, having the ability to include queue.h in queue.c would definitely be a bonus so there is definitely merit.  I am currently contemplating this one…


  • Friedrich Lobenstock

    Hi Richard!

    With regards to the TCB patch, that's a no go I'm afraid. I have
    updated the patch with the reason. Not to say that a solution that
    avoids the warnings could not be used.

    Did your really look at the patch? The definition of TCB is
    "protected" by the definition of TASK_INCLUDED_FROM_KERNEL_FILE?

    See a text version of the patch for viewing in the browser:


    And of course supported ports would only be allowed to de-reference
    the stackpointers which are referenced in the TCB. It's up to you
    to allow only such ports. And per default the definition of the TCB
    is not available in the portlayer if TASK_INCLUDED_FROM_KERNEL_FILE
    is not defined in port.c.

    BTW I'm referening to stackpointers - plural - because I'm currently
    working on a dual stack port with the addional stack added to the
    TCB and using the generalised stack checking functions.


  • Richard

    Richard - 2013-02-12

    I only looked at the patch in a text file and didn't notice that.  I will look again, but it probably won't be for a few hours yet as I want to ensure the code I have now is checked in first.


  • Richard

    Richard - 2013-02-12

    I have updated queue.c to make it consistent with task.c.  Now the handle is void* everywhere, queue.h is included in queue.c and local xQUEUE * pointers are used in the API functions as necessary (as tskTCB * pointers are in the task API functions). 

    Task.c used to use the same scheme as queue.c (two different task handle definitions) but was evidently updated without queue following on.  Agreed it is much better like this.

    Please grab the latest from SVN and make sure it is ok for your compiler.


  • Friedrich Lobenstock

    Dear Richard!

    I'll have to dissect your commit first to be able to reapply it onto my
    currently not mainline code.

    If I am allowed to make a wish please create one commit for everything
    that is related and another one for which is not.

    E.g., for every line in your last log message:

    Added more files to the Rowley and IAR LM3S demos to test building the newer files and queue sets.
    Made queue function prototypes consistent so xQueueHandle parameters are always xQueue, and xQUEUE * parameters pxQueue.
    Likewise make the task API using px for pointers to TCBs, and just x for task handles.
    Heap_x functions now automatically align the start of the heap without using the portDOUBLE union member.
    Queue.c now includes queue.h.

    It would be much easier to see which changes relate to the line saying
    "Queue.c now includes queue.h.", if the related changes would have been
    one commit and the other lines a commit of their own.

    I know old habits die hard, but please at least consider it. It might make life
    at little easier for distributed development.

    Thanks for your time and your support.

    Best regards

  • Friedrich Lobenstock

    Regarding changes to queue.c and queue.h, I can say job well done, all type checking errors are gone.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks