Typen sikkerhed

Verner Brandrud November 23, 2016 T 3 0
FONT SIZE:
fontsize_dec
fontsize_inc

I datalogi, type sikkerhed er, i hvilket omfang et programmeringssprog afskrækker eller forebygger skrive fejl. En type fejl er forkert eller uønsket program adfærd forårsaget af en uoverensstemmelse mellem forskellige datatyper for programmets konstanter, variable og metoder, f.eks, behandling et heltal som et flydende decimaltal. Type sikkerhed er undertiden alternativt anses for at være en egenskab af et edb-program i stedet for det sprog, som dette program er skrevet; det vil sige, nogle sprog har type-safe faciliteter, der kan omgås ved programmører, der vedtager praksis, der udviser dårlig form sikkerhed. Den formelle type teoretisk definition af type sikkerhed er væsentligt stærkere end hvad der forstås ved de fleste programmører.

Type håndhævelse kan være statisk, fange potentielle fejl påkompileringstidspunktet eller dynamisk, knytte typen informationer med værdier på run-time og høre dem efter behov for at opdage nært forestående fejl, eller en kombination af begge.

Den adfærd, der er klassificeret som type fejl ved en given programmeringssprog er som regel dem, der skyldes forsøg på at udføre operationer på værdier, der ikke er af den rette datatype. Denne klassificering er delvis baseret på udtalelse; nogle sproglige designere og programmører hævder, at enhver operation ikke fører til at programmere nedbrud, sikkerhedshuller eller andre åbenlyse fejl er legitimt, og behøver ikke at blive betragtet som en fejl, mens andre overveje nogen overtrædelse af programmøren udtrykkelige hensigt at være fejlagtige og ikke "type-safe ".

I forbindelse med statiske type systemer, type sikkerhed normalt indebærer en garanti for, at den endelige værdi af ethvert udtryk vil være en legitim medlem af dette udtryk statiske type. Den præcise krav er mere subtile end dette se for eksempel, subtype og polymorfi for komplikationer.

Type sikkerhed er tæt knyttet til hukommelsen sikkerhed, en begrænsning af muligheden for at kopiere vilkårlige bitmønstre fra en hukommelse sted til et andet. For eksempel i en implementering af et sprog, der har en eller anden form, således at en vis sekvens af bits udgør ikke et legitimt medlem af, hvis dette sprog tillader data, der skal kopieres til en variabel af typen, så er det ikke type-sikker, fordi en sådan operation kan tildele en ikke værdi som variabel. Omvendt, hvis sproget type usikkert at omfanget af at tillade en vilkårlig helt tal, der skal anvendes som en pegepind, så er det ikke memory-safe.

Mest statisk indtastet sprog giver en grad af typen sikkerhed, der er strengt stærkere end hukommelse sikkerhed, fordi deres typesystemer håndhæve den korrekte anvendelse af abstrakte datatyper defineret af programmører, selv når det ikke er strengt nødvendigt for hukommelse sikkerhed eller til forebyggelse af nogen art af katastrofale fejl.

Definitioner

Type-safe kode adgang kun hukommelsespladser det er bemyndiget til at få adgang. For eksempel kan typen-safe kode ikke læse værdier fra et andet objekts private områder.

Robin Milner givet følgende slogan til at beskrive typen sikkerhed:

Den passende formalisering af dette slogan afhænger stil med formel semantik, der anvendes til et bestemt sprog. I forbindelse med denotational semantik, type sikkerhed betyder, at værdien af ​​et udtryk, der er godt skrevet, siger med type τ, er en bona fide medlem af sættet, der svarer til τ.

I 1994 Andrew Wright og Matthias Felleisen formuleret hvad der nu standard definition og bevis teknik for type sikkerhed på sprog defineret af operationelle semantik. Efter denne metode er typen sikkerhed bestemmes af to egenskaber af semantik af programmeringssproget:

Disse egenskaber findes ikke i et vakuum; de er knyttet til semantik af programmeringssproget de beskriver, og der er et stort rum af varieret sprog, der kan passe disse kriterier, da begrebet "godt indtastet" program er en del af de statiske semantik af programmeringssprog og begrebet af "at sidde fast" er en egenskab af sine dynamiske semantik.

