cri@tiac.net (Richard Harter) writes:
<snip>
>
As it happens, I am quite familiar with the concept and the
technique, but I didn't mention it explicitly because I took it
for granted that bobble.h would provide an incomplete type.
I too was going to mention the technique until I saw Eric's reply
because in your sketch you said:
| we have definitions like
|
| struct bobble_s {...};
|
| in our bobble.h.
OK, it is only a sketch, but the {}s will suggest to any C programmer
that you are not thinking of using an incomplete type. Eric's
suggesting it is, in my opinion, entirely reasonable!
--
Ben.
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Eric.Sosman@su n.comwrote:
>
>
[snip]
>
<Eric.Sosman@su n.comwrote:
>
>>Richard Harter wrote:
[snip]
>
>>>
>>The problem is that C pointers are fragile, that they carry no
>>certificate of validity, and that they provide unrestricted
>>access to the struct contents.
>>The problem is that C pointers are fragile, that they carry no
>>certificate of validity, and that they provide unrestricted
>>access to the struct contents.
> But the "unrestrict ed access" issue is easily dealt with, in
>>the sense that the contents can be made "opaque." The tradition-
>>honored technique in C is for your "bobble.h" to omit any mention
>>of the elements of a struct bobble_s. You can declare a function
>>as accepting a struct bobble_s* as an argument or returning one
>>as a result without revealing what a struct bobble_s looks like,
>>or even revealing its size. See "incomplete type."
>>the sense that the contents can be made "opaque." The tradition-
>>honored technique in C is for your "bobble.h" to omit any mention
>>of the elements of a struct bobble_s. You can declare a function
>>as accepting a struct bobble_s* as an argument or returning one
>>as a result without revealing what a struct bobble_s looks like,
>>or even revealing its size. See "incomplete type."
As it happens, I am quite familiar with the concept and the
technique, but I didn't mention it explicitly because I took it
for granted that bobble.h would provide an incomplete type.
because in your sketch you said:
| we have definitions like
|
| struct bobble_s {...};
|
| in our bobble.h.
OK, it is only a sketch, but the {}s will suggest to any C programmer
that you are not thinking of using an incomplete type. Eric's
suggesting it is, in my opinion, entirely reasonable!
--
Ben.
Comment