[LLVMdev] Language lawyer question

Patrick Meredith pmeredit at uiuc.edu
Tue Mar 11 21:47:12 PDT 2008


I thought pointer referencing like this was only valid for arrays.  I  
could be wrong,  but it might be that looping over the struct like that
is invalid, making it undefined behavior (and then the hole doesn't  
matter because there is no valid way to access it).  That said, I've  
definitely
seen a lot of code that uses pointers to reference struct contents.

On Mar 11, 2008, at 10:42 PM, Dale Johannesen wrote:

> Looking through the gcc testsuite turned up an interesting edge  
> case.  Let's assume our target leaves a hole for alignment in  
> struct x, as do x86 and powerpc.  Do you think the following code  
> can validly abort?
>
>   struct x { char c; short s; };
>   int i;    char *p;
>   memset(&X, 0, sizeof(struct x));
>   memset(&Y, 22, sizeof(struct x));
>   X = Y;
>   for (i=0, p=(char *)&X; i<sizeof(struct x); i++, p++)
>     if (*p != 22)
>       abort();
>
> The memset's and char-by-char comparison are clearly valid  
> references; the questionable bit is the struct copy, which llvm-gcc  
> currently does field-by-field, skipping the hole.  C99 says
>
> In simple assignment (=), the value of the right operand is  
> converted to the type of the
> assignment expression and replaces the value stored in the object  
> designated by the left
> operand.
>
> I would take "replaces the value" to mean "replaces the entire  
> value", but it could be read otherwise, I suppose.
>
> The current code seems to me to assume holes in structs can't ever  
> be validly accessed, which isn't right, as we see here.  They are  
> often nondeterministic (this is explicit for initialization in C99)  
> but not always.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080311/ef90cc14/attachment.html>


More information about the llvm-dev mailing list