Vijay Saraswat giver følgende definition:

Forholdet til andre former for sikkerhed

Type sikkerhed i sidste ende til formål at udelukke andre problemer, fx: -

  • Forebyggelse af ulovlige operationer. For eksempel kan vi identificere et udtryk som ugyldig, fordi reglerne for aritmetiske ikke angiver, hvordan man opdele et heltal med en snor.
  • Hukommelse sikkerhed
    • Vilde pejlemærker kan opstå, når en pointer til en type objekt behandles som en pointer til en anden type. For eksempel er størrelsen af ​​et objekt afhænger af den type, så hvis en pointer inkrementeres i de forkerte legitimationsoplysninger, vil det ende peger på nogle tilfældige område af hukommelsen.
    • Buffer overflow - Out-of bundne skriver kan ødelægge indholdet af objekter allerede er til stede på den bunke. Dette kan forekomme, når en større formål med den ene type er groft kopieres i mindre genstand for en anden type.
  • Logik fejl oprindelse i semantik af forskellige typer. For eksempel kan inches og millimeter både lagres som heltal, men bør ikke anvendes i stedet for hinanden eller tilsættes. En type system, kan gennemtvinge to forskellige typer heltal for dem.

Type-safe og type-usikre sprog

Typen sikkerhed er normalt en forudsætning for enhver legetøj sprog foreslået i programmeringssprog forskning akademisk. Mange sprog, på den anden side, er for store for humane-genereret type sikkerheds beviser, da de ofte kræver kontrol tusindvis af sager. Ikke desto mindre har nogle sprog såsom Standard ML, som har nøje definerede semantik, vist sig at opfylde én definition af type sikkerhed. Nogle andre sprog som Haskell menes at møde nogle definitionen af ​​type sikkerhed, forudsat at visse "Escape" funktioner ikke anvendes type punning er et andet eksempel på en sådan "escape" funktionen. Uanset egenskaberne for definitionen sprog, kan visse fejl forekomme på run-time på grund af fejl i forbindelse med gennemførelsen, eller i forbundne biblioteker skrevet i andre sprog; sådanne fejl kunne gøre en given type gennemførelse usikre under visse omstændigheder. En tidlig version af Suns Java Virtual Machine var sårbare over for denne form for problem.

Skriv sikkerhed og "stærk skrive"

Nogle mennesker bruger udtrykket "stærk skrive" at henvise til visse aspekter af type sikkerhed. For eksempel kan et sprog med en statisk kontrolleret system af typen betegnes som "stærkt skrevet", fordi det statisk forbyder konvertering mellem værdier kompatibel type. Tilsvarende kan et sprog med en dynamisk kontrolleret typen systemet også beskrives som "stærkt skrevet", fordi et program, der forsøger at konvertere en værdi til en inkompatibel type vil svigte på kørselstidspunktet.

Skriv sikkerhed i objektorienterede sprog

I objektorienterede sprog typen sikkerhed er normalt iboende i det faktum, en type system er på plads. Dette er udtrykt i klassedefinitioner.

En klasse væsentlige definerer strukturen af ​​de objekter, der er afledt af det og en API som en aftale om håndtering af disse objekter. Hver gang et nyt objekt er skabt, vil overholde kontrakten.

Hver funktion, der udveksler genstande stammer fra en bestemt klasse, eller gennemførelse af en bestemt grænseflade, vil overholde denne kontrakt: dermed i denne funktion operationerne tilladt på det pågældende objekt vil kun være dem, defineret af metoderne til klassen objektet redskaber. Dette vil sikre, at objektet integritet vil blive bevaret.

Undtagelse herfra er objektorienterede sprog, der tillader dynamisk ændring af objektet struktur, eller brug af refleksion for at ændre indholdet af et objekt til at overvinde de begrænsninger, som klassen metoder definitioner.

Skriv sikkerhedsspørgsmål på specifikke sprog

Ada

