On Sun, Jun 21, 2009 at 4:53 AM, David Brownell wrote:
> As I said, I won't object to such fixes. But at the same time, it's
> worth realizing that it's been quite a few years since much general
> purpose code has worked on 16-bit CPUs. Even Intel is working on
> moving away from BIOS boot code t
On Saturday 20 June 2009, Rick Altherr wrote:
> I agree that fixing all the portability issues isn't easy and isn't
> strictly necessary for any particular future release. I'd just like
> to see us progress in that direction when making fixes for data
> types. If you need to fix a printf fo
On Jun 20, 2009, at 11:05 AM, David Brownell wrote:
On Saturday 20 June 2009, Duane Ellis wrote:
I assert that is specifically *not* a goal of openocd to build
and run openocd on *HOSTS* where the host basic compiler types
"int" and "unsigned int" are *less*then* then 32bits.
True of false?
On Jun 20, 2009, at 6:16 AM, Duane Ellis wrote:
rick> For example, in your case:
duane> uint32_t x;
duane> void funny_function( uint32_t );
duane>
duane> for( x = 0 ; x < 10 ; x++ ){
duane>printf(" X = %d, Calling funny function\n", (int)(x));
duane> funny_function( x )
On Saturday 20 June 2009, Duane Ellis wrote:
> I assert that is specifically *not* a goal of openocd to build
> and run openocd on *HOSTS* where the host basic compiler types
> "int" and "unsigned int" are *less*then* then 32bits.
>
> True of false?
IMO: true.
Not that I'd object to merging p
rick> For example, in your case:
duane> uint32_t x;
duane> void funny_function( uint32_t );
duane>
duane> for( x = 0 ; x < 10 ; x++ ){
duane>printf(" X = %d, Calling funny function\n", (int)(x));
duane> funny_function( x ) ;
duane> }
rick> Casting to int is fine as long as i
duane> (3) and thus, target addresses are generally equal to - or
duane> smaller then the host "unsigned integers"
zach> This is why we have intptr_t. The code shouldn't care.
zach> It's a bug if it does.
I believe you are mistaken, what you are looking for is: TARGET_intptr_t
not HOST_intptr_
You miss an important point, it is *NOT* the possible range of values
the *TYPE* may take on.
It is the range of values the **ACTUAL*DATA** might take on that is
important here.
It's much easier to make sure bugs are not introduced in the future to
make sure that things like printf respect
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote:
[snip]
> If we had to fix this, what would we do to fix this:
>
> Today - we do not have macros, or types like GDB/GCC/GAS.
> GDB for instance uses CORE_ADDR - and has infrastructure behind it.
[snip]
This point deserves emphasis. This is the
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> >
> >> duane> FYI - I committed several cygwin specific printf() warning fixes.
> >> duane>Simple cast to fix
> >> duane> these where causing "-Werror" fail
zach> I am opposed to reverting the changes; I would rather
zach> we take some time to audit the code and fix the system
zach> to ensure we improve portability.
Agreed 100%
zach> In the same process, we could also fix
zach> up the 160 odd places where strtoul is
zach> used without sufficient er
Zach Welch wrote:
> On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
>
>> duane> FYI - I committed several cygwin specific printf() warning fixes.
>> duane>Simple cast to fix
>> duane> these where causing "-Werror" failures on cygwin.
>>
>> zach> I was just about to post some patches
On Fri, 2009-06-19 at 17:40 -0700, Zach Welch wrote:
> On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> > duane> FYI - I committed several cygwin specific printf() warning fixes.
> > duane>Simple cast to fix
> > duane> these where causing "-Werror" failures on cygwin.
> >
> > zach> I
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> duane> FYI - I committed several cygwin specific printf() warning fixes.
> duane>Simple cast to fix
> duane> these where causing "-Werror" failures on cygwin.
>
> zach> I was just about to post some patches to show how to fix all of the
duane> FYI - I committed several cygwin specific printf() warning fixes.
duane>Simple cast to fix
duane> these where causing "-Werror" failures on cygwin.
zach> I was just about to post some patches to show how to fix all of these
zach> correctly, as casts are not the right way to do it.
In
On Fri, 2009-06-19 at 19:38 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
> >
> >> FYI - I committed several cygwin specific printf() warning fixes.
> >>Simple cast to fix
> >>
> >> these where causing "-Werror" failures on cygwi
Zach Welch wrote:
> On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
>
>> FYI -I committed several cygwin specific printf() warning fixes.
>> Simple cast to fix
>>
>> these where causing "-Werror" failures on cygwin.
>>
>
> I was just about to post some patches to show how
On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
> FYI - I committed several cygwin specific printf() warning fixes.
> Simple cast to fix
>
> these where causing "-Werror" failures on cygwin.
I was just about to post some patches to show how to fix all of these
correctly, as ca
FYI - I committed several cygwin specific printf() warning fixes.
Simple cast to fix
these where causing "-Werror" failures on cygwin.
>> Author: duane
>> Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009)
>> New Revision: 2293
>>
>> Modified:
>> trunk/src/jtag/arm-jtag-ew.c
>> trun
19 matches
Mail list logo
