Re: Malcolm's new book



[snips]

On Thu, 02 Aug 2007 20:03:59 +0100, Malcolm McLean wrote:

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.

In a 32-bit environment that is most unlikely. In a 64-bit environment,
well, that's a different story.

In a 16-bit environment, entirely possible.

I explain in the opening paragraphs why size_ts will not pollute my C
code

Because they exist for a reason, they do a job ints don't do, they do it
properly, in cases where ints simply are the *wrong* type - and thus you
choose int.

As I said, a complete failure to grasp basic concepts.

. You don't disagree with this reasoning, you either haven't read it
or fail to engage with it.

I will, of course, disagree with any argument which leads to provably
wrong results, such as concluding int is the appropriate type for size
arguments where size_t is the correct choice.

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.

Intermediate size or index calculations can easily be negative.

In which case, use ints for those, if applicable. Using them to pass or
return the size of a buffer is simply wrong, as a buffer will never have a
negative size, but can have a size larger than the range of an int, making
int the wrong type to use.

One problem with algorithm books is that they are written to the latest
fashion in languages. It might be Fortran, or C, or C++, or Java. I
expect my book to be still useful in a hundred years time.

I haven't read the whole thing, but the example chapters say it's not
particularly useful *now*, since it contains your fundamental inability to
grasp basic concepts and thus persistently does the Wrong Thing. Well,
okay, it might be useful as kindling, but it is bad enough, based just on
those examples shown, that it should never be allowed anywhere near a
programmer's hands, for fear it will taint them with the same illogic and
poor designs you employ in it.

by then, but the fundamental algorithms that make computers work won't
have changed. However languages change. I can't imagine C without int,
but size_t could well be obsolete by then.

Why would size_t be obsolete, since it does a job int does not do?

I can't see a language that
insists on a type called "size_t" as a general-purpose index lasting for
long.

So? It exists now, it has reasons for existing now, and you are ignoring
them and as a result producing bad, broken, amateurish code.
.



Relevant Pages

  • [PATCH] Numerous fixes to kernel-doc info in source files.
    ... static inline int ffs ... @buffer: where the data must be copied. ... * struct kfifo with kfree. ... @timer: ...
    (Linux-Kernel)
  • [UNIX] Multiple Vulnerabilities in Citadel/UX
    ... could allow complete control over a vulnerable server. ... Citadel server as can be seen by this simplistic code snippet: ... configuration buffers, leading to the possibility of carrying out a buffer ... int connect_to_host; ...
    (Securiteam)
  • Re: pushing the envelope with sockets
    ... receiving on the socket they are received (upto the buffer size), you can even change what happens if the buffer runs full. ... int read = S.EndReceive; ... class AsyncReader: Reader ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
    ... arch-independent pieces of the OProfile kernel driver that this patch ... kernel driver patches. ... into the kernel buffer without holding the buffer_mutex lock. ... int spu_sync_start; ...
    (Linux-Kernel)
  • [PATCH] char: make functions static in synclinkmp.c
    ... int *eof, void *data) ... /* Allocate DMA buffers for the transmit and receive descriptor lists. ... * This buffer is used to pass an assembled frame to the line discipline. ...
    (Linux-Kernel)