Ada er designet til at være egnet til indlejrede systemer, enhedsdrivere og andre former for systemets programmering, men også for at tilskynde til typen sikker programmering. For at løse disse modstridende mål, Ada begrænser type utryghed til et bestemt sæt af særlige konstruktioner, hvis navne begynder normalt med strengen Unchecked_. Unchecked_Deallocation effektivt kan forbudt fra en enhed af Ada tekst ved at anvende pragma Pure til denne enhed. Det forventes, at programmørerne vil bruge Unchecked_ konstruerer meget omhyggeligt og kun når det er nødvendigt; programmer, der ikke bruger dem er typen sikker.

Spark programmeringssprog er en delmængde af Ada fjerne alle potentielle tvetydigheder og usikkerhed, mens på samme tid tilføjer statisk kontrolleret kontrakter til de sproglige funktioner tilgængelige. SPARK undgår problemer med dinglende pointere ved at udelukke tildeling under kørslen helt.

Ada2012 tilføjer statisk tjekket kontrakter til selve sproget.

C

C programmeringssprog er typesafe i begrænsede sammenhænge; for eksempel genereres en kompileringstidspunktsfejl, når der gøres et forsøg til at konvertere en pointer til en type struktur til en pointer til en anden type struktur, medmindre det udtrykkeligt støbt anvendes. Men en række meget almindelige operationer er ikke-typesafe; for eksempel den sædvanlige måde at udskrive et heltal er noget lignende, hvor fortæller på run-time forvente et heltal argument. Dette er delvist afbødes ved nogle compilere tjekker typen korrespondancer mellem printf argumenter og formatstrenge.

Hertil kommer, C, ligesom Ada, giver uspecificerede eller udefinerede eksplicitte konverteringer; og i modsætning til i Ada, idiomer, der bruger disse konverteringer er meget almindelige, og har været med til at give C en type-usikker omdømme. For eksempel er den standard måde at allokere hukommelse på bunke er at påberåbe sig en hukommelse tildeling funktion, såsom med et argument angiver, hvor mange bytes er påkrævet. Funktionen returnerer en typebestemt pointer, som den kaldende kode skal kaste til den relevante pointer type. Ældre C specifikationer kræves en udtrykkelig støbt til at gøre det, derfor koden blev accepteret praksis. Imidlertid er denne praksis frarådes i ANSI C, da det kan maskere en manglende omfatte header fil, hvor er defineret, hvilket resulterer i efterfølgende fejl på maskiner, hvor de int og henvisningstyper er af forskellige størrelser, såsom de fleste almindelige implementeringer af C i den nu allestedsnærværende x86 64-arkitekturen. En konflikt opstår i kode, der er nødvendig for at udarbejde som C ++, da skuespillerne er nødvendig på dette sprog.

C ++

Nogle af C ++ funktioner, der fremmer mere typen-safe kode:

  • Den nye operatør returnerer en pointer af typen baseret på operand, mens malloc returnerer et tomrum pointer.
  • C ++ kode kan bruge virtuelle funktioner og skabeloner til at opnå polymorfi uden ugyldige pointere.
  • Forbehandlingskommandoer konstanter kan omskrives som const variabler.
  • Forbehandlingskommandoer makro funktioner kan omskrives til inline funktioner. Fleksibiliteten i at acceptere og returnere forskellige typer kan stadig opnås ved funktionsoverstyring.
  • Sikrere casting operatører, såsom dynamic_cast der udfører run-time typen kontrol.

C #

C # er typen-safe. Det har støtte til typebestemt pegepinde, men dette skal tilgås ved hjælp af "usikre" søgeord, som kan forbydes på compiler-niveau. Det har iboende støtte til run-time støbt validering. Afstøbninger kan valideres ved at bruge "som" søgeord, der vil returnere en null reference, hvis skuespillerne er ugyldig, eller ved hjælp af en C-style cast, der vil kaste en undtagelse, hvis skuespillerne er ugyldig. Se C Sharp konvertering operatører.

For stor vægt på objekttypen risikerer at besejre formålet med C # typen system. Det er normalt bedre praksis at opgive objekt referencer til fordel for generiske lægemidler, svarende til skabeloner i C ++ og generiske i Java.

