Extremely pedantic, but however...

Discussion in 'C Programming' started by Frederick Gotham, Oct 21, 2006.

  1. Is it not inefficient to have allowed "free" to accept a null pointer? Would
    it not have been better to disallow it, and to provide an auxiliary function
    for times when its wanted:

    #define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )

    --

    Frederick Gotham
    Frederick Gotham, Oct 21, 2006
    #1
    1. Advertising

  2. Frederick Gotham

    Malcolm Guest

    "Frederick Gotham" <> wrote in message
    news:W1l_g.15055$...
    >
    > Is it not inefficient to have allowed "free" to accept a null pointer?
    > Would
    > it not have been better to disallow it, and to provide an auxiliary
    > function
    > for times when its wanted:
    >
    > #define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )
    >

    In the olden days freeing a null pointer would crash your computer.
    The overhead is probably so trivial that the convenience is worth it.
    Plus malloc() is allowed to return null if a region of zero size is
    requested. So it is not necessarily illegitimate to free null.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
    Malcolm, Oct 21, 2006
    #2
    1. Advertising

  3. Frederick Gotham

    Skarmander Guest

    Frederick Gotham wrote:
    > Is it not inefficient to have allowed "free" to accept a null pointer?


    Only in C. Programmers in other languages generally don't care about an
    insignificant extra comparison. (free() itself is hardly cheap on most
    implementations.)

    > Would it not have been better to disallow it, and to provide an auxiliary
    > function for times when its wanted:


    Define "better". C already catches a lot of flak for having standard
    functions that do not check their arguments (or in some cases cannot check
    their arguments). The comparatively small cost of ensuring free(NULL)
    doesn't crash is worth it (note that in the general case free() does not
    have observable side effects, so making free(NULL) a no-op does not decrease
    reliability).

    S.
    Skarmander, Oct 21, 2006
    #3
  4. Skarmander posted:

    >> Is it not inefficient to have allowed "free" to accept a null pointer?

    >
    > Only in C. Programmers in other languages generally don't care about an
    > insignificant extra comparison. (free() itself is hardly cheap on most
    > implementations.)



    I'm not talking about programmers, I'm talking about computers running
    programs. If it takes 20 nanoseconds for a particular machine to check if a
    pointer is null, then the execution time of your algorithm is extended by
    20 nanoseconds for each time you call "free" (if every one of these null
    checks is redundan). Those 20 nanoseconds could have been reclaimed if
    "free" didn't check for null pointers.

    Whether a particular human being (aka programmer, in this context)
    considers 20 nanoseconds to be negligible is irrelevant to my query.


    >> Would it not have been better to disallow it, and to provide an
    >> auxiliary function for times when its wanted:

    >
    > Define "better".



    More efficient. Runs faster. Uses less resources.


    > C already catches a lot of flak for having standard
    > functions that do not check their arguments (or in some cases cannot
    > check their arguments).



    Depends who you ask. I congratulate C for its efficiency. If you want your
    hand to be held, you could get a wrapper library:

    size_t strlen_HOLD_MY_HAND(char const *const p)
    {
    if (p) return strlen(p);

    return 0;
    }


    > The comparatively small cost of ensuring
    > free(NULL) doesn't crash is worth it (note that in the general case
    > free() does not have observable side effects, so making free(NULL) a
    > no-op does not decrease reliability).



    If you want the feature of being able to invoke "free" upon a null pointer,
    then all it takes is something simple like:

    #define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);

    This way, you can use "free" whenever a null check would be redundant,
    saving 20 nanoseconds in execution time.

    --

    Frederick Gotham
    Frederick Gotham, Oct 21, 2006
    #4
  5. Frederick Gotham

    CBFalconer Guest

    Frederick Gotham wrote:
    >

    .... snip ...
    >
    > If you want the feature of being able to invoke "free" upon a null
    > pointer, then all it takes is something simple like:
    >
    > #define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);
    >
    > This way, you can use "free" whenever a null check would be
    > redundant, saving 20 nanoseconds in execution time.


    Ridiculous. All you are doing is applying the same test twice.
    The following is the code used in my nmalloc package (A #define
    converts nfree to free under the appropriate conditions). Note
    that nothing is done when ptr is NULL, apart from the ability to
    hook in user code. The DBG* lines are null in the release
    version. The hook mechanism also allows the user to catch any
    free(NULL) calls. See:

    <http://cbfalconer.home.att.net/download/>

    void nfree(void *ptr)
    {
    memblockp m;

    if (hookptr[free_HK]) hookptr[free_HK](0, ptr);

    if (ptr) {
    m = MEMBLKp(ptr);
    DBGPRTF("free(%p)", ptr); SHOWBLKF(m, "");
    if (ISFREE(m) || /* bad, refreeing block */
    FOULED(m) ) { /* block is fouled */
    badcallabort("free", 4, m);
    return; /* he can trap this SIGABRT */
    }
    dofree(m);
    #if DEBUGF
    DBGEOLN;
    #endif
    }
    else if (hookptr[free_null_HK])
    hookptr[free_null_HK](0, NULL);
    } /* nfree */

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Oct 21, 2006
    #5
  6. Frederick Gotham

    Skarmander Guest

    Frederick Gotham wrote:
    > Skarmander posted:
    >
    >>> Is it not inefficient to have allowed "free" to accept a null pointer?

    >> Only in C. Programmers in other languages generally don't care about an
    >> insignificant extra comparison. (free() itself is hardly cheap on most
    >> implementations.)

    >
    >
    > I'm not talking about programmers, I'm talking about computers running
    > programs.


    So am I.

    > If it takes 20 nanoseconds for a particular machine to check if a
    > pointer is null, then the execution time of your algorithm is extended by
    > 20 nanoseconds for each time you call "free" (if every one of these null
    > checks is redundan). Those 20 nanoseconds could have been reclaimed if
    > "free" didn't check for null pointers.
    >

    And free() is going to take up much more than 20 nanoseconds, most likely an
    order of magnitude more.

    > Whether a particular human being (aka programmer, in this context)
    > considers 20 nanoseconds to be negligible is irrelevant to my query.
    >

    Then your use of "inefficient" is peculiar, since efficiency never
    exclusively depends on absolute execution time. If that were the case, you
    should focus on making your programs much more efficient by not using
    dynamic memory allocation at all, obviating any concerns about free().

    >>> Would it not have been better to disallow it, and to provide an
    >>> auxiliary function for times when its wanted:

    >> Define "better".

    >
    >
    > More efficient. Runs faster. Uses less resources.
    >

    Your idea of better programs is limited.

    >> C already catches a lot of flak for having standard
    >> functions that do not check their arguments (or in some cases cannot
    >> check their arguments).

    >
    > Depends who you ask. I congratulate C for its efficiency. If you want your
    > hand to be held, you could get a wrapper library:
    >
    > size_t strlen_HOLD_MY_HAND(char const *const p)
    > {
    > if (p) return strlen(p);
    >
    > return 0;
    > }
    >

    This has nothing to do with hand-holding. If you're writing a program where
    you need either the length of a string or 0 if there is no string, this
    function is exactly what you want. If you're writing a program where you
    need the length of a string, calling strlen() with a null pointer is an
    error, since that's not a string.

    For free() it was decided that calling it with a null pointer is not an
    error, that "no memory" is a valid argument, and that freeing "no memory" is
    a no-op. This makes sense, since malloc() may return "no memory". Again, I
    maintain that the cost one pays for having these semantics, rather than more
    intricate ones that allow for a slightly simpler implementation, is
    insignificant.

    >> The comparatively small cost of ensuring
    >> free(NULL) doesn't crash is worth it (note that in the general case
    >> free() does not have observable side effects, so making free(NULL) a
    >> no-op does not decrease reliability).

    >
    >
    > If you want the feature of being able to invoke "free" upon a null pointer,
    > then all it takes is something simple like:
    >
    > #define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);
    >
    > This way, you can use "free" whenever a null check would be redundant,
    > saving 20 nanoseconds in execution time.
    >

    That does not address my point, which is that nobody ever benefits enough
    from those 20 nanoseconds to warrant changing the semantics of free().
    Programmers who are actually concerned with omitting redundant null checks
    should invest in their compiler, which is far more likely to pay off.

    A check for NULL in strlen() could be significant. My bold assertion is that
    a check for NULL in free() never is.

    S.
    Skarmander, Oct 21, 2006
    #6
  7. Frederick Gotham

    jacob navia Guest

    Frederick Gotham wrote:
    > Skarmander posted:
    >
    >
    >>>Is it not inefficient to have allowed "free" to accept a null pointer?

    >>
    >>Only in C. Programmers in other languages generally don't care about an
    >>insignificant extra comparison. (free() itself is hardly cheap on most
    >>implementations.)

    >
    >
    >
    > I'm not talking about programmers, I'm talking about computers running
    > programs. If it takes 20 nanoseconds for a particular machine to check if a
    > pointer is null, then the execution time of your algorithm is extended by
    > 20 nanoseconds for each time you call "free" (if every one of these null
    > checks is redundan). Those 20 nanoseconds could have been reclaimed if
    > "free" didn't check for null pointers.
    >
    > Whether a particular human being (aka programmer, in this context)
    > considers 20 nanoseconds to be negligible is irrelevant to my query.


    20 nanoseconds?

    At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
    1e-9 seconds

    OK, anyway this is for the principle you say. Suppose your program makes
    1e4 frees/second. That extra test will accumulate to

    0.5e-9*1e4 --> 0.5e-5 seconds, i.e. to make a difference of 1 second
    your program should run for 2e5 seconds, i.e. 55.55 hours, or 2.31 days.

    Non stop.

    And then you would just see a difference of 1 second, all this doing
    10 000 calls to free() in each second.

    This program
    #include <stdlib.h>
    #include <stdio.h>
    #define MAXTRIES 1000000*10
    int main(void)
    {
    char *a;

    for (int i=0; i<MAXTRIES;i++) {
    a = malloc(123456);
    free(a);
    }
    }

    takes 3.484 seconds, i.e. 10 million calls to malloc/free
    take 3.484 seconds, one of them takes 0,0000003484 seconds
    in a 2 year old PC running at 2GHZ.

    If you do 10 000 malloc/free per second you are using
    0,003484 seconds on those calls. In 200 000 seconds
    your program has spent 11.61 MINUTES in malloc/free, and from
    those 11.62 MINUTES you spend 1 second more in that test for
    NULL.
    jacob navia, Oct 21, 2006
    #7
  8. Frederick Gotham wrote:
    > Is it not inefficient to have allowed "free" to accept a null pointer?


    The test takes one or two instructions. The rest of the code for
    free() is at least ten times more instructions, most of them slow
    memory-reference instructions.

    In addition, since you can only free() something that has been
    malloc()ed, and only free() it once, those two test instructions only
    get run if you've also malloced() something. So you have to add the
    overhead of malloc() when considering this issue. malloc(), depending
    on the exact implementation, runs from 50 to 500 instructions.

    So two extra fast instructions out of 70 to 520 not so fast ones isnt
    much of a burden.

    And that's only for programs that do nothing but malloc() and free().

    I would not worry about it.
    Ancient_Hacker, Oct 21, 2006
    #8
  9. Frederick Gotham

    Eric Sosman Guest

    Frederick Gotham wrote:
    > Is it not inefficient to have allowed "free" to accept a null pointer?


    Terribly inefficient. Even worse is the fact that free()
    is a function, thus incurring the overhead of marshalling the
    argument, transferring control (possibly disrupting pipelines
    and instruction caches), remembering a return address, maybe
    saving some registers and/or doing a window turn with possible
    stack spill, and then unwinding the whole thing when free()'s
    business has been done. Pure overhead! Horrible to contemplate!
    free() should have been an operator, as in That Other Language.
    *Then* we'd finally get some efficiency!

    All right, class, let's turn the page. Next, we'll talk
    about all the time printf() wastes interpreting format strings.
    Who wants to go first?

    --
    Eric Sosman
    lid
    Eric Sosman, Oct 21, 2006
    #9
  10. On Sat, 21 Oct 2006 09:44:20 GMT, in comp.lang.c , Frederick Gotham
    <> wrote:

    >Skarmander posted:


    >> Define "better".

    >
    >More efficient.


    define more efficient... :)

    >Runs faster. Uses less resources.


    Fast, small, cheap. Perm two of three...
    >
    >If you want the feature of being able to invoke "free" upon a null pointer,
    >then all it takes is something simple like:
    >
    >#define FREE_SAFE(p) do { void *const q = p; if(q) free(q); } while (0);
    >
    >This way, you can use "free" whenever a null check would be redundant,
    >saving 20 nanoseconds in execution time.


    At the cost of getting the compiler to create an extra object, perform
    a test and insert a loop. This may cost more in terms of time, and
    resources, than the original free.

    I assume youre aware of the Three Laws of Optimisation?
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Oct 21, 2006
    #10
  11. > At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
    > 1e-9 seconds


    A test is a single instruction. Then a non executed branch is another
    instruction. The mips is the most recent CPU I can think of that has
    an integrated cmp/branch instruction.

    The CPU is (most likely) super scaller so these instructions are
    executing in parallel.

    I think that having to fetch 2 more instructions, branch prediction,
    convert to internal RISC format (if this is an x86 taget) is going to
    have a larger performance impact than actual execution


    > This program
    > #include <stdlib.h>
    > #include <stdio.h>
    > #define MAXTRIES 1000000*10
    > int main(void)
    > {
    > char *a;
    >
    > for (int i=0; i<MAXTRIES;i++) {
    > a = malloc(123456);
    > free(a);
    > }
    > }


    What about the performance of the following code ?
    The branch prediction inside of free isn't going to be that great.

    #include <stdlib.h>
    #include <stdio.h>
    #define MAXTRIES 1000000*10/2
    int main(void)
    {
    char *a;

    for (int i=0; i<MAXTRIES;i++) {
    a = malloc(123456);
    free(a);
    free(NULL);
    }
    }





    > Frederick Gotham wrote:
    > > Skarmander posted:
    > >
    > >
    > >>>Is it not inefficient to have allowed "free" to accept a null pointer?
    > >>
    > >>Only in C. Programmers in other languages generally don't care about an
    > >>insignificant extra comparison. (free() itself is hardly cheap on most
    > >>implementations.)

    > >
    > >
    > >
    > > I'm not talking about programmers, I'm talking about computers running
    > > programs. If it takes 20 nanoseconds for a particular machine to check if a
    > > pointer is null, then the execution time of your algorithm is extended by
    > > 20 nanoseconds for each time you call "free" (if every one of these null
    > > checks is redundan). Those 20 nanoseconds could have been reclaimed if
    > > "free" didn't check for null pointers.
    > >
    > > Whether a particular human being (aka programmer, in this context)
    > > considers 20 nanoseconds to be negligible is irrelevant to my query.

    >
    > 20 nanoseconds?
    >
    > At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
    > 1e-9 seconds
    >
    > OK, anyway this is for the principle you say. Suppose your program makes
    > 1e4 frees/second. That extra test will accumulate to
    >
    > 0.5e-9*1e4 --> 0.5e-5 seconds, i.e. to make a difference of 1 second
    > your program should run for 2e5 seconds, i.e. 55.55 hours, or 2.31 days.
    >
    > Non stop.
    >
    > And then you would just see a difference of 1 second, all this doing
    > 10 000 calls to free() in each second.
    >
    > This program
    > #include <stdlib.h>
    > #include <stdio.h>
    > #define MAXTRIES 1000000*10
    > int main(void)
    > {
    > char *a;
    >
    > for (int i=0; i<MAXTRIES;i++) {
    > a = malloc(123456);
    > free(a);
    > }
    > }
    >
    > takes 3.484 seconds, i.e. 10 million calls to malloc/free
    > take 3.484 seconds, one of them takes 0,0000003484 seconds
    > in a 2 year old PC running at 2GHZ.
    >
    > If you do 10 000 malloc/free per second you are using
    > 0,003484 seconds on those calls. In 200 000 seconds
    > your program has spent 11.61 MINUTES in malloc/free, and from
    > those 11.62 MINUTES you spend 1 second more in that test for
    > NULL.
    Samuel Stearley, Oct 21, 2006
    #11
  12. Frederick Gotham

    Guest

    Frederick Gotham wrote:
    > Is it not inefficient to have allowed "free" to accept a null pointer?


    No. In a balanced malloc/free design, free takes about 30 clocks
    minimum to completely execute. So the additional if() test (1 clock
    maybe?) is just too trivial to matter. In non-balanced malloc/free
    designs, indeed you can make the free() faster, but you've paid the
    comparatively bigger penalty for the malloc (maybe 75 clocks?) instead
    anyways.

    > [...] Would
    > it not have been better to disallow it, and to provide an auxiliary function
    > for times when its wanted:
    >
    > #define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )


    This is worse, because it distributes the checking throughout your
    code, rather than centralizing it inside the library. (I.e., your code
    footprint increases).

    This is besides the fact that since its a macro, p might be an
    expression with side effects that you are evaluating twice.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Oct 21, 2006
    #12
  13. Frederick Gotham

    jacob navia Guest

    Samuel Stearley wrote:
    >>At 2GHZ a test for NULL takes 0.5 nano seconds with nanoseconds being
    >>1e-9 seconds

    >
    >
    > A test is a single instruction. Then a non executed branch is another
    > instruction. The mips is the most recent CPU I can think of that has
    > an integrated cmp/branch instruction.
    >
    > The CPU is (most likely) super scaller so these instructions are
    > executing in parallel.
    >
    > I think that having to fetch 2 more instructions, branch prediction,
    > convert to internal RISC format (if this is an x86 taget) is going to
    > have a larger performance impact than actual execution
    >
    >
    >
    >>This program
    >>#include <stdlib.h>
    >>#include <stdio.h>
    >>#define MAXTRIES 1000000*10
    >>int main(void)
    >>{
    >> char *a;
    >>
    >> for (int i=0; i<MAXTRIES;i++) {
    >> a = malloc(123456);
    >> free(a);
    >> }
    >>}

    >
    >
    > What about the performance of the following code ?
    > The branch prediction inside of free isn't going to be that great.
    >
    > #include <stdlib.h>
    > #include <stdio.h>
    > #define MAXTRIES 1000000*10/2
    > int main(void)
    > {
    > char *a;
    >
    > for (int i=0; i<MAXTRIES;i++) {
    > a = malloc(123456);
    > free(a);
    > free(NULL);
    > }
    > }
    >

    It goes up from 3.484 to 3.687. But if I change the program to do
    #include <stdlib.h>
    #include <stdio.h>
    static void fn(void *p)
    {
    }

    #define MAXTRIES 1000000*10
    int main(void)
    {
    char *a;

    for (int i=0; i<MAXTRIES;i++) {
    a = malloc(123456);
    free(a);
    fn(NULL);
    }
    }

    The time stays the same... within measurements error.

    This means that the overhead of calling a
    function 10 million times is what is increasing the time here, and the
    difference between calling an empty function and calling malloc
    with NULL is zero

    probably it just make a return after it sees NULL, that's all.
    jacob navia, Oct 21, 2006
    #13
  14. CBFalconer posted:

    >> This way, you can use "free" whenever a null check would be
    >> redundant, saving 20 nanoseconds in execution time.

    >
    > Ridiculous. All you are doing is applying the same test twice.



    I don't understand you.

    The hypothetical "free" would not check for null.

    The hypothetical "FREE_SAFE" would check for null once.

    --

    Frederick Gotham
    Frederick Gotham, Oct 21, 2006
    #14
  15. Frederick Gotham

    ozbear Guest

    On Sat, 21 Oct 2006 08:40:22 GMT, Frederick Gotham
    <> wrote:

    >
    >Is it not inefficient to have allowed "free" to accept a null pointer? Would
    >it not have been better to disallow it, and to provide an auxiliary function
    >for times when its wanted:
    >
    >#define FREE_SAFE(p) ( (void)( (p) && free((p)) ) )
    >
    >--
    >
    >Frederick Gotham



    Invoking your FREE_SAFE macro above with an argument of malloc(10000)
    generates a nice memory leak.

    Oz
    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    ozbear, Oct 22, 2006
    #15
  16. "Eric Sosman" <> wrote in message
    news:...
    > Frederick Gotham wrote:
    >> Is it not inefficient to have allowed "free" to accept a null pointer?

    >
    > Terribly inefficient. Even worse is the fact that free()
    > is a function, thus incurring the overhead of marshalling the
    > argument, transferring control (possibly disrupting pipelines
    > and instruction caches), remembering a return address, maybe
    > saving some registers and/or doing a window turn with possible
    > stack spill, and then unwinding the whole thing when free()'s
    > business has been done. Pure overhead! Horrible to contemplate!
    > free() should have been an operator, as in That Other Language.
    > *Then* we'd finally get some efficiency!
    >
    > All right, class, let's turn the page. Next, we'll talk
    > about all the time printf() wastes interpreting format strings.
    > Who wants to go first?

    I waste an hour every time I have to lay eyes on the page in K&R with
    fprintf specifiers. EC
    Elijah Cardon, Oct 22, 2006
    #16
  17. Frederick Gotham

    SM Ryan Guest

    # > If it takes 20 nanoseconds for a particular machine to check if a
    # > pointer is null, then the execution time of your algorithm is extended by
    # > 20 nanoseconds for each time you call "free" (if every one of these null
    # > checks is redundan). Those 20 nanoseconds could have been reclaimed if
    # > "free" didn't check for null pointers.

    This is the same argument as to why Fortran didn't have
    zero trip DO loops. See also, etc etc etc.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    OOOOOOOOOO! NAVY SEALS!
    SM Ryan, Oct 22, 2006
    #17
  18. Frederick Gotham

    CBFalconer Guest

    Frederick Gotham wrote:
    > CBFalconer posted:
    >
    >>> This way, you can use "free" whenever a null check would be
    >>> redundant, saving 20 nanoseconds in execution time.

    >>
    >> Ridiculous. All you are doing is applying the same test twice.

    >
    > I don't understand you.
    >
    > The hypothetical "free" would not check for null.
    >
    > The hypothetical "FREE_SAFE" would check for null once.


    Are you just trolling? I posted an example of a free that checked
    for NULL, and you just snipped it. Every free must do this to meet
    the standards requirements.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Oct 22, 2006
    #18
  19. CBFalconer <> writes:
    > Frederick Gotham wrote:
    >> CBFalconer posted:
    >>>> This way, you can use "free" whenever a null check would be
    >>>> redundant, saving 20 nanoseconds in execution time.
    >>>
    >>> Ridiculous. All you are doing is applying the same test twice.

    >>
    >> I don't understand you.
    >>
    >> The hypothetical "free" would not check for null.
    >>
    >> The hypothetical "FREE_SAFE" would check for null once.

    >
    > Are you just trolling? I posted an example of a free that checked
    > for NULL, and you just snipped it. Every free must do this to meet
    > the standards requirements.


    He did say "hypothetical". The point of this thread is his suggestion
    that free() would be more efficent if it *didn't* check for a null
    pointer argument; the FREE_SAFE macro would do the check, and be more
    or less equivalent to the real-world free(). Obviously this would not
    conform to the actual standard.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Oct 22, 2006
    #19
  20. No he's not trolling.
    He's saying that his 'FREE_SAFE' macro does not result in the NULL
    check twice because the 'free' that its calling is a hypothetical free
    that lacks such a check.



    CBFalconer wrote:
    > Frederick Gotham wrote:
    > > CBFalconer posted:
    > >
    > >>> This way, you can use "free" whenever a null check would be
    > >>> redundant, saving 20 nanoseconds in execution time.
    > >>
    > >> Ridiculous. All you are doing is applying the same test twice.

    > >
    > > I don't understand you.
    > >
    > > The hypothetical "free" would not check for null.
    > >
    > > The hypothetical "FREE_SAFE" would check for null once.

    >
    > Are you just trolling? I posted an example of a free that checked
    > for NULL, and you just snipped it. Every free must do this to meet
    > the standards requirements.
    >
    > --
    > Chuck F (cbfalconer at maineline dot net)
    > Available for consulting/temporary embedded and systems.
    > <http://cbfalconer.home.att.net>
    Samuel Stearley, Oct 22, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Casey Hawthorne
    Replies:
    21
    Views:
    860
    Roedy Green
    Jun 5, 2004
  2. Bill Medland

    Pedantic JNI question

    Bill Medland, Oct 20, 2006, in forum: Java
    Replies:
    10
    Views:
    1,791
    Chris Uppal
    Oct 26, 2006
  3. jacob navia

    New -pedantic option for lcc-win32

    jacob navia, Sep 15, 2006, in forum: C Programming
    Replies:
    5
    Views:
    386
    Ben Pfaff
    Sep 16, 2006
  4. r.z.
    Replies:
    7
    Views:
    295
    Mirek Fidler
    Dec 19, 2006
  5. Replies:
    4
    Views:
    261
    Roland Dick
    Nov 9, 2007
Loading...

Share This Page