Re: Malcolm's new book
- From: Kelsey Bjarnason <kbjarnason@xxxxxxxxx>
- Date: Thu, 2 Aug 2007 09:03:38 -0700
[snips]
On Sun, 29 Jul 2007 22:36:39 +0100, Malcolm McLean wrote:
The problem is that I have to write the code with either ints or size_t's.
Being an int should fit all man, I chose int.
Bad choice.
int get_buff_len( buffer_t buff )
Quick: what happens if the length of the buffer is > INT_MAX? Hmm...
could be held in a size_t, which can handle the size of the largest
allowable object, but pukes on int.
Yeah, well. int.
This then leads to accusations of not having grasped the concept of
size_t.
Obviously, you haven't.
Of course it is pretty unlikely that someone would churn out 600
pages of C code but lack the intellectual capacity to understand that
size_t is the ANSI recommended way of representing amounts of memory.
Yet you get it wrong consistently.
I
even discuss the issue briefly in chapter 1.
Then you should know better.
But I have to explain my
reasons, whether you accept them or not, rather than be thought ignorant
of the existence of such a type.
If you know it, you should use it. Since there is *no* possible
justification for using int in such cases, as sizes are never negative and
can overflow the range of an int, you simply cannot use int reliably in
such cases - which is *exactly* why size_t exists in the first place.
Since you don't use size_t, one must conclude you're unaware of what it
is, what it's for and why it exists. If you *did* know, you'd have used
it, instead of int.
.
- Follow-Ups:
- Re: Malcolm's new book
- From: Malcolm McLean
- Re: Malcolm's new book
- Prev by Date: Re: The chart of comp.lang.c
- Next by Date: Re: Check if process has a stdin handle
- Previous by thread: Re: Malcolm's new book
- Next by thread: Re: Malcolm's new book
- Index(es):
Relevant Pages
|