Cyklon

Cyclone er en type-safe sprog. Det kræver ikke en virtuel maskine eller garbage collection at opnå typen sikkerhed under runtime. Syntaksen er meget lig C.

Java

Java-sproget er konstrueret til at håndhæve typen sikkerhed. Alt i Java sker inde et objekt, og hvert objekt er en instans af en klasse.

At gennemføre håndhævelsen typen sikkerhed, hvert objekt, før brug, skal fordeles. Java tillader brugen af ​​primitive typer, men kun inde ordentligt tildelte objekter.

Nogle gange kan en del af den type sikkerhed gennemføres indirekte, f.eks klassen BigDecimal repræsenterer et decimaltal til vilkårlig præcision, men håndterer kun tal, der kan udtrykkes med en endelig repræsentation. Operationen BigDecimal.divide beregner et nyt objekt, som delingen af ​​to tal udtrykt som BigDecimal.

I dette tilfælde, hvis divisionen ikke har nogen endelig repræsentation, som når man beregner f.eks 1/3 = 0,33333 ..., den kløft metoden kan stige en undtagelse, hvis der ikke afrunding tilstand er defineret for operationen. Derfor biblioteket, snarere end det sprog, garanterer, at objektet respekterer kontrakten implicit i definitionen klassen.

Standard ML

SML har strengt definerede semantik og er kendt for at være typen-safe. Men nogle implementeringer af SMG, herunder Standard ML of New Jersey, dens syntaktiske variant Mythryl og MLton, give biblioteker, der tilbyder visse usikre operationer. Disse faciliteter bruges ofte sammen med disse implementeringer udenlandske funktion grænseflader til at interagere med ikke-ML-kode, der kan kræve oplysninger lagt ud på bestemte måder. Et andet eksempel er SMG / NJ interaktiv selv topniveau, der skal bruge usikre operationer til at udføre ML kode indtastes af brugeren.

Pascal

Pascal har haft en række typen sikkerhedskrav, hvoraf nogle holdes i nogle compilere. Når en Pascal compiler dikterer "streng skrive", kan to variable ikke overdrages til hinanden, medmindre de er enten kompatible eller overføres til det samme undertype. For eksempel, hvis du har følgende kode fragment:

Under streng skrive, en variabel defineret som TwoTypes ikke er forenelig med DualTypes og en overdragelse af T1: = D2; er ulovligt. En overdragelse af T1: = T2; ville være lovlige, fordi de undertyper, de er defineret til, er identiske. Men en opgave som T1.Q: = D1.Q; ville være lovligt.

Fælles Lisp

Generelt Common Lisp er en type-safe sprog. En fælles Lisp compiler er ansvarlig for at indsætte dynamiske kontrol for transaktioner, hvis typen sikkerhed kan ikke bevises statisk. Men en programmør kan indikere, at et program bør udarbejdes med lavere dynamisk type kontrol. Et program samles i en sådan tilstand, kan ikke betragtes som type sikker.

C ++ Eksempler

De følgende eksempler illustrerer, hvordan C ++ støbte operatører kan bryde typen sikkerhed, når de anvendes forkert. Det første eksempel viser, hvordan grundlæggende datatyper kan forkert støbt:

I dette eksempel udtrykkeligt forhindrer compiler i at udføre en sikker konvertering fra heltal til floating-point-værdi. Når programmet kører det vil output en skraldespand floating-point-værdi. Det problem kunne have været undgået ved i stedet at skrive

Det næste eksempel viser, hvordan objekt referencer kan forkert downcasted:

De to underordnede klasser har medlemmer af forskellige typer. Når downcasting en forælder klasse pegepind til et barn klasse pointer, så den resulterende pointer kan ikke pege på et gyldigt genstand for korrekte type. I eksemplet, fører dette til skrald værdi blive udskrevet. Det problem kunne have været undgået ved at erstatte med det kaster en undtagelse om ugyldige afstøbninger.

  Like 0   Dislike 0
Forrige artikel Sabo Quarter
Kommentarer (0)
Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha