From owner-freebsd-hackers Wed Jan 17 07:00:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA14812 for hackers-outgoing; Wed, 17 Jan 1996 07:00:56 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA14807 for ; Wed, 17 Jan 1996 07:00:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA14936 for ; Wed, 17 Jan 1996 07:00:28 -0800 To: hackers@freebsd.org Subject: Change to stdio.h to export `cookie?' Date: Wed, 17 Jan 1996 07:00:28 -0800 Message-ID: <14934.821890828@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Those users of our stdio's funopen() call are already familiar with the cookie I'm talking about - it's a magic variable in the FILE struct which you can set to things for the benefit of your own I/O functions. The only problem is that the API designers didn't provide a hook for getting/setting it, leading to code which makes assumptions about the inside of the FILE structure. I don't know if anyone's ever ported MH to a new stdio architecture, but programs which make assumptions about the internals of stdio are EVIL and should be banned. In the case of the cookie, it's worse since there's no other way to fiddle with it and fiddle with it you have to if you want to actually use it as the designers intended. Any objections to an accessor macro being added to stdio.h? I don't like extra namespace pollution any more than the next guy, but it seems cleaner to me than fiddling in the FILE struct. Comments? Total lack thereof will also result in me making this change to -current in a couple of days, so speak up now please! Jordan