network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 8 months |
| seen | Apr 15 at 22:45 | |
| stats | profile views | 0 |
|
Jan 14 |
awarded | Announcer |
|
Sep 10 |
comment |
Deleting a Java Object securely @Thomas Pornin To nitpick a bit ;) Theoretically one can avoid the GC problems, the "solutions" are just somewhat.. complicated or need a compliant API. #1: ByteBuffer.allocateDirect(). #2: Use an unsafe object to allocate the necessary memory and craft your own char[] or string. #1 obviously only works with an API that would use CharBuffers (ugh) and #2 has more than enough problems (though I've wrote a small app once to win a bet). But in both situations you get memory that is not allocated on the GC heaps and therefore not copied around if you use a stop© GC. |
|
Sep 10 |
awarded | Supporter |
|
Sep 10 |
comment |
How should I compile program for fuzz testing?You want to have a configuration in the test where you do not get saved by the enhanced debug checks like app verifier or the malloc_check stuff - but since every problem one of those two finds is (or should) be a bug that has to be fixed anyhow, wouldn't this only increase the chances to crash? You may crash at a different position (ie most likely earlier), but you'd still find the bug. The only problem I'd see is with undefined behavior that results in different code, but other than that I usually use the debug builds. |
