Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs) - Linux

This is a discussion on Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs) - Linux ; Ezekiel wrote: > The primary reason for checking the return of malloc() is to exit gracefully > or to handle the error. Precisely. > If malloc() fails then it'll return a NULL pointer back to you. Any attempt > to ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

  1. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

    Ezekiel wrote:
    > The primary reason for checking the return of malloc() is to exit gracefully
    > or to handle the error.


    Precisely.


    > If malloc() fails then it'll return a NULL pointer back to you. Any attempt
    > to use that pointer (ie - dereference it and read or write through it) will
    > crash the app. Not checking the return value of malloc() will *NOT* lead to
    > any viruses. If malloc() works you get a pointer to valid memory. If
    > malloc() fails then you get a NULL pointer that is useless. Failure to check
    > may cause the program to crash. But it will not introduce some sort of
    > security risk.



    Well, security risk or not, it'll certainly crash your app.

    ptr=malloc(len);
    if(ptr)
    {
    // do some stuff
    free(ptr);
    }

    What's difficult about that? It was lesson number one in dynamic memory
    usage on my c++ course.

    Not checking it is bad programming practice.

  2. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    Phil Da Lick! wrote:

    >Ezekiel wrote:
    >>
    >> The primary reason for checking the return of malloc() is to exit gracefully
    >> or to handle the error.

    >
    >Precisely.


    Well, duh. I'm not a pro programmer, but even I know this basic
    stuff, whether it's malloc or fopen or whatever.


  3. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    Phil Da Lick! espoused:
    > Ezekiel wrote:
    >> The primary reason for checking the return of malloc() is to exit gracefully
    >> or to handle the error.

    >
    > Precisely.
    >
    >
    >> If malloc() fails then it'll return a NULL pointer back to you. Any attempt
    >> to use that pointer (ie - dereference it and read or write through it) will
    >> crash the app. Not checking the return value of malloc() will *NOT* lead to
    >> any viruses. If malloc() works you get a pointer to valid memory. If
    >> malloc() fails then you get a NULL pointer that is useless. Failure to check
    >> may cause the program to crash. But it will not introduce some sort of
    >> security risk.

    >
    >
    > Well, security risk or not, it'll certainly crash your app.
    >
    > ptr=malloc(len);
    > if(ptr)
    > {
    > // do some stuff
    > free(ptr);
    > }
    >
    > What's difficult about that? It was lesson number one in dynamic memory
    > usage on my c++ course.
    >
    > Not checking it is bad programming practice.


    Snap - one of the first things I learnt about using C 20 years ago was
    to check what malloc returned. It's not difficult.

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  4. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

    chrisv wrote:
    > Phil Da Lick! wrote:
    >
    >> Ezekiel wrote:
    >>> The primary reason for checking the return of malloc() is to exit gracefully
    >>> or to handle the error.

    >> Precisely.

    >
    > Well, duh. I'm not a pro programmer, but even I know this basic
    > stuff, whether it's malloc or fopen or whatever.
    >


    What's shocking is that something as big as flash can *possibly* be
    exploited because the programmers didn't check the return value!

  5. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    "Phil Da Lick!" writes:

    > chrisv wrote:
    >> Phil Da Lick! wrote:
    >>
    >>> Ezekiel wrote:
    >>>> The primary reason for checking the return of malloc() is to exit
    >>>> gracefully or to handle the error.
    >>> Precisely.

    >>
    >> Well, duh. I'm not a pro programmer, but even I know this basic
    >> stuff, whether it's malloc or fopen or whatever.
    >>

    >
    > What's shocking is that something as big as flash can *possibly* be
    > exploited because the programmers didn't check the return value!


    Whats even more shocking is that you still do not understand the fact
    that on Linux it would not matter a fig ....


    Buffer overruns etc are far more important to check.

  6. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

    Hadron wrote:
    > "Phil Da Lick!" writes:
    >
    >> chrisv wrote:
    >>> Phil Da Lick! wrote:
    >>>
    >>>> Ezekiel wrote:
    >>>>> The primary reason for checking the return of malloc() is to exit
    >>>>> gracefully or to handle the error.
    >>>> Precisely.
    >>> Well, duh. I'm not a pro programmer, but even I know this basic
    >>> stuff, whether it's malloc or fopen or whatever.
    >>>

    >> What's shocking is that something as big as flash can *possibly* be
    >> exploited because the programmers didn't check the return value!

    >
    > Whats even more shocking is that you still do not understand the fact
    > that on Linux it would not matter a fig ....
    >
    >
    > Buffer overruns etc are far more important to check.


    Why are you mentioning linux again? Please point out the post in which I
    state this would not be a problem in linux.

    Perhaps you should learn some basic understanding eh?

  7. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    On 2008-04-23, Mark Kent wrote:
    > Phil Da Lick! espoused:
    >> Ezekiel wrote:
    >>> The primary reason for checking the return of malloc() is to exit gracefully
    >>> or to handle the error.

    >>
    >> Precisely.
    >>
    >>
    >>> If malloc() fails then it'll return a NULL pointer back to you. Any attempt
    >>> to use that pointer (ie - dereference it and read or write through it) will
    >>> crash the app. Not checking the return value of malloc() will *NOT* lead to
    >>> any viruses. If malloc() works you get a pointer to valid memory. If
    >>> malloc() fails then you get a NULL pointer that is useless. Failure to check
    >>> may cause the program to crash. But it will not introduce some sort of
    >>> security risk.

    >>
    >>
    >> Well, security risk or not, it'll certainly crash your app.
    >>
    >> ptr=malloc(len);
    >> if(ptr)
    >> {
    >> // do some stuff
    >> free(ptr);
    >> }



    I'd prefer to do it this way:

    if ((ptr=malloc(len)) == NULL) {
    printf("Malloc Failure");
    return 1;
    }

    >>
    >> What's difficult about that? It was lesson number one in dynamic memory
    >> usage on my c++ course.
    >>
    >> Not checking it is bad programming practice.

    >
    > Snap - one of the first things I learnt about using C 20 years ago was
    > to check what malloc returned. It's not difficult.


    I always do. It's one of the first things you learn. Another is to keep
    track of your hanging pointers. I usually assign them to NULL.

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  8. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    Mark Kent wrote:

    >Phil Da Lick! espoused:
    >>
    >> What's difficult about that? It was lesson number one in dynamic memory
    >> usage on my c++ course.
    >>
    >> Not checking it is bad programming practice.

    >
    >Snap - one of the first things I learnt about using C 20 years ago was
    >to check what malloc returned. It's not difficult.


    Well, you guys probably didn't attend the prestigious William H. Gates
    College of Crapware.


  9. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    ____/ chrisv on Wednesday 23 April 2008 13:41 : \____

    > Mark Kent wrote:
    >
    >>Phil Da Lick! espoused:
    >>>
    >>> What's difficult about that? It was lesson number one in dynamic memory
    >>> usage on my c++ course.
    >>>
    >>> Not checking it is bad programming practice.

    >>
    >>Snap - one of the first things I learnt about using C 20 years ago was
    >>to check what malloc returned. It's not difficult.

    >
    > Well, you guys probably didn't attend the prestigious William H. Gates
    > College of Crapware.


    CoC? Like Cocaine? That college must be getting kids addicted.

    But you know what they say...


    First one's free! (gratis)

    --
    ~~ Best of wishes

    Roy S. Schestowitz | Warning 0x12C: ispell feels tired
    http://Schestowitz.com | GNU is Not UNIX | PGP-Key: 0x74572E8E
    http://iuron.com - proposing a non-profit search engine

  10. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

    chrisv wrote:
    > Mark Kent wrote:
    >
    >> Phil Da Lick! espoused:
    >>> What's difficult about that? It was lesson number one in dynamic memory
    >>> usage on my c++ course.
    >>>
    >>> Not checking it is bad programming practice.

    >> Snap - one of the first things I learnt about using C 20 years ago was
    >> to check what malloc returned. It's not difficult.

    >
    > Well, you guys probably didn't attend the prestigious William H. Gates
    > College of Crapware.
    >


    lol

  11. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)


    "Gregory Shearman" wrote in message
    news:slrng0tvvh.8g7.ZekeGregory@netscape.net...
    > On 2008-04-23, Mark Kent wrote:
    >> Phil Da Lick! espoused:
    >>> Ezekiel wrote:
    >>>> The primary reason for checking the return of malloc() is to exit
    >>>> gracefully
    >>>> or to handle the error.
    >>>
    >>> Precisely.
    >>>
    >>>
    >>>> If malloc() fails then it'll return a NULL pointer back to you. Any
    >>>> attempt
    >>>> to use that pointer (ie - dereference it and read or write through it)
    >>>> will
    >>>> crash the app. Not checking the return value of malloc() will *NOT*
    >>>> lead to
    >>>> any viruses. If malloc() works you get a pointer to valid memory. If
    >>>> malloc() fails then you get a NULL pointer that is useless. Failure to
    >>>> check
    >>>> may cause the program to crash. But it will not introduce some sort of
    >>>> security risk.
    >>>
    >>>
    >>> Well, security risk or not, it'll certainly crash your app.
    >>>
    >>> ptr=malloc(len);
    >>> if(ptr)
    >>> {
    >>> // do some stuff
    >>> free(ptr);
    >>> }

    >
    >
    > I'd prefer to do it this way:
    >
    > if ((ptr=malloc(len)) == NULL) {
    > printf("Malloc Failure");
    > return 1;
    > }



    This will only work if you do your malloc() inside of main() which is
    somewhat unusual. Most likely the malloc() is burried deep down several
    function calls. What exactly is the point of returning an arbitrary "1" from
    some function that's nested several calls deep.

    If the point is to exit then the code you would want is:

    if ((ptr=malloc(len)) == NULL) {
    printf("Malloc Failure");
    exit(1);
    }

    If the point is to "exit" on memory failure then you exit... you don't
    "return" 1 when you're deep in the call stack.




    >>>
    >>> What's difficult about that? It was lesson number one in dynamic memory
    >>> usage on my c++ course.
    >>>
    >>> Not checking it is bad programming practice.

    >>
    >> Snap - one of the first things I learnt about using C 20 years ago was
    >> to check what malloc returned. It's not difficult.

    >
    > I always do. It's one of the first things you learn. Another is to keep
    > track of your hanging pointers. I usually assign them to NULL.
    >
    > --
    > Regards,
    >
    > Gregory.
    > Gentoo Linux - Penguin Power



    ** Posted from http://www.teranews.com **

  12. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)


    "Mark Kent" wrote in message
    news:ds13e5-qes.ln1@ellandroad.demon.co.uk...
    > Phil Da Lick! espoused:
    >> Ezekiel wrote:
    >>> The primary reason for checking the return of malloc() is to exit
    >>> gracefully
    >>> or to handle the error.

    >>
    >> Precisely.
    >>
    >>
    >>> If malloc() fails then it'll return a NULL pointer back to you. Any
    >>> attempt
    >>> to use that pointer (ie - dereference it and read or write through it)
    >>> will
    >>> crash the app. Not checking the return value of malloc() will *NOT* lead
    >>> to
    >>> any viruses. If malloc() works you get a pointer to valid memory. If
    >>> malloc() fails then you get a NULL pointer that is useless. Failure to
    >>> check
    >>> may cause the program to crash. But it will not introduce some sort of
    >>> security risk.

    >>
    >>
    >> Well, security risk or not, it'll certainly crash your app.
    >>
    >> ptr=malloc(len);
    >> if(ptr)
    >> {
    >> // do some stuff
    >> free(ptr);
    >> }
    >>
    >> What's difficult about that? It was lesson number one in dynamic memory
    >> usage on my c++ course.
    >>
    >> Not checking it is bad programming practice.


    >
    > Snap - one of the first things I learnt about using C 20 years ago was
    > to check what malloc returned. It's not difficult.


    Then why are the developers of Evolution too lazy to check the return value?



    e-util/e-error.c

    *** Return value NOT checked ***
    domain = alloca(strlen(tag)+1);
    strcpy(domain, tag);



    mail/e-searching-tokenizer.c

    ignore_tag (const char *tag)
    {
    *** Return value NOT checked ***
    char *t = alloca(strlen(tag)+1), c, *out;
    const char *in;
    int i;


    static void dump_trie(struct _state *s, int d)
    {
    *** Return value NOT checked ***
    char *p = alloca(d*2+1);


    static struct _searcher * search_info_to_searcher(struct _search_info *si)
    {
    *** Return value NOT checked ***
    tags = alloca(20+strlen(col));


    *** Return value NOT checked ***
    tage = alloca(20);



    mail/em-account-editor.c

    static gboolean emae_check_complete(EConfig *ec, const char *pageid, void
    *data)

    *** Return value NOT checked ***
    template = alloca(len + 14);
    strcpy(template, tmp);


    mail/em-format-html-display.c

    static void efhd_update_matches(EMFormatHTMLDisplay *efhd)

    if (p->search_dialog) {
    *** Return value NOT checked ***
    str = alloca(strlen(fmt)+32);
    sprintf(str, fmt, e_searching_tokenizer_match_count(efhd->search_tok));


    mail/em-format.c

    const EMFormatHandler *em_format_fallback_handler(EMFormat *emf, const char
    *mime_type)
    *** Return value NOT checked ***
    mime = alloca(len+2);
    strncpy(mime, mime_type, len);
    strcpy(mime+len, "*");





    ** Posted from http://www.teranews.com **

  13. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    "Ezekiel" writes:

    > "Mark Kent" wrote in message
    > news:ds13e5-qes.ln1@ellandroad.demon.co.uk...
    >> Phil Da Lick! espoused:
    >>> Ezekiel wrote:
    >>>> The primary reason for checking the return of malloc() is to exit
    >>>> gracefully
    >>>> or to handle the error.
    >>>
    >>> Precisely.
    >>>
    >>>
    >>>> If malloc() fails then it'll return a NULL pointer back to you. Any
    >>>> attempt
    >>>> to use that pointer (ie - dereference it and read or write through it)
    >>>> will
    >>>> crash the app. Not checking the return value of malloc() will *NOT* lead
    >>>> to
    >>>> any viruses. If malloc() works you get a pointer to valid memory. If
    >>>> malloc() fails then you get a NULL pointer that is useless. Failure to
    >>>> check
    >>>> may cause the program to crash. But it will not introduce some sort of
    >>>> security risk.
    >>>
    >>>
    >>> Well, security risk or not, it'll certainly crash your app.
    >>>
    >>> ptr=malloc(len);
    >>> if(ptr)
    >>> {
    >>> // do some stuff
    >>> free(ptr);
    >>> }
    >>>
    >>> What's difficult about that? It was lesson number one in dynamic memory
    >>> usage on my c++ course.
    >>>
    >>> Not checking it is bad programming practice.

    >
    >>
    >> Snap - one of the first things I learnt about using C 20 years ago was
    >> to check what malloc returned. It's not difficult.

    >
    > Then why are the developers of Evolution too lazy to check the return value?
    >


    Almost the entire Gnome toolkit ignores the return value too. Reason?
    Well if malloc fails for 20 bytes then the chance of Gregory's "printf"
    working are about zero.

    FWIW, I do check it.

  14. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)


    "Hadron" wrote in message
    news:funrpc$41p$1@registered.motzarella.org...
    > "Ezekiel" writes:
    >
    >> "Mark Kent" wrote in message
    >> news:ds13e5-qes.ln1@ellandroad.demon.co.uk...
    >>> Phil Da Lick! espoused:
    >>>> Ezekiel wrote:
    >>>>> The primary reason for checking the return of malloc() is to exit
    >>>>> gracefully
    >>>>> or to handle the error.
    >>>>
    >>>> Precisely.
    >>>>
    >>>>
    >>>>> If malloc() fails then it'll return a NULL pointer back to you. Any
    >>>>> attempt
    >>>>> to use that pointer (ie - dereference it and read or write through it)
    >>>>> will
    >>>>> crash the app. Not checking the return value of malloc() will *NOT*
    >>>>> lead
    >>>>> to
    >>>>> any viruses. If malloc() works you get a pointer to valid memory. If
    >>>>> malloc() fails then you get a NULL pointer that is useless. Failure to
    >>>>> check
    >>>>> may cause the program to crash. But it will not introduce some sort of
    >>>>> security risk.
    >>>>
    >>>>
    >>>> Well, security risk or not, it'll certainly crash your app.
    >>>>
    >>>> ptr=malloc(len);
    >>>> if(ptr)
    >>>> {
    >>>> // do some stuff
    >>>> free(ptr);
    >>>> }
    >>>>
    >>>> What's difficult about that? It was lesson number one in dynamic memory
    >>>> usage on my c++ course.
    >>>>
    >>>> Not checking it is bad programming practice.

    >>
    >>>
    >>> Snap - one of the first things I learnt about using C 20 years ago was
    >>> to check what malloc returned. It's not difficult.

    >>
    >> Then why are the developers of Evolution too lazy to check the return
    >> value?
    >>

    >
    > Almost the entire Gnome toolkit ignores the return value too. Reason?
    > Well if malloc fails for 20 bytes then the chance of Gregory's "printf"
    > working are about zero.


    That's one of the pitfalls of what to do if malloc() fails. Most likely your
    app is in dire trouble so doing something like calling printf() (which
    allocates a buffer internally) is also likely to fail.


    > FWIW, I do check it.


    I do... but indirectly. Most of what I do now is C++ so malloc() has been
    replaced with 'new' which throws an out of memory exception if it fails. So
    there's no need to directly check the return value from new() since an
    exception gets thrown if it fails. You still need to catch the exception if
    you want to handle it gracefully but then it's back to the first issue of is
    there enough memory to do much of anything.

    When I did (or occasionally do) use "C" with malloc() we generally wrap
    malloc in our own wrapper. We have something like safe_malloc() that is
    guaranteed to return a valid pointer or the safe_malloc() function will
    handle the error itself and terminate the app. This way safe_malloc() always
    does the check and the rest of the code doesn't have to.

    Generally something like "safe_malloc()" gets used nearly all of the time.
    There are exceptions for when we would want to use malloc() directly if we
    want to allocate a large amount of memory for example. In that case we do
    check the return value because we expect that it could legitimately fail and
    we don't want to terminate. If it fails we could do something like remove
    data from caches or even allocate less memory than we desire and work with
    what we get.

    I have seen malloc() fail even though there was ample memory available. It's
    possible to have a large amount of free memory available but malloc() could
    fail if you try to allocate say 4-Megs. The available memory might be
    fragmented so while there is 100's of megs of memory available, there is no
    contiguous piece that's 4-Megs.



    ** Posted from http://www.teranews.com **

  15. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime,320 Million Zombie PCs)

    Ezekiel wrote:
    > e-util/e-error.c
    >
    > *** Return value NOT checked ***
    > domain = alloca(strlen(tag)+1);
    > strcpy(domain, tag);


    argggh! unclean!



  16. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    * Ezekiel peremptorily fired off this memo:

    >> Snap - one of the first things I learnt about using C 20 years ago was
    >> to check what malloc returned. It's not difficult.

    >
    > Then why are the developers of Evolution too lazy to check the return value?
    >
    > e-util/e-error.c
    >
    > *** Return value NOT checked ***
    > domain = alloca(strlen(tag)+1);
    > strcpy(domain, tag);
    >
    > mail/e-searching-tokenizer.c
    > char *t = alloca(strlen(tag)+1), c, *out;
    >
    > char *p = alloca(d*2+1);
    > tags = alloca(20+strlen(col));
    > tage = alloca(20);
    >
    > mail/em-account-editor.c
    >
    > template = alloca(len + 14);
    >
    > mail/em-format-html-display.c
    >
    > str = alloca(strlen(fmt)+32);
    >
    > mail/em-format.c
    >
    > mime = alloca(len+2);


    Dumbass, why don't you just read ALLOCA(3)?

    RETURN VALUE
    The alloca() function returns a pointer to the beginning of
    the allocated space. If the allocation causes stack
    overflow, program behavior is undefined.

    Idiot.

    --
    I'm sorry that we have to have a Washington presence. We thrived during our
    first 16 years without any of this. I never made a political visit to
    Washington and we had no people here. It wasn't on our radar screen. We were
    just making great software.
    -- Bill Gates

  17. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    * Phil Da Lick! peremptorily fired off this memo:

    > Ezekiel wrote:
    >> e-util/e-error.c
    >>
    >> *** Return value NOT checked ***
    >> domain = alloca(strlen(tag)+1);
    >> strcpy(domain, tag);

    >
    > argggh! unclean!


    You got tooled by that stump-jumping furrow-walkin' micro-cephalic Zeke
    character.

    man alloca

    --
    If I'd had some set idea of a finish line, don't you think I would have
    crossed it years ago?
    -- Bill Gates

  18. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)


    "Linonut" wrote in message
    news:LX1Qj.31216$tG6.30758@bignews1.bellsouth.net. ..
    >* Ezekiel peremptorily fired off this memo:
    >
    >>> Snap - one of the first things I learnt about using C 20 years ago was
    >>> to check what malloc returned. It's not difficult.

    >>
    >> Then why are the developers of Evolution too lazy to check the return
    >> value?
    >>
    >> e-util/e-error.c
    >>
    >> *** Return value NOT checked ***
    >> domain = alloca(strlen(tag)+1);
    >> strcpy(domain, tag);
    >>
    >> mail/e-searching-tokenizer.c
    >> char *t = alloca(strlen(tag)+1), c, *out;
    >>
    >> char *p = alloca(d*2+1);
    >> tags = alloca(20+strlen(col));
    >> tage = alloca(20);
    >>
    >> mail/em-account-editor.c
    >>
    >> template = alloca(len + 14);
    >>
    >> mail/em-format-html-display.c
    >>
    >> str = alloca(strlen(fmt)+32);
    >>
    >> mail/em-format.c
    >>
    >> mime = alloca(len+2);

    >
    > Dumbass, why don't you just read ALLOCA(3)?
    >
    > RETURN VALUE
    > The alloca() function returns a pointer to the beginning of
    > the allocated space. If the allocation causes stack
    > overflow, program behavior is undefined.
    >
    > Idiot.



    If the behavior not defined then why do you assume that it won't return
    NULL?


    http://www.rt.com/man/alloca.3.html

    ALLOCA(3) Linux Programmer's Manual ALLOCA(3)


    RETURN VALUES
    The alloca function returns a pointer to the beginning of
    the allocated space. If the allocation failed, a NULL
    pointer is returned.



    http://www.hmug.org/man/3/alloca.php

    DESCRIPTION
    The alloca() function allocates size bytes of space in the stack frame
    of the caller. This temporary space is automatically freed on return.

    RETURN VALUES
    The alloca() function returns a pointer to the beginning of the
    allocated space. If the allocation failed, a NULL pointer is returned.




    http://www.mkssoftware.com/docs/man3/alloca.3.asp

    DESCRIPTION
    The alloca() function allocates space in the stack frame of the caller,
    and returns a pointer to the allocated block. This temporary space is
    automatically freed when the function from which alloca() is called returns.

    RETURN VALUES
    The alloca() function returns a null pointer if there is insufficient
    memory.

    CONFORMANCE
    4.4BSD



    http://code.google.com/p/yardparser/wiki/StackOverflow

    alloca is defined to return a void*, and if there is not enough space on the
    stack, it is supposed to return NULL.... Unfortunately, many implementations
    of alloca never return NULL, so this does not work on those platforms.



    Then again it seems that some apps (asterisk) do check the return value of
    alloca(). So do you think that those developers stupid?

    http://www.asterisk.org/doxygen/1.2/cdr__pgsql_8c.html

    00097 /* Maximum space needed would be if all characters needed to be
    escaped, plus a trailing NULL */
    00098 if ((clid = alloca(strlen(cdr->clid) * 2 + 1)) != NULL)
    00099 PQescapeStringConn(conn, clid, cdr->clid, strlen(cdr->clid),
    &pgerr);
    00100 if ((dcontext = alloca(strlen(cdr->dcontext) * 2 + 1)) != NULL)
    00101 PQescapeStringConn(conn, dcontext, cdr->dcontext,
    strlen(cdr->dcontext), &pgerr);
    00102 if ((channel = alloca(strlen(cdr->channel) * 2 + 1)) != NULL)
    00103 PQescapeStringConn(conn, channel, cdr->channel,
    strlen(cdr->channel), &pgerr);
    00104 if ((dstchannel = alloca(strlen(cdr->dstchannel) * 2 + 1)) !=
    NULL)
    00105 PQescapeStringConn(conn, dstchannel, cdr->dstchannel,
    strlen(cdr->dstchannel), &pgerr);
    00106 if ((lastapp = alloca(strlen(cdr->lastapp) * 2 + 1)) != NULL)
    00107 PQescapeStringConn(conn, lastapp, cdr->lastapp,
    strlen(cdr->lastapp), &pgerr);
    00108 if ((lastdata = alloca(strlen(cdr->lastdata) * 2 + 1)) != NULL)
    00109 PQescapeStringConn(conn, lastdata, cdr->lastdata,
    strlen(cdr->lastdata), &pgerr);
    00110 if ((uniqueid = alloca(strlen(cdr->uniqueid) * 2 + 1)) != NULL)
    00111 PQescapeStringConn(conn, uniqueid, cdr->uniqueid,
    strlen(cdr->uniqueid), &pgerr);
    00112 if ((userfield = alloca(strlen(cdr->userfield) * 2 + 1)) !=
    NULL)
    00113 PQescapeStringConn(conn, userfield, cdr->userfield,
    strlen(cdr->userfield), &pgerr);
    00114 if ((src = alloca(strlen(cdr->src) * 2 + 1)) != NULL)
    00115 PQescapeStringConn(conn, src, cdr->src, strlen(cdr->src),
    &pgerr);
    00116 if ((dst = alloca(strlen(cdr->dst) * 2 + 1)) != NULL)
    00117 PQescapeStringConn(conn, dst, cdr->dst, strlen(cdr->dst),
    &pgerr);






    > --
    > I'm sorry that we have to have a Washington presence. We thrived during
    > our
    > first 16 years without any of this. I never made a political visit to
    > Washington and we had no people here. It wasn't on our radar screen. We
    > were
    > just making great software.
    > -- Bill Gates




  19. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    In article ,
    Linonut wrote:
    > >
    > > Then why are the developers of Evolution too lazy to check the return value?
    > >
    > > e-util/e-error.c
    > >
    > > *** Return value NOT checked ***
    > > domain = alloca(strlen(tag)+1);
    > > strcpy(domain, tag);
    > >
    > > mail/e-searching-tokenizer.c
    > > char *t = alloca(strlen(tag)+1), c, *out;
    > >
    > > char *p = alloca(d*2+1);
    > > tags = alloca(20+strlen(col));
    > > tage = alloca(20);
    > >
    > > mail/em-account-editor.c
    > >
    > > template = alloca(len + 14);
    > >
    > > mail/em-format-html-display.c
    > >
    > > str = alloca(strlen(fmt)+32);
    > >
    > > mail/em-format.c
    > >
    > > mime = alloca(len+2);

    >
    > Dumbass, why don't you just read ALLOCA(3)?
    >
    > RETURN VALUE
    > The alloca() function returns a pointer to the beginning of
    > the allocated space. If the allocation causes stack
    > overflow, program behavior is undefined.
    >
    > Idiot.


    Last time I checked, Evolution runs on a variety of Unix and Unix-like
    systems, and I've even seen talk of a Windows version. Not all alloca
    implementations behave the same:

    RETURN VALUES
    The alloca() function returns a pointer to the beginning of the
    allocated space. If the allocation failed, a NULL pointer is
    returned.

    --
    --Tim Smith

  20. Re: [News] [Rival] The MSBBC on the 'Windows Ecosystem' (Cybercrime, 320 Million Zombie PCs)

    * Subway steel peremptorily fired off this memo:

    >>> mail/em-format.c
    >>>
    >>> mime = alloca(len+2);

    >>
    >> Dumbass, why don't you just read ALLOCA(3)?
    >>
    >> RETURN VALUE
    >> The alloca() function returns a pointer to the beginning of
    >> the allocated space. If the allocation causes stack
    >> overflow, program behavior is undefined.
    >>
    >> Idiot.

    >
    > If the behavior not defined then why do you assume that it won't return
    > NULL?


    Ay yi yi!

    The behavior is undefined. You don't even know if the function will be
    returning.

    > http://www.rt.com/man/alloca.3.html
    >
    > ALLOCA(3) Linux Programmer's Manual ALLOCA(3)
    >
    > RETURN VALUES
    > The alloca function returns a pointer to the beginning of
    > the allocated space. If the allocation failed, a NULL
    > pointer is returned.


    Dude, that's from 1993. Try a recent GNU version.

    > http://www.hmug.org/man/3/alloca.php


    That one's also from 1993, and it is BSD, not GNU.

    > http://www.mkssoftware.com/docs/man3/alloca.3.asp
    >
    > CONFORMANCE
    > 4.4BSD


    Ditto. And that's not a UNIX one.

    > http://code.google.com/p/yardparser/wiki/StackOverflow
    >
    > Then again it seems that some apps (asterisk) do check the return value of
    > alloca(). So do you think that those developers stupid?


    No. They are smart. However, not checking the return value of alloca()
    is /not/ stupid or unwise.

    Funny how you had to go all over the web to find contradictions to what
    I can find on my own machine, and your man pages are wayyyyyyy out of
    date.

    --
    No! There are no significant bugs in our released software that any
    significant number of users want fixed.
    -- Bill Gates, http://www.cantrip.org/nobugs.html

+ Reply to Thread
Page 1 of 2 1 2 LastLast