public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcin Dalecki <dalecki@evision.ag>
To: Alexander Viro <viro@math.psu.edu>
Cc: martin@dalecki.de, Thunder from the hill <thunder@ngforever.de>,
	Peter Chubb <peter@chubb.wattle.id.au>,
	Pavel Machek <pavel@ucw.cz>,
	Matt_Domsch@Dell.com, Andries.Brouwer@cwi.nl,
	linux-kernel@vger.kernel.org
Subject: Re: 2.5.28 and partitions
Date: Thu, 01 Aug 2002 23:45:50 +0200	[thread overview]
Message-ID: <3D49AC0E.9070804@evision.ag> (raw)
In-Reply-To: Pine.GSO.4.21.0208011709390.12627-100000@weyl.math.psu.edu

Uz.ytkownik Alexander Viro napisa?:
> 
> Newsflash: for Homsky-3 grammar "reg exp guessing" _IS_ complete parser
> in the formal sense.

Unsually only unless you compre it with your *intentions*.
Please don't confuse definition of grammar with parser implementation
despite that fact the reg-exp stuff is looking like declarative
programming. Whot it does is *not* always equivalent to what it should.
OK?

>>>is tough".  Examples on demand, including real gems like
>>>	fread(&foo, sizeof(foo), 1, fp);
>>>	if (foo.x >= 100000 || foo.y >= 100000)
>>>		/* fail and exit */
>>>	p = (char *)malloc(foo.x * foo.y);
>>>	if (!p)
>>>		/* fail and exit */
>>>	for (i = 0; i < foo.x; i++)
>>>		fread(p + i*foo.y. 1, foo.y, fp);
>>>and similar wonders (if anybody wonders what's wrong with the code above,
>>>you need to learn how multiplication is defined on int and compare 10^10 with
>>>2^32).  And yes, it's real-life code, from often-used programs.  Used on
>>>untrusted data, at that.
>>
>>Storing the constants in question in the above code sample
>>as ASCII at the start of where foo is pointing at, would have hardly
>>saved the poor overworked programmers mind from precisely the same
>>mistake he did above. (Needless to say that you actually forgott
>>to mention that the code fails on <= 32 bit systems. Inestad of 
>>providing te "hint" for guessing where the actual error is.)
> 
> 
> Huh???
> 
> you: "it's easy to screw up when working with ASCII strings"
> me: "tossers will find a way to screw up on anything, no matter what it is;
>      see example of tosser screwing up on plain arithmetics"
> you: "use of ASCII wouldn't help them in that case"
> 

Scratch the above: I tell you: "Not unsing ASCII is greatly
diminishing the propability of the occurrance of the error."
And error rate depends on the size of code. No matter how
perfect you think someone has to be as a coder.
  No code - no errors. The same buggy code twice - twice the same errors.

> Sure thing, it wouldn't.  _Nothing_ short of acquiring some clue would.
> Possible solutions:
> 	A) replace all arithmetics with BIGNUMs (and just you wait for
> first out-of-memory)
> 	B) get rid of tossers.
> 
> Matter of taste, indeed, but I'd rather go for (B) - has a benefit of
> solving many other problems.

No. The vomitting only moves to the time where you actually get your ass 
up from the kernel and take a look at the code trying to use it. And 
then it's more painfull. Go libproc or its relatives please. I don't
blaim Albert for it! I blaim the interface.
I don't try to tell you that binary interfaces are the best thing
since slice bread. They are just less worse for the *actual* user.

That's the point.


  reply	other threads:[~2002-08-01 21:47 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <15688.25919.138565.6427@wombat.chubb.wattle.id.au>
2002-07-31 22:39 ` 2.5.28 and partitions Alexander Viro
2002-08-01 10:08   ` Marcin Dalecki
2002-08-01 12:31     ` Kai Henningsen
2002-08-01 19:29   ` Thunder from the hill
2002-08-01 20:31     ` Alexander Viro
2002-08-01 20:45       ` Thunder from the hill
2002-08-01 21:08         ` Alexander Viro
2002-08-01 21:25           ` Marcin Dalecki
2002-08-01 21:41             ` Alexander Viro
2002-08-02 19:40               ` Mike Touloumtzis
2002-08-01 21:02       ` Marcin Dalecki
2002-08-01 21:27         ` Alexander Viro
2002-08-01 21:45           ` Marcin Dalecki [this message]
2002-08-02  5:21           ` Ryan Anderson
2002-08-01 21:24       ` Albert D. Cahalan
2002-08-02 19:47         ` Mike Touloumtzis
2002-08-02 20:49           ` Albert D. Cahalan
2002-08-02 21:21             ` Mike Touloumtzis
2002-08-02 21:36               ` [RFC] " Thunder from the hill
2002-08-02 22:12               ` Albert D. Cahalan
2002-08-02 22:53                 ` Mike Touloumtzis
2002-08-02 14:54 Jesse Pollard
2002-08-02 18:33 ` Kai Henningsen
     [not found] <15688.27022.143541.447952@wombat.chubb.wattle.id.au>
2002-07-31 23:42 ` Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2002-07-31 23:38 Matt_Domsch
     [not found] <F44891A593A6DE4B99FDCB7CC537BBBBB839AC@AUSXMPS308.aus.amer .dell.com>
2002-07-31 22:58 ` Anton Altaparmakov
2002-07-31 22:47 Matt_Domsch
2002-07-25 17:50 Andries.Brouwer
2002-07-25 13:24 Petr Vandrovec
2002-07-25 13:45 ` Anton Altaparmakov
2002-07-26  5:13   ` Adrian Bunk
2002-07-25 12:43 Petr Vandrovec
2002-07-25  3:22 Matt_Domsch
2002-07-25  5:27 ` Linus Torvalds
2002-07-25 11:44   ` Alexander Viro
2002-07-25 15:57     ` Linus Torvalds
2002-07-30  9:58     ` Pavel Machek
     [not found]   ` <Pine.GSO.4.21.0207250739390.17037-100000@weyl.math.psu.edu >
2002-07-25 13:03     ` Anton Altaparmakov
2002-07-25 16:50       ` Alexander Viro
2002-07-25 17:35         ` Jason L Tibbitts III
2002-07-25 17:57         ` Rik van Riel
2002-07-25 18:27           ` Alexander Viro
2002-07-27  5:56         ` Austin Gonyou
     [not found]       ` <Pine.GSO.4.21.0207251245530.17621-100000@weyl.math.psu.edu >
2002-07-25 17:39         ` Anton Altaparmakov
2002-07-25 10:42 ` Alan Cox
2002-07-24 22:42 Andries.Brouwer
2002-07-24 23:42 ` Alexander Viro
2002-07-25  0:20   ` kwijibo
2002-07-25  4:00   ` Jason L Tibbitts III
     [not found] ` <Pine.GSO.4.21.0207241925450.14656-100000@weyl.math.psu.edu >
2002-07-25  2:11   ` Anton Altaparmakov
2002-07-25  5:15     ` Linus Torvalds
     [not found]     ` <Pine.LNX.4.44.0207242213540.1231-100000@home.transmeta.com >
2002-07-25  8:43       ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D49AC0E.9070804@evision.ag \
    --to=dalecki@evision.ag \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=Matt_Domsch@Dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@dalecki.de \
    --cc=pavel@ucw.cz \
    --cc=peter@chubb.wattle.id.au \
    --cc=thunder@ngforever.de \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox