This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc problem/question in 2.1.3


>>>>> On Mon, 05 Jun 2000 02:28:13 -0400, Mike Corbeil
>>>>> <mcorbeil@netrevolution.com> said:

    Mike> condition.  This problem or caveat, however, has surely disappeared with the dawn
    Mike> of more powerful CPUs, and ANSI isn't robust, except at a superficial level (ANSI
    Mike> sucks, in this sense, #$#$#$#$!!!!!, as I'm sure many would say, more or less).

    Mike> Redefining ptr to null is a very separate, distinct, concept, because it really
    Mike> has nothing to do with free, except that free doesn't make the redefinition.
    Mike> Although free could do this, there's really no reason for it to do so and there
    Mike> are cases where this would be unnecessary overhead, technically and logically.

    Mike> Checking the ptr before calling free is kind of a patch, as is redefining ptr to
    Mike> null, but only the first or former patch is logically valid, in a strict sense,
    Mike> but only because it's imposed by C or $#$!@#$!@#!!!! ANSI.

Where I don't agree with you on this is that you can choose with C
whether you want some additionnal level of robustness (by adding extra
code) or performance.
In the latter case, you can avoid putting extra code if you know your
code is bugfree. In the case of the pointer put to NULL, this
verification shouldn't occur in a correct program, but in this case it
could serve as a way of debugging the program.

    Mike> For example, in some contexts it's crucial or important to check the result of
    Mike> malloc, but in others, like VAX/VMS, it's not necessary, or at least not
    Mike> according to some people who developed mission critical systems in C on this
    Mike> platform; people possessing graduate degrees in CS.  I believe that it is
    Mike> unnecessary in VAX/VMS, but it is definitely a strong plus or even necessary in
    Mike> MS, or at least MS DOS.  For Unix I'm not sure, however regardless what OS I
    Mike> program in, I always check the result of malloc, even if only for potential
    Mike> portability.

Why should we check the result of malloc on some systems and not on
others. What particularity do these systems have ?

Another question : what does this "wrt" word mean ? I could read it a
couple of times in your message but I can't figure out its meaning.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]