Need to find size of destination buffer for strncpy

[Keith Thompson]

no, its a feature

Yes, but it's a feature with some pitfalls. For example, if I
accidentally type:

#if __STDC_VERSION_ >= 199901L
// code that depends on C99
#else
/* code that depends only on C90 */
#endif

then the compiler won't complain about the typo. The result in this
case is that it will always use the C90-specific code (which will
probably work correctly with a C99 compiler), and the C99-specific
code won't be tested.

I think if I were designing the language from scratch, I'd make a
reference to an undefined symbol an error. Of course, making such a
change now would break existing code.

 

[Giorgos Keramidas]

and then get rejected by malloc. At least nmalloc. So what?

Unless there *is* enough memory to satisfy the allocation request,
right?

jacob is also trying to blame programmer error (using a negative, signed
value as a 'size_t') to the size_t type itself. What he fails to supply
is a `type which is better than size_t for representing object sizes'.

He seems to imply that 'int' is better, but we all know it isn't.

 

[Stephen Sprunk]

Unless there *is* enough memory to satisfy the allocation request,
right?

In theory. I'm curious if there is any existing 32- or 64-bit
implementation that can _ever_ successfully allocate (size_t)(-4) bytes.
None of the x86 or x64 OSes I know can, due to various "holes" in the
address space -- even RedHat's oddball Linux/x86 kernel that allows ~4GB
user space.

Clearly, it can succeed on systems that have a 16-bit size_t, such as
MS-DOS (and clones). Of course, using an int on such a system just adds
insult to injury, since it restricts you to allocating 32,767 bytes at a
time.

jacob is also trying to blame programmer error (using a negative,
signed
value as a 'size_t') to the size_t type itself. What he fails to
supply
is a `type which is better than size_t for representing object sizes'.

He seems to imply that 'int' is better, but we all know it isn't.

And, to be clear, the above 32,767-byte restriction holds in theory for
all systems; int isn't required to hold anything larger, and portable
code can't assume it does. int is clearly a bad choice for a memory
size argument in portable code.

If Jacob wants a signed argument to malloc(), he should at least be
proposing ssize_t (of course, assuming ISO standardized the POSIX
definition). However, the whole concept of allowing negative memory
sizes is just absurd to begin with. It catches one very obscure bug
which is likely to be caught anyways because malloc(-4) is unlikely to
ever work, is only likely to be made in extremely rare circumstances,
and is easily discovered with a debugger -- and in return it cuts the
amount of memory one can allocate in half, which is a pretty severe
limitation for some real-world apps that need >2GB of memory on 32-bit
systems.

S

 

[Giorgos Keramidas]

In theory. I'm curious if there is any existing 32- or 64-bit
implementation that can _ever_ successfully allocate (size_t)(-4)
bytes. None of the x86 or x64 OSes I know can, due to various "holes"
in the address space -- even RedHat's oddball Linux/x86 kernel that
allows ~4GB user space.

You're right of course. I should have stated more clearly that I had
arithmetically smaller values than -4 in mind.

Clearly, it can succeed on systems that have a 16-bit size_t, such as
MS-DOS (and clones). Of course, using an int on such a system just
adds insult to injury, since it restricts you to allocating 32,767
bytes at a time.

Exactly, thanks for putting in better words what I wrote