Connecting Tech Pros Worldwide Forums | Help | Site Map

Re: A question of programming technique in C

Ben Bacarisse
Guest
 
Posts: n/a
#1: Nov 5 '08
cri@tiac.net (Richard Harter) writes:
Quote:
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Eric.Sosman@sun.comwrote:
>
Quote:
>>Richard Harter wrote:
>
[snip]
>
Quote:
Quote:
>>>
>>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.
<snip>
Quote:
Quote:
> But the "unrestricted 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."
>
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.

Richard Harter
Guest
 
Posts: n/a
#2: Nov 5 '08

re: Re: A question of programming technique in C


On Wed, 05 Nov 2008 13:46:51 +0000, Ben Bacarisse
<ben.usenet@bsb.me.ukwrote:
Quote:
>cri@tiac.net (Richard Harter) writes:
>
Quote:
>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
><Eric.Sosman@sun.comwrote:
>>
Quote:
>>>Richard Harter wrote:
>>
>[snip]
>>
Quote:
>>>>
>>>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.
><snip>
Quote:
Quote:
>> But the "unrestricted 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."
>>
>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!
See reply to Eric.


Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
Closed Thread