[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2017 18:58:30 -0400
From: Morten Welinder <mwelinder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] stdio: implement fopencookie(3)
> Also note that while standard functions in POSIX can additionally be
> defined as function-like macros, they can't be object-like macros, so
> (*read), etc. are safe due to the parentheses.
I'm not sure that's true. Solaris defines (or used to, at least),
say, "open" to "open64" under the right conditions. With that, actual
field names in the structure ends up being dependent on #include
order. Quite a mess and worse for "stat" since "struct stat" gets
renamed in addition to the function.
"#define open my_table.my_open" would be fun too. I haven't seen that
in the wild, though.
M.
On Tue, Oct 10, 2017 at 4:56 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Oct 10, 2017 at 08:51:17PM +0200, Jens Gustedt wrote:
>> Hello William,
>>
>> On Tue, 10 Oct 2017 18:03:56 +0000 William Pitcock
>> <nenolod@...eferenced.org> wrote:
>>
>> > The fopencookie(3) function allows the programmer to create a custom
>> > stdio implementation, using four hook functions which operate on a
>> > "cookie" data type.
>>
>> I know it is not your fault, but the naming conventions in this new
>> interface are realy bad design.
>>
>> > +typedef struct {
>> > + ssize_t (*read)(void *cookie, char *buf, size_t size);
>> > + ssize_t (*write)(void *cookie, const char *buf, size_t size);
>> > + int (*seek)(void *cookie, off_t *offset, int whence);
>> > + int (*close)(void *cookie);
>> > +} cookie_io_functions_t;
>>
>> > +FILE *fopencookie(void *cookie, const char *mode, cookie_io_functions_t io_funcs);
>>
>> The members may clash with macro names. E.g an implementation would be
>> allowed to overload "close" with a macro. This is not possible if the
>> implementation would want to use this interface here at the same time.
>>
>> User code could legitimately want to use a macro "seek" for its own
>> purpose.
>>
>> Could you at least avoid to use user-space names as function
>> parameters? Here you should just omit cookie, buf, size, offset,
>> whence, mode and io_funcs. I think in musl parameters in prototypes
>> usually don't have names. If you think that we should have them (they
>> sort of document the interface) you should put them into a reserved
>> namespace with leading underscore or so, or at least prefix them with
>> cookie_
>
> I agree with most of the principles here (esp. how bad the public
> interface of this function is), but there's not a whole lot that can
> be done. Your one request is reasonable and in fact mandatory for musl
> header policy: we do not use parameter named at all in prototypes. So
> it should read just:
>
> FILE *fopencookie(void *, const char *, cookie_io_functions_t);
>
> Also note that while standard functions in POSIX can additionally be
> defined as function-like macros, they can't be object-like macros, so
> (*read), etc. are safe due to the parentheses.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
