Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1471 > unrolled thread

Formulating Security in Programming Languages

Started bySeima Rao <seimarao@gmail.com>
First post2015-01-15 17:49 +0530
Last post2015-01-15 17:49 +0530
Articles 1 — 1 participant

Back to article view | Back to comp.compilers


Contents

  Formulating Security in Programming Languages Seima Rao <seimarao@gmail.com> - 2015-01-15 17:49 +0530

#1471 — Formulating Security in Programming Languages

FromSeima Rao <seimarao@gmail.com>
Date2015-01-15 17:49 +0530
SubjectFormulating Security in Programming Languages
Message-ID<15-01-014@comp.compilers>
Hi,

    I came up with this notation in stating the goal of security in
programming languages:

    Programming Language Construct = Syntax + Semantics + Side Effect.

    N# semantics N# syntax = Syntax + Semantics + Side Effects

   Security = N# semantics N# syntax - Side Effects

    I will explain via a C example:

    N# (malloc-semantics) N# (malloc-syntax, free-opt-syntax) = Memory
Allocation + Memory Deallocation + Memory Leak

    In the above, the LHS says, apply the combined syntaxes of malloc
and optional-free to the semantics of malloc. The result is that
Memory Leak is a side effect. So, the goal of security is to remove
Memory Leaks.

   Does the approach specified in the above paragraphs occur to you as
brute force esp when generalizing over the entire grammar(small &
manageable) if not the semantics(the whole large LRM)?

   Is anyone interested in this topic ?

   Are there any other formal approaches to investigating security in
Programming Languages?

Sincerely,
Seima Rao.

[toc] | [standalone]


Back to top | Article view | comp.compilers


csiph-web