[PATCH v2] tests/validation: Fix 64bit test failure

[Sebastian Huber]

On 24/02/2021 18:30, Gedare Bloom wrote:

> On Wed, Feb 24, 2021 at 9:58 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de>  wrote:
>> On 24/02/2021 17:54, Gedare Bloom wrote:
>>
>>> On Wed, Feb 24, 2021 at 2:52 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de>   wrote:
>>>> On 16/02/2021 06:51, Sebastian Huber wrote:
>>>>
>>>>> The issue can be fixed in two ways.
>>>>>
>>>>> 1. We change the API, so that the error condition can happen also on
>>>>> 64-bit architectures (current patch).
>>>>>
>>>>> 2. We change the specification and implementation, so that this error
>>>>> condition is removed on 64-bit architectures. In the implementation,
>>>>> this is easy. In the specification, this is a bit more difficult since
>>>>> I would have to introduce a new option which enables or disables parts
>>>>> of the specification based on the word size of the architecture
>>>>> (similar to RTEMS_SMP). This is the main reason why I didn't fix the
>>>>> issue immediately
>>>> How do we want to address this issue? Change the API or the
>>>> specification, etc.?
>>>>
>>> I'd lean toward 1, except without digging in the details I think the
>>> proposed patch is wrong to use size_t, and the implementation check of
>>> SIZE_MAX. We shouldn't use size_t for a counting variable, that is
>>> wrong. size_t has an implied type of number of bytes. The check should
>>> be against UINT32_MAX if the variable type is uint32_t.
>> This is exactly the problem. Internally, this uint32_t variable is used
>> to compute the allocation size in size_t, which is uint64_t on 64-bit
>> architectures and an overflow cannot happen.
>>
> These limits are ridiculous, even on a 32-bit machine no one is going
> to be allocated a 4 GiB message.
>
> We should consider specifying the API more tightly. The maximum
> message sizes are currently only constrained by the Workspace Size or
> (for Global) the MPCI message limits. Maybe we should make the
> maximum_pending_messages as uint16_t or even uint8_t, then the
> overflow can't happen on 32-bit machine either.

The message size is already size_t. The problem is the 
maximum_pending_messages. I think that limiting the maximum for the 
pending messages to 65535 would be a bit too restrictive.

I will fix the error condition in the specification and adjust the 
implementation accordingly without changing the API.

>
-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/