Re: Malcolm's new book - Chapter 1 review

[snips]

On Sat, 11 Aug 2007 10:30:38 +0100, Malcolm McLean wrote:

Someone sees

void compress(void *data, size_t sz)

he will naturally assume that the reason for the size_t is to allow the
function to compress an buffer that can be held in memory.

Er... no. The void *data (being the only readily apparent "input" to the
function) tells him that the function will be compressing data from
memory; the size_t indicates that the parameter sz indicates the size of
said buffer.

if he sees

void compress(void *data, int len)

then that assumption isn't as strong

Actually, the indication it's compressing data from memory is exactly
identical, as it still uses void * to specify the buffer. What becomes
unclear isn't the source of the data, but the meaning of the len
parameter.

Above, sz implied size of buffer. Below that, len no longer implies
that, since it now allows negative values which are meaningless in
specifying buffer sizes, and _disallows_ perfectly legal buffer sizes -
meaning I can have a buffer with more than INT_MAX bytes yet have
absolutely no way, with your functions, to specify how long it is.

The first form of the function makes sense, the second doesn't; aside
from simply being broken (failing to allow me to specify the size of
perfectly valid buffers) it gives implications of "magic" - i.e. it
suggests something special happens when I pass in -137 or -1 or -32767 as
the len; if not, then there's no reason for len to be a signed int
instead of a proper size_t.

So... exactly *what* magic gets done when I pass in -1 or -137 or
-32767? Can't tell from the function prototype, and I don't see a
comment block specifying all the magic values. I'm sure they're all
documented, though, right?

- he will tend to assume that any
integer can be accepted

Of course... but since -1 isn't a valid length for a buffer passed in by
a void *, this is no longer a length parameter - despite the name - but,
rather, an indicator of some weird hidden magic released by values having
no relation to the size of the buffer. Which, of course, suggests that
"len" is a horrendously bad name, as whatever it is specifying is at best
_occasionally_ a length.

all functions taking integers can accept any parameters. In fact the
function will fail if the integer is over four bytes, because it stores
the length as four bytes.

So I run this on a 16-bit implementation, you store the size of the "len"
parameter as four bytes. So far so good... but I can allocate buffers
larger than the code will allow me to compress, because size_t has a
wider positive range than int on such a machine: I can create buffers of
65535 bytes, but only compress buffers of 32767 - and all because the
developer seems to think size_t has no reason for existing, despite ample
evidence to the contrary.

This restriction is extremely easy to remove,

And shouldn't be there in the first place, as it shows the author either
doesn't understand things such as size_t, or simply doesn't care about
writing code well.

Bytes are eight bits.

You're in the land of C... where eight bit bytes are nothing more than an
occasional happenstance.

That is standard use of the term when defining
binary data formats, which have nothing to do with the C language.

Welcome to planet earth: you're using C, developing algorithms in C,
discussing them in a C newsgroup. Guess what? We use C terms here.

Of
course a byte is also the smallest addressible unit of memory.

Is it? Not according to the standard. By your use, if a machine is
designed which assigned addresses to individual bits (or perhaps pairs or
quads of bits) then 1, 2 or 4 bits would be a "byte" on that machine.
Seems like a poor definition. Fortunately, has bugger all to do with C.

The word
is used in two ways.

Yes it is. It is used correctly - as an equivalent to char, in terms of
size - and incorrectly, as something other than equivalent to char, in
terms of size.

.

Relevant Pages

  • Re: Streaming XML
    ... This document object grows bigger and bigger while the application ... The document is used as a buffer of data, ... The first is related to memory usage. ... I want to compress it. ...
    (microsoft.public.dotnet.xml)
  • Streaming XML
    ... This document object grows bigger and bigger while the application ... The document is used as a buffer of data, ... The first is related to memory usage. ... I want to compress it. ...
    (microsoft.public.dotnet.xml)
  • Re: String to byte[] reloaded
    ... can reuse the same buffer several times. ... I cannot change the compress method's signature (e.g. ... To make sure I handle very careful such a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why COBOL is losing the POWER struggle
    ... compress replacement operands within a buffer. ... Dashwood, 'as far as you are concerned' is not 'what the machine is ...
    (comp.lang.cobol)
  • Re: Probleme mit FoxPro Anwendung auf Windows 2003 Terminalserver
    ... Specifies the maximum buffer memory size in bytes. ... for nBuffMemSize that is less than 256K bytes, ... Specify 0 for nBuffMemSize to return the buffer ...
    (microsoft.public.de.fox)