This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Mixed use of delete with malloc in fclose


Hi All,

During searching a bug in our firmware (which was not related to ecos)
I stumbled accross this minor inconsitency (which does not have an effect
in our setup because the operator delete in libsupc++ of our gcc uses
free internally):

In packages/language/c/libc/stdio/current/src/common/fopen.cxx
line 172 (in Revision 1.9 - HEAD) memory is alloced with malloc and object is
constructed with placement new:

    // Allocate it some memory and construct it.
    curr_stream = (Cyg_StdioStream *)malloc(sizeof(*curr_stream));
    if (curr_stream == NULL) {
        cyg_stdio_close( dev );
        Cyg_libc_stdio_files::unlock();
        errno = ENOMEM;
        return NULL;
    } // if

    curr_stream = new ((void *)curr_stream) Cyg_StdioStream( dev, open_mode,
                                                             append, binary,
                                                             bufmode, bufsize );

But fclose frees memory useing delete (if it not overwritten with empty stubs).
Please not that the (void *) cast at the new statement is also useless.
For a proposed patch please see the attachment.

    -Guenter

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Attachment: fclose_delete.patch
Description: Binary data

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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