On Thu, 13 Dec 2007, Nuno Lucas wrote:
> Explaining a bit more what I had mean, you are doing an 8-bit shift on
> a char. Some compilers will first convert the value to int and then do
> the shift, while others will apply the shift to the 8-bit value
> (meaning the result will always be 0).
>
> I
Pedro,
A while ago you got the arm-unknown naming scheme accepted. We have not
implemented it yet though.
What would be the best way to proceed with this ? Do you know if any of
the GNU tools imported this into their sources ?
I would guess not but your never know.
If we proceed with implementi
Danny Backx wrote:
> Pedro,
>
> A while ago you got the arm-unknown naming scheme accepted. We have not
> implemented it yet though.
>
> What would be the best way to proceed with this ? Do you know if any of
> the GNU tools imported this into their sources ?
>
> I would guess not but your never
On Thu, 2007-12-13 at 22:34 +, Pedro Alves wrote:
> Danny Backx wrote:
> > Pedro,
> >
> > A while ago you got the arm-unknown naming scheme accepted. We have not
> > implemented it yet though.
> >
> > What would be the best way to proceed with this ? Do you know if any of
> > the GNU tools i
Ivan Vucica wrote:
> In that sad case, I'll leave the code as it is.
>
Now that's silly. You've been told the compiler is not
at fault here. Why don't you just do something like:
uint8_t* buffer = (uint8_t*)msg.getBuffer();
int read_post = 0;
while (read_pos < message
Danny Backx wrote:
>> [*] - In that case, please remember to use the
>> correct vanilla autoconf* versions.
>
> Where do I find which the right versions are ?
>
Before regenerating:
$head configure
$head Makefile.in
-
SF
