Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 6 Nov 2001 18:39:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 6 Nov 2001 18:39:28 -0500 Received: from sweetums.bluetronic.net ([66.57.88.6]:54423 "EHLO sweetums.bluetronic.net") by vger.kernel.org with ESMTP id ; Tue, 6 Nov 2001 18:39:12 -0500 Date: Tue, 6 Nov 2001 18:39:01 -0500 (EST) From: Ricky Beam X-X-Sender: To: cc: Erik Andersen , Linux Kernel Mail List Subject: Re: PROPOSAL: dot-proc interface [was: /proc stuff] In-Reply-To: <20011106224753.7D45EA3B90@fancypants.trellisinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Nov 2001 dank@trellisinc.com wrote: >"code poet?" you've plucked an 80 from the air. regardless of what the >kernel prints now and how it's limited (deep within drivers/block/genhd.c), >there is no reference to this silent 63 via either explicit comment or >pure code. your code remains happily ignorant of any modification to this >postcondition, and when that changes (as it surely will), you lose. it's >uninspired coding like the above that keeps the buffer overflow >technique alive. Exactly. Just because the code _currently_ won't generate more than 63 chars doesn't mean it always will. And who says the application will see the true, kernel generated "/proc/partitions"? >c string processing is all of doable, mature, and meticulous. "done >properly by beginners" is not how i would describe it. Experience shows beginners rarely get thing right the first time out. (Or the second or third time if they are like some of my previous students.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/