[PATCH] score: Change _Heap_Extend() API

[Gedare Bloom]

On Fri, Aug 10, 2012 at 9:26 AM, Joel Sherrill <joel.sherrill at oarcorp.com>wrote:

> On 08/10/2012 03:59 AM, Sebastian Huber wrote:
>
>> On 08/09/2012 05:50 PM, Joel Sherrill wrote:
>>
>>> Sorry to keep pestering but we ended up with a deliberately unused
>>> parameter. Does that give a warning?
>>>
>> With the standard warning flags "-Wall -Wmissing-prototypes
>> -Wimplicit-function-**declaration -Wstrict-prototypes -Wnested-externs"
>> I get no
>> error.
>>
>>  Do we need to use the gcc pragma to note it is unused? I know in the
>>> test code, there is a conditional defined for this. It may have to move
>>> into the core like the memory barrier and other compiler specific macros
>>>
>> There are a lot of __attribute__((unused)) scattered around the code.
>>
>> We should think about using something similar to the FreeBSD cdefs.h file.
>> They do a lot to cope with compiler dependencies, e.g.
>>
>> #if __GNUC_PREREQ__(2, 7)
>> #define __dead2         __attribute__((__noreturn__))
>> #define __pure2         __attribute__((__const__))
>> #define __unused        __attribute__((__unused__))
>> #define __used          __attribute__((__used__))
>> #define __packed        __attribute__((__packed__))
>> #define __aligned(x)    __attribute__((__aligned__(x))**)
>> #define __section(x)    __attribute__((__section__(x))**)
>> #endif
>>
>> This is a lot shorter than the RTEMS_ATTRIBUTE_XXX.
>>
>>  It is shorter. I question better because the BSD names already
> are duplicated in newlib. With the libbsd work, I have noticed
> that the conflicts/duplications for sys/cdefs.h are popping up
> again. If we use the same names a third time, this is just going
> to be worse.
>
> I would prefer something like this over inserting compiler
builtins/attributes directly.


> If we can unify all this, it may be OK.  But sys/cdefs.h definitions
> have proven to be a thorn over the past years.
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&   Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available             (256) 722-9985
>
>
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120810/4b811f06/attachment-0001.html>