[15933] in bugtraq
Re: StackGuard with ... Re: [Paper] Format bugs.
daemon@ATHENA.MIT.EDU (Valentin Nechayev)
Mon Jul 24 14:56:10 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000724131631.B40510@lucky.net>
Date: Mon, 24 Jul 2000 13:16:32 +0300
Reply-To: netch@lucky.net
From: Valentin Nechayev <netch@LUCKY.NET>
X-To: Brett Glass <brett@LARIAT.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <4.3.2.7.2.20000721224040.04b04b90@localhost>; from
brett@LARIAT.ORG on Fri, Jul 21, 2000 at 10:48:57PM -0600
Fri, Jul 21, 2000 at 22:48:57, brett wrote about "Re: StackGuard with ... Re: [Paper] Format bugs.":
> Which brings up a more interesting question:
>
> Don't these errors really reflect more fundamental problems in the
> development tools? It seems to me that the bugs arose because:
>
> 1) Format strings in the C libraries use a sort of "in-band signalling" --
> that is, they can mix text with format designators. This means that
> passing the text you want to print as the format string produces results
> that appear to be correct.
Well, but it is programmers' and code checking problem.
It is easy to make mistake of another class with the same result.
> 2) The C language itself has no way of specifying a MINIMUM number of
> arguments for a function call. Had the compiler noted that setproctitle()
> and similar functions need at least two arguments, the mistakes would
> have been caught from the get-go.
What version of C you mean?
Possibly it is true for K&R, but for ANSI it is wrong.
When one writes prototype such as
int fooprintf( foo_t* foo, const char* format, ... )
first 2 arguments are strongly specified and fixed.
> The former requires changing the conventions used by the standard C
> libraries, which is probably infeasible.
It is IMHO really needed to include something similar to GCC's
__attribute((format(*printf))) to C standard. All another aspects can be
handled with exiting features.
