Hi, all!
Well, I think I need to add something to discussion. We actually have
3 problems here.
1. Type defintions problem.
2. As [1] is decided, there is transition needed.
3. Whatever is done, it does not add to functionality, only maintainability.
As it is generally considered, when release
Nicolas Pitre a écrit :
As far as my opinion matters, I don't think that uint32_t is that much
clearer than u32. It is widely assumed that u32 refers to an integer
and not a float, hence having the information carried everywhere is up
only for additional typing and screen realestate.
On Sun, 2009-05-24 at 22:43 -0700, Rick Altherr wrote:
On May 24, 2009, at 9:37 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009,
On May 25, 2009, at 12:28 PM, Zach Welch wrote:
1) It's shorter/faster to type. This argument has been hashed out
extensively on the Linux mailing lists. Linus has it right in this
debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean
we
can't exploit their work for own
zach
Sorry Rick, but I think that you and Duane have lost this argument.
You have failed to defend your position with facts.
It's hard to 'defined my position' - when I asked this last night 9pm -
and left early this AM to spend a good part of memorial day holiday on a
sail boat (what a
Rick Altherr a écrit :
Perhaps I'm jaded from writing code for OS X where function names are
intended to be descriptive and thus end up long. Most editors include
autocompletion which makes the difference minimal in practice. Even
when I'm writing code in vi, I prefer the longer type names
On May 25, 2009, at 1:21 PM, Duane Ellis wrote:
zach
Sorry Rick, but I think that you and Duane have lost this argument.
You have failed to defend your position with facts.
I was asking more for an opinion, and the *REASON* I wanted to ask
this was the recent rash of printf() formatter
On Mon, 2009-05-25 at 14:01 -0700, Rick Altherr wrote:
On May 25, 2009, at 1:52 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote:
[snip]
Sorry Rick, but I think that you and Duane have lost this argument.
You have failed to defend your position with facts.
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:
Further, you can argue with the following assertions -- only if you
can
show me a patch that proves them wrong:
Show me your patch, or let me commit mine. This debate is silly.
On May 25, 2009, at 2:50 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:
Further, you can argue with the following assertions -- only if
you
can
show me a patch that proves them wrong:
Show me your patch, or
On Monday 25 May 2009, Rick Altherr wrote:
Show me your patch, or let me commit mine. This debate is silly.
My two cents: Commit Zach's patch, since it ends up
resolving potential bugs with e.g. u32 != uint32_t.
Then put the debate off to the side for a while. Arguing
like that is
On Mon, 2009-05-25 at 15:02 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:50 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:
Further, you can argue with the following assertions -- only if
you
can
On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
On May 25, 2009, at 3:37 PM, Zach Welch wrote:
The opposing patch is attached. As I already mentioned, it is
large,
but the changes were done entirely with the following commands:
find . -name \*.[ch] -exec sed -i .old -e
On Monday 25 May 2009, Rick Altherr wrote:
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that fact.
Trust me, there is no passion on this end. Only
On May 25, 2009, at 6:31 PM, David Brownell wrote:
On Monday 25 May 2009, Rick Altherr wrote:
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that
fact.
Trust
Why not deprecate/change, all u32 to uint32_t - wholesale?
Likewise for others.
Any reason not to? I mean stdint.h does exist, or a reasonable equal
can be made via types.h.
-Duane.
___
Openocd-development mailing list
On Sun, 2009-05-24 at 21:40 -0400, Duane Ellis wrote:
That is the other question: stdint.h is a C99 header, yes? It might be
better to unconditionally included it, defining our short types from it.
What do you think?
We already do, it is included by 'types.h'.
Conditionally. The
On May 24, 2009, at 6:40 PM, Duane Ellis wrote:
That is the other question: stdint.h is a C99 header, yes? It might
be
better to unconditionally included it, defining our short types
from it.
What do you think?
We already do, it is included by 'types.h'.
I am saying that *IF* for some
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32 is used by replacements.h
The traditional sibling of a u32 (unsigned) is an s32 (signed).
I don't know where i32 came from, it's an interloper.
That
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32 is used by replacements.h
The traditional sibling of a u32 (unsigned) is an s32 (signed).
I don't know
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32 is used by replacements.h
The traditional
On Sun, 2009-05-24 at 21:37 -0700, Zach Welch wrote:
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to
On Sunday 24 May 2009, Zach Welch wrote:
1) It's shorter/faster to type.
Which is why I like u32/s32 (and friends) mysself.
The {u,}int{8,16,32,64}_t names are committee design.
They look and smell long, like an elephant. ;)
___
On May 24, 2009, at 9:37 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
=On May 24, 2009, at 9:04 PM, Zach Welch wrote:
On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
On Sunday 24 May 2009, Zach Welch wrote:
- add iN equivalents to intN_t types; i32
24 matches
Mail list logo
