cygwin programs again: realloc() segfaults with library v1.3.1

[friedman_hill ernest j]

The author of this code is apparently confused about how realloc()
works. realloc() takes a pointer to a memory block and a new size. It
tries to grow the block in place, but if it fails, it allocates a new
block, copies the old contents, frees the old block, and returns a
pointer to the new block. But in the code you're shown below, the
author always writes something like this:

        realloc(args.basedir, strlen(argv[argp + 1]) + 1);
        strcpy(args.basedir, argv[argp + 1]);

after the first call, it is entirely possible that args.basedir points
to unallocated memory. Every call to realloc should be written like
this:

        args.basedir =
           (char *) realloc(args.basedir, strlen(argv[argp + 1]) + 1);
        strcpy(args.basedir, argv[argp + 1]);
   
Now, strictly, you should check args.basedir for 0 before using it,
since 0 is returned if the the allocation failed, and this assigning
right back into args.basedir is wrong too since if 0 is returned, the
original block is leaked. But the code you've shown already assumes
that malloc never fails, so I don't know what error-handling scheme to
use. But a "real" program should do something like this:

        void * ptr =
           realloc(args.basedir, strlen(argv[argp + 1]) + 1);
        if (ptr == 0)
           reportFailureAndExit("realloc");
        args.basedir = (char *) ptr;
        strcpy(args.basedir, argv[argp + 1]);


In any event, this has NOTHING to do with cygwin -- it's just faulty
code. It also just happens to be the case that on the code's author's
system, realloc rarely if ever moves memory, while on yours, cygwin
often needs to. Que sera, sera.


I think Thunder from the hill wrote:
[Charset utf-8 unsupported, filtering to ASCII...]
> I hate this mailer! I think I should better use another one.
> 
> Again, this is the failing source code. Whenever realloc() is used in
> sendfile(), the MicroHTTPD segfaults.
> 
> Thunder
> 
> System:
> AMD K6-II 400
> Windows NT 4.0 with latest cygwin                        --> uhttpd problem
> Self-compiled Linux with self-compiled programs    --> uhttpd seems to work
> when running as root, else chroot() fails with ENOPERM. (sure, since only
> root may chroot().)
> VIIB graphic card
> SB Live!
> 

[Attachment, skipping...]

> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple



---------------------------------------------------------
Ernest Friedman-Hill  
Distributed Systems Research        Phone: (925) 294-2154
Sandia National Labs                FAX:   (925) 294-2234
Org. 8920, MS 9012                  ejfried@ca.sandia.gov
PO Box 969                  http://herzberg.ca.sandia.gov
Livermore, CA 94550

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple