Re: malloc problem/question in 2.1.3

[Mike Corbeil <mcorbeil at netrevolution dot com>]

Wolfgang Sourdeau wrote:

> >>>>> 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 ?

I didn't say anything wrt what we should and should not do.  That's a misinterpretation.

However, I believe that the reason malloc calls weren't verified on VAX/VMS is because these
never fail(ed), due to an inherent aspect of the OS, I believe (I think VMS means Virtual
Memory System, or something like that, with some implication that whenever memory was or is
needed, it could or can be obtained with assurance, but am not a VMS expert to the n-th
degree, n>=30-40%).

Whether or not this is true, I can't say, because the programs I was (only) maintaining worked
flawlessly, I asked the person who developed these programs about this very point, and he said
that that this was indeed the reason.

I didn't subsequently bother looking for books to verify, because this person had a graduate
degree in CS, undergrad in Math, was then project manager of a Unix systems integration team
of a major bank's treasury dept, and the programs worked flawlessly; even if I didn't like
malloc not being verified, by principle.

I would always verify calls to malloc, regardless of the OS I was developing on.  We
definitely should on some or all other platforms, other than VMS anyway, and I'm not
sufficiently knowledgeable about all of them to speak with total accuracy.  However, it's
definitely important on MS OSs, older ones anyway, and that being the OS on which I initially
learned C in 89, I've carried along the concept of verifying malloc calls to programming in C
on Unix, and will do the same on any platform I work on, including VMS (when I'm doing
development).  Only once did I develop a new program on VAX/VMS and I checked my calls to
malloc there, too, because it's the convention and certainly can't or shouldn't hurt, not
usually anyway.

Unlike reinit'ing or redefining ptr to null immediately after applying free to the ptr,
verifying the status of a call to malloc is conventional.

Portability is another guideline I try to always program by; although, time constraints are
also sometimes so pressing that some immediately unnecessary overhead is not always applicable
without management court marshalling staff.


> 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.

No problem.  It means "with respect to".

In case you're not familiar with some others:

=> means implies (you probably already knew this one)
Btw => by the way
Otoh => on the other hand
Afaik => as far as I know or knew
Afaict => as far as I can tell (I've never seen this one)
Imo => in my opinion
Imho => in my humble opinion
Imnsho => in my not so humble opinion
Fyi => for your information (you probably knew this one, also)
TAMWTDI => there are many ways to do it (not sure if I have the acro entirely correct, but
it's close and from the author of Perl so you'll definitely find the one I'm trying to think
of in an O'Reilly book on Perl)

These are the ones I can think of off of the top of my head.  Some others, I still haven't
figured out and haven't gotten around to asking, but they're also rarely used.  The above are
fairly to very common, in the USA anyway.

I know the feeling.

mike