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: 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:02:04 +0200	[thread overview]
Message-ID: <3D49A1CC.7080608@evision.ag> (raw)
In-Reply-To: Pine.GSO.4.21.0208011610020.12627-100000@weyl.math.psu.edu

Uz.ytkownik Alexander Viro napisa?:
> 
> On Thu, 1 Aug 2002, Thunder from the hill wrote:
> 
> 
>>Hi,
>>
>>On Wed, 31 Jul 2002, Alexander Viro wrote:
>>
>>>What the bleedin' hell is wrong with <name> <start> <len>\n - all in ASCII?  
>>>Terminated by \0.  No need for flags, no need for endianness crap, no
>>>need to worry about field becoming too narrow...
>>
>>Well, why not long[] fields? Might be more powerful, and possibly not any 
>>slower than ASCII.
> 
> 
> More powerful in which way?  I see where it's less powerful - sizeof(long)
> is platform-dependent and so is endianness.  More powerful?  Maybe, if
> you have integers that do not have decimal representation.  I've never
> heard of such beasts, but sure would appreciate some examples.
> 
> As for the Martin's comments...  Martin, if you can't write a function
> that checks whether array of characters has a contents fitting the
> description above - stand up and say so.  Aloud.  In public.

Actually you asked me to just shut up. Becouse I assume that you guessed
that I'm able to write the corresponding code?

I will anser anyway ;-)

Sure I'm able to do this. However if I hear the words parser I 
immediately think *complete* parsers in the formal sense.
Not a bunch of reg exp guessing. Neither do
I think about that error prone scanning for '\0' or fumbling
with xxx[strln(xxx)]. And yes using lex and yacc *is actually* easy
for me.

So unless you provide me with a... well for example, *complete* BNF
grammar definition of /proc I will always claim that using it or ASCII 
based interfaces is:

1. Not easy.

2. Like walking on moving sand.

Oh well: I will accept EBNF as well...

Looking at some structs relives one from this headache.


> The fact that thousands of selfstyled "programmers" manage to screw that
> up says only one thing - that they should not be allowed anywhere near
> programming.  Because the same guys screw up in _anything_ they do,
> no matter what data types are involved.  ASCII is tough?  Make it "arithmetics
> 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.)

It would have just duplicated the code size, becouse he would
have to do the ASCII parsing and additionaly he would
have to deal with moving offsets for reading the actual data.
Just more room for more mistakes.

The example above is a bad example to support your point therefore.
Actually it fires back. Like firing sharp rounds through
an AK47 with an exercise device still attached to the end of the pipe.

> Should we declare that arithmetics is dangerous?

It is it is... Dealing with the 5 axioms of peano leads you to
many many wired concepts. Like for example - infinity!!!


  parent reply	other threads:[~2002-08-01 21:03 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 [this message]
2002-08-01 21:27         ` Alexander Viro
2002-08-01 21:45           ` Marcin Dalecki
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=3D49A1CC.7080608@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