Skip to Content.
Sympa Menu

svadev - Re: [svadev] safecode and alloca(0)

svadev AT lists.siebelschool.illinois.edu

Subject: Svadev mailing list

List archive

Re: [svadev] safecode and alloca(0)


Chronological Thread 
  • From: John Criswell <criswell AT illinois.edu>
  • To: Matthew Wala <wala1 AT illinois.edu>
  • Cc: svadev AT cs.uiuc.edu
  • Subject: Re: [svadev] safecode and alloca(0)
  • Date: Tue, 22 Nov 2011 21:48:35 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/svadev>
  • List-id: <svadev.cs.uiuc.edu>
  • Organization: University of Illinois at Urbana-Champaign

On 11/22/2011 6:48 PM, Matthew Wala wrote:
Why does SAFECode allow malloc(0) but disallows alloca(0)?

Hrm. I'm not sure if this is really what SAFECode *should* do, but I can think of some reasons why it does it.

I think malloc(0) does occur in some programs, and SAFECode could easily handle it by changing the allocation size to 1 in the poolalloc() function back when it was always using the pool allocator run-time. This cannot be done with allocas since alloca is an LLVM instruction and emitted straight to machine code.

It may also be the case that malloc(0) is correct (return a pointer to zero-sized storage) while alloca(0) is not, but I'd have to check the LLVM docs to be certain.

I think the correct thing to do now is to first determine whether malloc(0) and alloca(0) are allowed and, if so, permit the pool_register() and pool_register_stack() (and their variants) to register zero-sized objects.

That said, this is extremely low priority unless you're seeing a program that is breaking because of it. Unless SAFECode is breaking a correct program, you should just file a bug report, and we'll get back to it when we have time. Testing SAFECode out on larger programs is higher priority at present as well as fixing more serious bugs such as PR#11414 and PR#11423.

-- John T.



Matt
_______________________________________________
svadev mailing list
svadev AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/svadev





Archive powered by MHonArc 2.6.16.

Top of Page