Re: new/delete overloading, why?
sön 2010-08-22 klockan 17:18 +1200 skrev Amos Jeffries: We should add a small compiler unit-test into configure for a while before removing either way. No guess work then. Do you mean a unit-test to test if the compiler warns about free() abuses on data allocated by new? Regards Henrik
Re: new/delete overloading, why?
Henrik Nordström wrote: lör 2010-08-21 klockan 07:02 +1200 skrev Robert Collins: it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. Allocating with new and freeing with free() is a coding error in all books. There may be nothing like that left to worry about now. I sure hope not. valgrind reports it as an error. I think I recall seeing gcc 4.3+ report it as a warning which we catch with -Werror. The older ones (ala gcc 2.* and 3.* did not AFAIK, thus the high potential for flashing lights and sound effects). Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
Re: new/delete overloading, why?
lör 2010-08-21 klockan 20:26 +1200 skrev Amos Jeffries: Henrik Nordström wrote: lör 2010-08-21 klockan 07:02 +1200 skrev Robert Collins: it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. Allocating with new and freeing with free() is a coding error in all books. There may be nothing like that left to worry about now. I sure hope not. valgrind reports it as an error. I think I recall seeing gcc 4.3+ report it as a warning which we catch with -Werror. The older ones (ala gcc 2.* and 3.* did not AFAIK, thus the high potential for flashing lights and sound effects). So you argree that there should be nothing like that left to worry about? Regards Henrik
Re: new/delete overloading, why?
Henrik Nordström wrote: lör 2010-08-21 klockan 20:26 +1200 skrev Amos Jeffries: Henrik Nordström wrote: lör 2010-08-21 klockan 07:02 +1200 skrev Robert Collins: it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. Allocating with new and freeing with free() is a coding error in all books. There may be nothing like that left to worry about now. I sure hope not. valgrind reports it as an error. I think I recall seeing gcc 4.3+ report it as a warning which we catch with -Werror. The older ones (ala gcc 2.* and 3.* did not AFAIK, thus the high potential for flashing lights and sound effects). So you argree that there should be nothing like that left to worry about? I'm torn both ways. We should add a small compiler unit-test into configure for a while before removing either way. No guess work then. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
Re: new/delete overloading, why?
2010/8/21 Henrik Nordström hen...@henriknordstrom.net: Why are we overloading new/delete with xmalloc/xfree? include/SquidNew.h this is causing random linking issues every time some piece of code forgets to include SquidNew.h, especially when building helpers etc. And I fail to see what benefit we get from overloading the new/delete operators in this way. it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. There may be nothing like that left to worry about now. -Rob
Re: new/delete overloading, why?
lör 2010-08-21 klockan 07:02 +1200 skrev Robert Collins: it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. Allocating with new and freeing with free() is a coding error in all books. There may be nothing like that left to worry about now. I sure hope not. Regards Henrik
