[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] substring function and bounds checks
From: |
Michele La Monaca |
Subject: |
Re: [Chicken-hackers] substring function and bounds checks |
Date: |
Wed, 6 Feb 2013 19:20:28 +0100 |
Hi Peter,
wow! What a long and articulate response! Thanks for that, I really
appreciate the time and effort you put in it. I also understand (and
appreciate again) your attempt to inculcate in me a different way of
thinking, but unfortunately, at least for now, my antibodies are at
work. Maybe one day... for now I am just comfortable with my few
little beliefs. Excuse me if I have been somehow rude but, you know,
we both have strong ideas.
Today is my boring gym day, so I have to condense my reply somehow
and, anyway, I don't want to repeat myself over and over. As I said:
(substring1 "foo" 0 10) -> bump
(substring2 "foo" 0 10) -> "foo"
are both legitimate scheme substring functions from what I can tell.
You say the first is the "non-sloppy", "safer" one, I just say they
have a different semantic and I do notice that we have a rather
different concept of safety. Indeed, I don't think
(substring2 "foo" 0 10) -> "foo"
is conceptually wrong or sloppy as long as you know exactly what the
semantic of the function is ("give me at most N chars" -> perl or
"give me chars up to the Nth position or up to the end of the string
whatever the first" -> python, ruby).
Regarding the practical aspects of the issue, I hope you might agree
with me that substring2 if far superior to substring1. Having to catch
exceptions, or having to write a wrapper function, as Jim suggested,
to achieve a minimal sane usage of substring1 (and hey we are not
talking about the apollo11-land-on-the-moon-button function), should
give you a sense of the inadequacy of the substring function currently
shipped with chicken.
Anyway, as you suggested, maybe it is just too early for me... let's
see. (I hope) I am the kind of person which periodically reconsider
without preconceptions his beliefs and principles, though, admittedly,
I am rather defensive at the beginning.
Thanks to the community for all the kind responses.
Regards,
Michele
On Wed, Feb 6, 2013 at 10:21 AM, Peter Bex <address@hidden> wrote:
> On Wed, Feb 06, 2013 at 12:55:16AM +0100, Michele La Monaca wrote:
>> What I can say... Well, maybe one day I will see the light, in the
>> meanwhile I would just have preferred a more useful substring
>> function. I really think that the one provided by chicken is simply
>> not on par with other languages, sorry.
>
> This is not a question of being "on par" or not. Some other languages
> choose to have nonsensical requests like "give me characters 0
> through 10 from this 3-character string" to return the original string.
>
> Substring is a silly and trivial example but it clearly illustrates the
> deep fundamental differences in philosophy between the different
> cultures of these languages.
>
> The most valuable gift a computer programming language can give you is
> the ability to reason about a piece of code without extra information.
> For example, if you see (substring s 0 10) you immediately *know* in
> any code that follows:
>
> - The variable s is a string
> - The string s is at least 10 characters long
> - The returned value is a string
> - The returned string is exactly 10 characters long
>
> If none of the above are true, you'll have an error situation and
> the code following the substring call will not be executed.
> In "sloppy" languages, you lose several of these important footholds,
> which means you can't reason so well about your code's correctness
> anymore, except by reading back and dragging in more context.
>
> The above guarantees mean, for example, that if later you see
> (string-ref s 8) this will *always* return a character. In your
> other languages, you won't know what exactly it'll do. You'll have two
> lines of possible future traces through your program: one where there
> was a character and one where there wasn't. Multiply this by every
> sloppy operator you use and you end up with a tangled web of possible
> futures. Often, only one of those futures is what you had in mind when
> writing code. The other possibilities produce wrong computations, which
> may result in data corruption or security problems.
>
> Sloppiness promotes muddled thinking and imprecise code. Imprecise
> code is prone to bugs, which may lead to security problems. This may
> not be fair, but I think a particularly good example is the 2 recent
> extremely dangerous vulnerabilities in Ruby on Rails which allowed for
> remote code execution.
>
> What caused these problems to happen? Misplaced convenience and
> sloppiness: Rails allowed Yaml data to be embedded in XML and JSON,
> which automatically got parsed. Of course, XML and JSON are their own
> formats and their specifications don't mention anything about Yaml.
> This means a Yaml parser has nothing, and I mean *nothing* to do in
> an XML parser. It may be convenient in a small set of cases, but
> it's just another case of adding more magic: it's not something you
> asked for, so it shouldn't happen.
>
> For another good example of the deep confusion caused by code that
> is sloppy by design, read https://bugs.php.net/bug.php?id=54547
> Read it, and also note that the list of bizarre and unexpected
> consequences includes, yet again, security implications.
> At least, it's unexpected to users from different programming cultures,
> expecting programming languages to be precise.
>
> Still not convinced? Look at the incredulity of the Postgres community
> in response to being shown MySQL's sloppy behavior:
> http://www.postgresql.org/message-id/address@hidden
> Fundamentally. Different. Cultures.
>
> I understand you're only asking about strings, but this sort of thing
> needs to be considered in the wider cultural context, and Schemers
> prefer precision and correctness over sloppiness and second-guessing.
>
>> The semantic of a
>> commonly-found substring function "give me at most N chars starting
>> from a certain position in the string" is the most useful according
>> me. I don't see any evil in that.
>
> See above, consider the profound implications of widespread culturally
> encouraged sloppiness. This is a really important insight that should
> not be dismissed out of hand for its apparent triviality. It's
> fundamental to every program you write in a language.
>
>> The chicken (scheme?) alternative
>> "give me exactly N chars or blow up" is rather limited in scope to me.
>
> It's a substring procedure. It *should* be limited in scope. It should
> "do one thing, and do it well". The Unix community learned that lesson
> well after the deluge of flags that Berkeley added to cat(1).
> If you want a slicing procedure that includes a kitchen sink, that can
> be easily added on top of such precise, simple basics, as shown by the
> "slice" egg. If you think that's too bloated, you can include the
> trivial substring/n procedure Jim posted.
>
>> > Scheme is about correctness. If you provide invalid indices, you get
>> > errors.
>>
>> Well, in the real world you can't always predict input and therefore
>> you must do checks.
>
> As has been pointed out before, you'll need to add back extra checks if
> you rely on the sloppy behavior and want to make it more precise, in
> order to reason about it properly. The main problem is that it's
> awfully tempting to "forget" to add proper checks, and now you have
> another security problem that snuck into your system.
>
> Being precise is a virtue when telling a computer what to do. If you
> omit important details, an attacker will provide them to the computer
> for you.
>
>> Either you leave this burden to the user or you kindly provide this
>> even-cobol-has-it feature.
>
> It's a misfeature. This is like arguing that "1" + 2 not returning 3
> is a "even Javascript provides it" feature and Scheme should add it.
> We disagree, it's a bad idea. This is fundamental to the culture of
> a particular programming language and you're simply not going to get
> one culture to agree that the values of another culture must be adopted
> wholesale.
>
> If you fundamentally disagree with the culture, you're programming in
> the wrong language. If you're still learning the language, like when
> visiting a foreign country, you should delay judgement based on
> preconceptions and try to understand the language's underlying culture
> first before suggesting making radical differences to the language.
>
>> >This will help you detect bugs early on instead of just keep going on with a
>> >bad result of an incorrect computation until some other thing fails much
>> >farther along. This kind of thing also tends to sneak in vulnerabilities,
>> >as
>> >you never *really* know what your code will do in the face of
>> >inconsistencies.
>> >"fail early and noisily" is good design.
>>
>> To me, this only means more bloated, unreadable code in the best case,
>> unfriendly crashes in the worst one.
>
> Like it was pointed out elsewhere, a controlled error situation is not a
> crash. Also, errors are good; when asking nonsensical questions you
> should get "no can do" as an answer, rather than nonsensical answers.
> Doing anything else is just building on quicksand. But that's just my
> opinion, and the reason I like (Chicken) Scheme so much: most of its
> community seems to have agreed on these values long ago.
>
> Cheers,
> Peter
> --
> http://sjamaan.ath.cx
>
> _______________________________________________
> Chicken-hackers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
- Re: [Chicken-hackers] substring function and bounds checks, (continued)
- Re: [Chicken-hackers] substring function and bounds checks, Jim Ursetto, 2013/02/05
- Re: [Chicken-hackers] substring function and bounds checks, Michele La Monaca, 2013/02/05
- Re: [Chicken-hackers] substring function and bounds checks, Jim Ursetto, 2013/02/05
- Re: [Chicken-hackers] substring function and bounds checks, Peter Bex, 2013/02/06
- Re: [Chicken-hackers] substring function and bounds checks,
Michele La Monaca <=
- Re: [Chicken-hackers] substring function and bounds checks, John Cowan, 2013/02/06
- Re: [Chicken-hackers] substring function and bounds checks, Peter Bex, 2013/02/06
- Re: [Chicken-hackers] substring function and bounds checks, Alex Shinn, 2013/02/06
- Re: [Chicken-hackers] substring function and bounds checks, Michele La Monaca, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, Alex Shinn, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, Michele La Monaca, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, Alex Shinn, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, John Cowan, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, Alex Shinn, 2013/02/07
- Re: [Chicken-hackers] substring function and bounds checks, John Cowan, 2013/02/07