And of course, the move() procedure in FPC/TP/Delphi has exactly the same problems as memcpy() as far as bounds-unsafety is concerned (it's similar with fillchar/memset, indexbyte/memchr, etc).

Jonas

Jonas Maebe :

And of course, the move() procedure in FPC/TP/Delphi has exactly the same problems as memcpy() as far as bounds-unsafety is concerned (it's similar with fillchar/memset, indexbyte/memchr, etc).

True. But in contrast to C an average programmer doesn't need it very often. In Pascal there are easier ways to assign arrays to each other than doing a raw byte copy. ;)

But I still fail to see the advantage of

void * memcpy_s ( void * destination,
size_t dest_size,
const void * source,

                        size_t num );

vs. the original:

void * memcpy ( void * destination,
const void * source,

                      size_t num );

Time will tell, if memcpy_s() is actually "safer". If the programmer didn't think about the destination buffer's size before, why should he now? :->

Vinzent.

In our previous episode, "Vinzent H�fler" said:

Less, yes.

That's the feeling I had too. It will only matter in a very small number of items, where the numbers are actually calculated on the spot in different ways.

"Vinzent Höfler" :

Time will tell, if memcpy_s() is actually "safer". If the programmer didn't think about the destination buffer's size before, why should he now? :->

The C(++)-folks fix:

-- 8< --
inline void memcpy_s(void *dest, size_t sizeInBytes, const void *src, size_t count) {
if (count > sizeInBytes)
throw InvalidArgument("memcpy_s: buffer overflow"); memcpy(dest, src, count);
}
-- 8< --

LMAO. Adding unnecessary bounds checking on each single call. So much for the speed advantage of a low-level language. A pascal compiler knows the correct sizes beforehand, no need for extra bounds checking...

Vinzent.

Because the API forces him to think about it now.

I don't think it's unnecessary. Moreover, in the trivial cases (where you wouldn't use a move() in Pascal) the check will be optimized away (since all size-related arguments will be constants), and in most other cases the time spent on actually copying will probably dwarf any overhead added by that extra check.

So much for the speed advantage of a low-level language. A pascal compiler knows the correct sizes beforehand, no need for extra bounds checking...

A Pascal compiler has no idea about any actual variable sizes inside the move() procedure.

Jonas

Jonas Maebe :

I wouldn't be to sure about that. See below.

As necessary as in "the check will be optimized away"? ;)

Moreover, in the trivial cases (where you wouldn't use a move() in Pascal) the check will be optimized away (since all size-related arguments will be constants),

Hmmhmm. That means any static checker (like lint) should have caught the buffer overflow before the code even got compiled?

Well, C-code tends to forget any type information at the second call-level latest. Whilst a "sizeof" on a "char buffer[5]" declaration still works, "sizeof" yields different results for "char*". As "memcpy" itself demonstrates, both types are broadly equivalent, with the small difference that the latter is void of /any/ size information.

This simply doesn't happen with Pascal's arrays, even in non-trivial cases.

and in most other cases the time spent on actually copying will probably dwarf any overhead added by that extra check.

Sure. Tell that to the C-folks who keep complaining about slow languages like Pascal and Ada because of the runtime checks that happen there.

But it usually knows it before entering it. C compilers don't.

Vinzent.