Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Passing structs by value

Reply
Thread Tools

Passing structs by value

 
 
Keith Thompson
Guest
Posts: n/a
 
      12-05-2005
pete <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>
>> (The set of representations
>> that are trap representations can vary over time during the execution
>> of the program.)

>
> How do you know that?


Because an implementation on which they can vary can be conforming.
(I'm not claiming that they'll do so on every implementation.)

For example:

void *ptr = malloc(32);
assert(ptr != NULL);
/*
* ptr has a valid value.
*/
free(ptr);
/*
* ptr may now contain a trap representation, even though the bits
* haven't changed.
*/

How does this violate the standard? If the standard intends that ptr
can't have a trap representation, why does it say the value is
indeterminate rather than unspecified? (The only difference between
indeterminate and unspecified is that the former includes trap
representations.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      12-05-2005
Jordan Abel wrote:
>
> On 2005-12-05, pete <(E-Mail Removed)> wrote:
> > Keith Thompson wrote:
> >
> >> (The set of representations
> >> that are trap representations
> >> can vary over time during the execution
> >> of the program.)

> >
> > How do you know that?

>
> Yeah -
> that is one of the more controversial of the "DS9K claims" - IMO
> up there with the "padding bits of DOOM" one elsethread.


I can find a reference for that one.

"Some combinations of padding bits might generate trap
representations, for example, if one padding bit is a parity bit."

But I don't see anything in the standard about trap representations,
which even suggests that trap representations
can change during the execution of a program.

The only reference to trap representations
connected with pointers is"

5 An integer may be converted to any pointer type.
Except as previously specified,
the result is implementation-defined,
might not be correctly aligned,
might not point to an entity of the referenced type,
and might be a trap representation.

I read the commas and the "and" of
"this, that, and the other"
as
"this, and that, and the other"
rather than as
"this, or (that, and the other)"

--
pete
 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      12-05-2005
Keith Thompson wrote:

> free(ptr);
> /*
> * ptr may now contain a trap representation, even though the bits
> * haven't changed.
> */
>
> How does this violate the standard? If the standard intends that ptr
> can't have a trap representation, why does it say the value is
> indeterminate rather than unspecified?


I don't know.

> (The only difference between
> indeterminate and unspecified is that the former includes trap
> representations.)


You might be right.
I believe they (the comp.std.c crowd and others here)
also say that a machine can trap on a pointer
over running an array,
which could be an example of a trap representation
that can change during the execution of a program.

--
pete
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      12-06-2005
On 2005-12-05, pete <(E-Mail Removed)> wrote:
> Jordan Abel wrote:
>>
>> On 2005-12-05, pete <(E-Mail Removed)> wrote:
>> > Keith Thompson wrote:
>> >
>> >> (The set of representations
>> >> that are trap representations
>> >> can vary over time during the execution
>> >> of the program.)
>> >
>> > How do you know that?

>>
>> Yeah -
>> that is one of the more controversial of the "DS9K claims" - IMO
>> up there with the "padding bits of DOOM" one elsethread.

>
> I can find a reference for that one.
>
> "Some combinations of padding bits might generate trap
> representations, for example, if one padding bit is a parity bit."


the "padding bits of doom" claim was that if you read out the
representation as unsigned chars, then copy it into another variable at
a later date, those padding bits might be valid anymore - i.e. the DS9K
might suddenly flip all padding bits to 1 and places with 0s would
suddenly become trap representations.

> But I don't see anything in the standard about trap representations,
> which even suggests that trap representations can change during the
> execution of a program.

 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-06-2005
On Mon, 05 Dec 2005 23:35:11 GMT, in comp.lang.c , pete
<(E-Mail Removed)> wrote:

>
>But I don't see anything in the standard about trap representations,
>which even suggests that trap representations
>can change during the execution of a program.


Absence of a mention merely means that the standard places no
requirements on it.
In this case, the definition of trap representation (6.2.6.1p5)
doesn't say that it may /not/ change during execution, so you can't
assume it remains constant.

>The only reference to trap representations
>connected with pointers is"
>
>5 An integer may be converted to any pointer type.
>Except as previously specified,
>the result is implementation-defined,
>might not be correctly aligned,
>might not point to an entity of the referenced type,
>and might be a trap representation.
>
>I read the commas and the "and" of
> "this, that, and the other"
>as
> "this, and that, and the other"


I believe it means that at least zero of the conditions might apply to
any instance of such a conversion.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
Reply With Quote
 
Alex Fraser
Guest
Posts: n/a
 
      12-06-2005
"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
[snip]
> 5 An integer may be converted to any pointer type.
> Except as previously specified,
> the result is implementation-defined,
> might not be correctly aligned,
> might not point to an entity of the referenced type,
> and might be a trap representation.
>
> I read the commas and the "and" of
> "this, that, and the other"
> as
> "this, and that, and the other"
> rather than as
> "this, or (that, and the other)"


I read the above as:

Except as previously specified,
the result is implementation defined,
[the result] might not be correctly aligned,
[the result] might not point to an entity of the referenced type, and
[the result] might be a trap representation.

Alex


 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      12-06-2005
Jordan Abel wrote:

> the "padding bits of doom" claim was that if you read out the
> representation as unsigned chars,
> then copy it into another variable at
> a later date, those padding bits might be valid anymore - i.e.
> the DS9K
> might suddenly flip all padding bits to 1 and places with 0s would
> suddenly become trap representations.


The value of the padding bits wouldn't change.
The problem would be if the trap representation changed.

--
pete
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      12-08-2005
(E-Mail Removed) (Richard Bos) writes:

> Keith Thompson <(E-Mail Removed)> wrote:
>
> > Jack Klein <(E-Mail Removed)> writes:
> > > On Mon, 5 Dec 2005 05:20:20 +0000 (UTC), Christopher Benson-Manica
> > > <(E-Mail Removed)> wrote in comp.lang.c:
> > >> Does the following program exhibit undefined behavior? Specifically,
> > >> does passing a struct by value cause undefined behavior if that struct
> > >> has as a member a pointer that has been passed to free()?
> > >
> > > I'm not sure why you make a distinction between a pointer in a
> > > structure passed by value, and a bare pointer passed by value. Also
> > > I'm not sure why you make a distinction between a pointer that has an
> > > indeterminate value because it is uninitialized, or because it points
> > > to previously allocated storage that has been freed.
> > >
> > >> #include <stdlib.h>
> > >>
> > >> struct stype
> > >> {
> > >> int *foo;
> > >> };
> > >>
> > >> void bar( struct stype foo )
> > >> {
> > >> }
> > >>
> > >> int main( void )
> > >> {
> > >> struct stype baz;
> > >> baz.foo=malloc( sizeof *baz.foo );
> > >> free( baz.foo );
> > >> bar( baz ); /* UB or not? */
> > >> return 0;
> > >> }
> > >
> > > In several places, the C standard refers to function call arguments
> > > being stored into the function's parameters by assignment. So passing
> > > anything to a function in C is essentially the same as assigning it to
> > > the function's local parameter value.
> > >
> > > Assignment in C is always based on value, so passing anything with
> > > indeterminate value, other than an unsigned char, to a function is
> > > undefined behavior, as is any other use of the value of such an
> > > object. It makes no difference whether the object with indeterminate
> > > value is part of a structure, nor does it make any difference how the
> > > value became indeterminate.

> >
> > But DR #222 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_222.htm>
> > says:
> >
> > The value of a struct or union object is never a trap
> > representation, even though the value of a member of a struct or
> > union object may be a trap representation.

>
> That's weird. I would've thought this would only make sense for unions,
> not structs. [...stuff about unions...]
>
> For a struct, this is much simpler: all members must be valid for it to
> be a valid object. Assigning a non-trap value to a single struct member
> is already guaranteed not to assign a trap value to any other member of
> the struct, unlike in unions.


Pshaw. Do you mean to say that for

struct small_stack_of_int {
int values[100];
int first_empty_slot;
};

that all elements of the 'values' array must have been assigned, even
if the relation 'first_empty_slot == 0' is true?

It makes perfect sense for struct objects to be partially valid, with
one field (or sometimes more) indicating which other fields may be
accessed. The pattern is quite common, showing up in various kinds
of buffers all the time.

The rule in the DR, and now in n1124, is IMO the most sensible
expression for how non-completely-valid structs should be
expected to behave.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Packed structs vs. unpacked structs: what's the difference? Daniel Rudy C Programming 15 04-10-2006 08:10 AM
Array of structs instead of an array with pointers to structs? Paminu C Programming 5 10-11-2005 07:18 PM
length of an array in a struct in an array of structs in a struct in an array of structs Tuan Bui Perl Misc 14 07-29-2005 02:39 PM
const structs in other structs Chris Hauxwell C Programming 6 04-27-2004 07:03 PM
structs with fields that are structs Patricia Van Hise C Programming 5 04-05-2004 01:37 AM



Advertisments