Subject: Re: How to add a support function to libc
To: Allen Briggs <briggs@ninthwonder.com>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-userlevel
Date: 10/19/2000 10:14:57
briggs@ninthwonder.com (Allen Briggs) writes:
> This is a naming and namespace question...
(personally i'd prefer the args in opposite order -- template first,
if you will -- but you didn't ask that.)
> I'd like to add a function to libc that will be used in some calls
> to printf() functions. Such as:
>
> printf(newfunction(user_format, "%s %ld %d"),
> string_arg, long_arg, int_arg);
>
> This function will be used in libraries and programs to ensure that
> the user_format is compatible with the supplied arguments. The
> assumption being that this would be used when user_format comes from
> some untrusted location--perhaps a message catalog.
great.
> I think the function should live in libc/stdio, next to the printf(3)
> family, but I'm not sure where it should be prototyped, or how it
> should be named to avoid namespace collisions (I'm not clear on which
> namespaces are reserved for whom).
>
> The working name for the function is __fmtcheck(), prototyped as
>
> const char *__fmtcheck __P((const char *, const char *))
> __attribute__((__format_arg__(2)));
Strongly suggest you pick a name not starting with __.
While it's great to use something in the implementation namespace for
solely internal purposes only, this is code that's meant to be called
from user programs too, is it not? If so, it should be in the normal
user namespace -- just not prototyped in the headers if standards are
in force, and aliased in libc and used internally in the aliased form.
the problem is, if you use an implementation namespace name, then that
means that it's harder -- or potentially impossible -- to portably
stub around the calls in programs that need to be made portable.
> So what's the correct approach? My naive approach is to just drop
> the prototype in the "Routines that are purely local" section of
> stdio.h (with fgetln, fpurge, et al.). Instruction in a less
> naive approach welcome.
That is the correct approach, in my opinion. But it should be a
normally-named function, not starting with __.
chris