Re: An alternative way of populating /proc

From: dean gaudet (dgaudet-list-linux-kernel@arctic.org)
Date: Wed Apr 12 2000 - 15:36:43 EST


On Wed, 12 Apr 2000, bert hubert wrote:

> On Wed, Apr 12, 2000 at 12:46:25AM -0700, dean gaudet wrote:
>
> > is the real concern codesize and you're totally willing to throw away
> > type checking and such?
>
> If you mess up, things will break the second you populate /proc.

hmm, how is that? there's no type checking, you could easily store an
integer where a string is expected.

> This might
> also work to detect an excess of arguments, or a lack thereoff:
>
> i = create_proc_entries(NULL, /* create in root /proc */
> "test:{bar:{x:%d,y:%d,z:%d},foo-r:%f}",
> &x, &y, &z, foo_fun, (void *)&somedata,
> CREATE_PROC_TERMINATOR);
>
> And insert a line like this in the right place:
>
> BUG(va_arg(*args_ptr, int)!=CREATE_PROC_TERMINATOR);

solves one of a million problems with printf/scanf-style varargs typeless
stuff.

On Wed, 12 Apr 2000, bert hubert wrote:

> On Wed, Apr 12, 2000 at 12:43:17PM +0200, Olaf Titz wrote:
>
> > You can even have the compiler check the format string against the
> > arguments with some __attribute__ magic. This alone is reason enough
> > to keep it as shown above, printf-compatible.
>
> No you can't. It's not printf, it's scanf magic in this case, and gcc does
> not appear to feature a % argument that expects a pointer to a function.

is my point making any more sense yet? :) printf/scanf are total special
cases and gcc supports them. it's a generally bad style of programming
though whose only saving grace is that it can produce small code. hence
my original question.

-dean

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:19 EST