Re: Using malloc in C++?
Owen Jacobson wrote:
On Jun 7, 8:09 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
Owen Jacobson wrote:
... Or any of
a number of other circumstances?
Chinese fish prices not withstanding ?
That's what "implementation defined" means, yes. The entire behaviour
of malloc is, somewhat obliquely, implementation-defined. The only
properties malloc must have in a conforming implementation is always
producing any of a fixed set of outputs for any given input, and that
subsequent operations on those values also have predictable results.
This describes malloc and numerous other interfaces. Again, so ? Here
is some more info http://www.fa.gov.tw/eng/news/news.php.
I don't see the relevance of this to this thread. We're talking about
portability issues of malloc over new. Someone assered that malloc
behaves differently on different platforms. My recollection was that
free(0) and malloc(0) used to be poorly specified. Someone said that
malloc(0) has two standard behaviours and I said QED. How this relates
to code throwing exceptions is about as relevant as PRC fish prices.
The assertion that malloc is somehow "less portable" than new is so
wrong-headed that I thought I'd have a shot at dismantling it. Plus,
I like replying to you.
In the context of the OP - what do you use - malloc or new ? Your less
likely to get into trouble using new if you don't know about malloc(0)
having two conforming behaviours. IIRC, the reason why I ended up
knowing about issues with free(0) and malloc(0) was when my own malloc
library did different things than the standard library and code started
to break everywhere. It became clear to me that wether I liked it or
not, malloc(0) should likely return non-null otherwise lots of code
broke. It was used in some cases as a process specific unique number
generator. In some cases strings of 0 length were allocated and
comparison of string pointer was an identifying mark of being the same
string. My initial work around for the "malloc bug" was to change the
length to 1 if it came in as zero but later I fixed the code so the
allocated block was actually 0 bytes long.
You may argue all you like about how portable malloc is but in reality I
have had alot of experience that tells me differently.
What ? malloc(23) should only return null in the case of a bug (non
conformance) or inability to allocate memory (bad_alloc). Are you
advocating otherwise ?
The C standard, from whence malloc comes, is extremely conservative
when it comes to defining what standard library functions that have
side effects are required to do. The verbiage in C99 is as follows:
If the space cannot be allocated, a null pointer is
returned.
It does not say "If the space is unavailable", or "If memory is full",
or anything else, merely "if the space cannot be allocated."
Reread what I wrote. If it's not nearly identical to what you assert
then I don't understand.
Ah, but your point, as I read it, was that malloc's behaviour when
passed 0 as an argument was somehow less well-specified than its
behaviour in the face of other inputs.
malloc(0) just leads to novices creating code that may or may not be
portable. That's the only thing I was alluding to.
... This is, as supported by
careful examination of the C standard, not true.
By experience it is true. The C standard can say all it likes but
broken code exists and new broken code will continue to be written.
... Code which relies on
malloc returning a non-NULL pointer, and code which relies on new
returning a pointer rather than throwing an exception, *must* be
prepared for the alternative as it will eventually happen in all but
the most trivial examples. Period.
Never argued any different. However demanding it and getting it are two
very different things.
... As I
said: it's a quality of implementation issue; a sufficiently poor
implementation may never be able to allocate exactly 23 bytes and
unwilling to allocate more than requested.
Again this is relevant to this discussion how ? The "mystring" code I
hacked earlier is an example where on one platform malloc(0) returning
different values on different platforms causing vastly different things
to happen being a portability issue.
Neither the C nor the C++ standard guarantees that conforming code
will behave identically on all platforms. They guarantee that
conforming code will behave *predictably* on all conforming
platforms. This is true of all programming languages that have formal
definitions.
There is a certain level of expectation that calling "malloc(1)" at the
beinnging of main will return non zero. I have found numerous
applications that segv when it does not (when I was doing my malloc
testing). Even libc on many platforms died even before main() was
called when I did my tests 15 or so years ago. I suspect things are a
little better now.
That's all. Code like this
exists. The point is that new has a more strict definition
Cite from the relevant standards? I don't see any evidence that
that's actually true.
What standard ? I wrote code in this thread earlier that works on one
platform and not on another - wether it's conforming or not is
irrelevant, the fact is that I know it exists because I ran into 10s of
applications that expected certain behaviour from malloc(0). It's proof
by existence.
and hence it will result in better code portability.
*If* 'new' has a more strict definition than malloc, then code that
utilises 'new' will have a more strictly-defined behaviour than code
that uses malloc, yes.
Yes.
... Such an implementation
would be conformant, even though it would likely have no users.
Again, so what ? The point is that code (bad or otherwise) exists such
that it works on one platform and not another because of THIS behaviour
of malloc which does not happen with new. That's all. If you think it
does not exist, see my code above. If you don't believe that anyone
would write code like that, get more experience.
The same behaviour is permitted from new (and new[]). Nothing in the C
++ standard demands that a new-expression exhaust memory before
throwing std::bad_alloc -- in fact, the definition of new and new[] is
carefully written to allow malloc() as an allocator function[0].
Therefore, nothing prohibits a compliant C++ implementation from, by
default, throwing bad_alloc consistently on either of the two
following examples:
--example1.cpp--
class Empty {
};
int main () {
Empty *e = new Empty (); // Here
delete e;
}
Conforming or not, it would be a terribly useless compiler if it did
throw bad_alloc here. Hence I think none do unless memory really can't
be allocated as in it is exhasted by some implementation defined meaning
of exhausted.
Besides sizeof Empty is probably 1 on most implementations so it's not
relevant to this discussion when comparing it to malloc(0). The
standard requires that each object have a unique address. There is a
trivial base class optimization that does essentially make Empty zero
sized when derived from but compilers are free to simply sizeof Empty 1.
--example2.cpp--
int main () {
int *i = new int[0]; // Here
delete i;
}
I don't think any C++ compiler will throw here either (I have yet to see
one) unless memory is exhausted (by some implementation defined meaning
of ehausted).
--end--
Once again, such an implementation would be conforming: the behaviour
of both programs is predictable. It would merely be extremely poor.
.... and pointless.
Do you know of the existance of a platform that will consistantly throw
bad_alloc for "int *i = new int[0];" ?
....
I find it hard to believe you expect the ISO standards committee to
control the behaviour of myriad implementation vendors, as that's what
enforcing any specific behaviour from a memory-allocation function
would require.
What are standards for again ?
... It would also require absolute cooperation from OS
vendors and hardware manufacturers.
That's one of the side effects of standards.
Isn't it time to get these implementations fixed, Gianni?
Sure. By that question do you imply you want me to do something about
it? You seem to have a grasp of the issue, you're just as qualified as
I am. Good luck with the C committee.
While I'm not psychic, I believe the C committee's goals to include
defining a language in which both extremely portable code and
extremely platform-dependant code may be written.
What the committee wants to do is highly dependent of the committee
members. However, given that one of the most critical features of a
computer language like C and C++ is to have a certain degree of code
portability, I would expect that this one would be high on it's priority
list.
... Consequently, the
standard defines rules within which code is guaranteed to behave
predictably under any conforming implementation; it is up to
programmers to be familiar with these rules if they wish to write code
that's as portable as C allows.
Sigh. True. I have met too many programmers to know reality is
unfortunately different. The best thing is for the standards committee
to provide well defined behaviour where there is no compelling
implementation dependent reason to do otherwise. i.e. malloc(0) being
defined to behave like malloc(1) would have been a fine requirement in
the standard.
... The language does not demand that all
code remain within these rules.
What do you think we're discussing ?