[PATCH 12/42] libcrypt/crypt-md5.c: Fix overflow issues

[Joel Sherrill]

On 03/26/2015 04:12 PM, Peter Dufault wrote:
>> On Mar 23, 2015, at 16:23 , Sebastian Huber<sebastian.huber at embedded-brains.de>  wrote:
>>
>>
>>
>> ----- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom gedare at gwu.edu:
>>
>>> I guess this is a problem for 16-bit targets? changing the constants
>>> to 16UL and 8UL also should work. A comment should be made that this
>>> is only for 16-bit targets. If we rid RTEMS of those, we can get rid
>>> of some of these shenanigans...
>> It would be interesting to know if we have at least one real application running RTEMS on a 16-bit target.  Apart from warning fixes I don't see any activity in this area.
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> Late answer, I'm catching up on old e-mails.
>
> I think if 16 bit Harvard architecture (64K instruction / 64K data) targets are no longer supportable then 16 bit should be deprecated and then abandoned.  If you can still do a lot with RTEMS in 128K then that useful subset of the code should be identified and kept 16 bit clean, that would be a good requirement on developers and that part of the code base.

> That is, if anyone wants to do that, I currently use 4MB instruction / 4MB data as my minimal targets that can be comfortably extended during the support life time (I want TCP/IP and NFS as part of my minimum, your mileage will definitely vary).
>
The original target platform for RTEMS was 1MB RAM that was used for 
everything.
I still think this is a very reasonable memory profile for most 
applications.

I am not sure if the 64K instruction/data is that useful but 16-bit 
architectures are
not necessarily limited to 64K address spaces. We all remember the 8086 and
variants. The m32c has 24 bit address space.

I don't know the requirements for what I used to frequently call 
Tiny/RTEMS.
If you have a 20+ bit address space, then there isn't much of a code 
size issue.
There will be combinations of code that just won't fit. I expect the new 
TCP/IP
stack to be a casualty there. But the old TCP/IP stack worked quite well in
a 1MB environment and I would expect LWIP to do even better.

So my focus is just on being 16-bit integer clean. I don't think we will 
shrink
into the smallest AVR CPU models but something like an 8086 in large memory
model or an m32c shouldn't be an issue for most of RTEMS.

But yes.. we should have some insight into which features are hopeless in
a 16-bit integer environment and maybe some idea of what is really too 
small.
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


-- 
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available