> On Mar 26, 2015, at 17:26 , Joel Sherrill wrote:
>
>> 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
On 03/26/2015 04:12 PM, Peter Dufault wrote:
On Mar 23, 2015, at 16:23 , Sebastian Huber
wrote:
- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@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 mad
> On Mar 23, 2015, at 16:23 , Sebastian Huber
> wrote:
>
>
>
> - Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@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
El 25/03/2015 21:41, "Joel Sherrill" escribió:
>
>
>
> On March 24, 2015 8:37:57 AM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >In order to avoid code duplication and ease future bugfixing, I suggest
> >to have a conditional casting and leave the core code alone, something
On March 24, 2015 8:37:57 AM CDT, Daniel Gutson
wrote:
>In order to avoid code duplication and ease future bugfixing, I suggest
>to have a conditional casting and leave the core code alone, something
>like
>
>#ifdef __rtems__
>#define cast(x) ((unsigned long int)x)
>#else
>#define cast(x) (x)
>
In order to avoid code duplication and ease future bugfixing, I suggest to
have a conditional casting and leave the core code alone, something like
#ifdef __rtems__
#define cast(x) ((unsigned long int)x)
#else
#define cast(x) (x)
#endif
...cast(final[ 0] << 16)...
#undef cast
El 23/03/2015 11:52
On 23/03/15 16:51, Gedare Bloom wrote:
I guess this is a problem for 16-bit targets? changing the constants
to 16UL and 8UL also should work.
No, this doesn't work. The type of the << X variable is irrelevant.
A comment should be made that this
is only for 16-bit targets. If we rid RTEMS o
On March 23, 2015 3:23:59 PM CDT, Sebastian Huber
wrote:
>
>
>- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@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-b
- Am 23. Mrz 2015 um 16:51 schrieb Gedare Bloom ged...@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 th
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...
On Mon, Mar 23, 2015 at 10:39 AM, Joel Sherrill
wrote:
> -
---
cpukit/libcrypt/crypt-md5.c | 12
1 file changed, 12 insertions(+)
diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c
index c60dcf8..78ae0bc 100644
--- a/cpukit/libcrypt/crypt-md5.c
+++ b/cpukit/libcrypt/crypt-md5.c
@@ -133,6 +133,17 @@ crypt_md5_r(const char
11 matches
Mail list logo
