Ugrás a tartalomhoz

C standard library

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából

A C szabványos könyvtár (C standard library), néha libc[1], a C programozási nyelv szabványos könyvtára, ahogyan azt az ISO C szabvány meghatározza.[2] Az eredeti ANSI C(wd) szabványból kiindulva, a C POSIX könyvtárral(wd) egy időben fejlesztették ki, amely annak szuperhalmaza.[3] Mivel az ANSI C-t a Nemzetközi Szabványügyi Szervezet elfogadta,[4] a C standard könyvtárat ISO C library-nak is nevezik.[5]

A C szabványos könyvtár makrókat, típusdefiníciókat és függvényeket biztosít olyan feladatokhoz, mint a karakterlánc-kezelés, a matematikai számítások, a be- és kimeneti feldolgozás, a memóriakezelés és input/output.

Alkalmazásprogramozási interfész (API)

[szerkesztés]

Fejléc fájlok

[szerkesztés]

A C szabványos könyvtár alkalmazásprogramozási interfésze (API) számos fejlécfájlban(wd) (header files) van deklarálva. Minden fejlécfájl egy vagy több függvénydeklarációt, adattípus-definíciót és makrókat tartalmaz.

Hosszú stabil időszak után három új fejlécfájl (iso646.h, wchar.h és wctype.h) került be az 1995-ben ratifikált C-szabvány Normative Addendum 1 (NA1) kiegészítésével. További hat fejlécfájl (complex.h, fenv.h, inttypes.h, stdbool.h, stdint.h és tgmath.h) a C99(wd), a C-szabvány 1999-ben közzétett módosításával, további öt fájl (stdalign.h, stdatomic.h, stdnoreturn.h, threads.h és uchar.h) a C11(wd) 2011-ben, és még egy fájl (stdbit.h) a 2023-ban megjelent C23-mal(wd) került hozzá. Összesen most már 30 fejlécfájl van:

Név -tól Leírás
<assert.h>(wd) Deklarálja az assert makrót, amely a program hibakeresése során a logikai és más típusú hibák felderítésére szolgál.
<complex.h>(wd) C99 Meghatároz egy sor függvényt a komplex számok manipulálására.
<ctype.h>(wd) Meghatározza a karakterek típusuk szerinti osztályozására[6] vagy a kis- és nagybetűk közötti konverzióra használt függvények halmazát a használt karakterkészlettől független módon (jellemzően ASCII vagy annak valamelyik kiterjesztése, bár ismertek EBCDIC-et használó implementációk is).
<errno.h>(wd) A könyvtári függvények által jelentett hibakódok tesztelésére.
<fenv.h>(wd) C99 Meghatározza a lebegőpontos környezet vezérlésére szolgáló funkciókat.
<float.h>(wd) A lebegőpontos könyvtár megvalósítás-specifikus tulajdonságait meghatározó makro-állandók definiálása.
<inttypes.h>(wd) C99 Meghatározza a rögzített szélességű egész szám típusokat.
<iso646.h>(wd) NA1 Számos makrót definiál, amelyek több szabványos token kifejezésének alternatív módjait valósítják meg. Az ISO 646 variáns karakterkészletekben történő programozáshoz.
<limits.h>(wd) Makro-állandókat definiál, amelyek az egész szám típusok megvalósítás-specifikus tulajdonságait határozzák meg.
<locale.h>(wd) Meghatározza a lokalizációs függvényeket.
<math.h>(wd) Definiálja az általános matematikai függvényeket.
<setjmp.h>(wd) Deklarálja a setjmp és longjmp, makrókat, amelyeket a nem lokális kilépésekhez használnak.
<signal.h>(wd) Meghatározza a jelkezelő funkciókat.
<stdalign.h>(wd) C11 Az objektumok lekérdezéséhez és adatok igazításához.
<stdarg.h>(wd) A függvényeknek átadott változó számú argumentum eléréséhez.
<stdatomic.h> C11 A szálak között megosztott adatokon végzett atomi műveletekhez.
<stdbit.h> C23 Bájtrendezéshez és bitábrázoláshoz.
<stdbool.h>(wd) C99 Boolean adattípust határoz meg.
<stddef.h>(wd) Számos hasznos típust és makrót definiál.
<stdint.h>(wd) C99 Rögzített szélességű egész számtípusokat határoz meg.
<stdio.h>(wd) Meghatározza az alapvető bemeneti és kimeneti funkciókat.
<stdlib.h>(wd) Numerikus konverziós függvények, pszeudo-véletlen számok generálására szolgáló függvények, memóriaelosztás, folyamatvezérlő függvények definiálása.
<stdnoreturn.h> C11 Nem visszatérő függvények megadásához.
<string.h>(wd) Meghatározza a karakterlánc-kezelő függvényeket.
<tgmath.h>(wd) C99 Típus-generikus matematikai függvények definiálása.
<threads.h> C11 Több szál, mutexek[7] és feltételváltozók kezelésére szolgáló függvények definiálása.
<time.h>(wd) Meghatározza a dátum- és időkezelési funkciókat.
<uchar.h> C11 Unicode karakterek manipulálására szolgáló típusok és függvények.
<wchar.h>(wd) NA1 wide-string kezelő funkciókat határoz meg.
<wctype.h>(wd) NA1 Meghatározza a széles karakterek típus szerinti osztályozására vagy a kis- és nagybetűk közötti konverzióra használt függvények készletét.

A fejlécfájlok közül három (complex.h, stdatomic.h és threads.h) olyan feltételes funkciókat tartalmaz, amelyeket az implementációknak nem kell támogatniuk.

A POSIX szabvány számos nem szabványos C fejléccel egészítette ki a Unix-specifikus funkciókat. Sokuk átkerült más architektúrákba is. Ilyen például az fcntl.h és az unistd.h. Számos más csoport más nem szabványos fejléceket is használ – a GNU C Library rendelkezik az alloca.h-val, az OpenVMS pedig a va_count() függvénnyel.

Dokumentáció

[szerkesztés]

Unix-szerű rendszereken az API hiteles dokumentációja man-oldalak formájában érhető el. A legtöbb rendszeren a szabványos könyvtári függvényekről szóló man oldalak a 3. fejezetben találhatók; a 7. fejezet tartalmazhat néhány általánosabb lapot a mögöttes fogalmakról (pl. man 7 math_error Linuxon).

Megvalósítások

[szerkesztés]

A Unix-szerű rendszerek általában rendelkeznek C könyvtárral megosztott könyvtár(wd) formájában, de a fejlécfájlok (és a fordító eszköztár) hiányozhatnak a telepítésből, így a C fejlesztés nem feltétlenül lehetséges. A C könyvtár a Unix-szerű rendszereken az operációs rendszer részének tekinthető; a C szabvány által meghatározott funkciók mellett más, az operációs rendszer API-jának részét képező funkciókat is tartalmaz, például a POSIX szabványban meghatározott funkciókat. A C könyvtári függvényeket, beleértve az ISO C szabványos függvényeket is, a programok széles körben használják, és úgy tekintik őket, mintha nem csak a C nyelvben lévő valaminek az implementációját, hanem de facto az operációs rendszer interfészének a részét képeznék. A Unix-szerű operációs rendszerek általában nem tudnak működni, ha a C könyvtárat törlik. Ez azokra az alkalmazásokra igaz, amelyek dinamikusan(wd), nem pedig statikusan(wd) linkeltek. Továbbá maga a kernel (legalábbis a Linux esetében) könyvtáraktól függetlenül működik.

A Microsoft Windows rendszerben az alaprendszer dinamikus könyvtárai (DLL-ek) a Microsoft Visual C++(wd) v6.0 fordítóhoz tartozó C szabványkönyvtár implementációját biztosítják; a Microsoft Visual C++ fordító újabb verzióihoz tartozó C szabványkönyvtárat az egyes fordítók külön-külön, valamint az újraforgalmazható (redistributable) csomagok biztosítják. A C nyelven lefordított alkalmazásokat vagy statikusan összekapcsolják egy C könyvtárral, vagy a könyvtár dinamikus verziójával likelik, amelyet az alkalmazásokkal együtt szállítanak, ahelyett, hogy arra támaszkodnának, hogy a célrendszereken jelen legyen. A fordító C könyvtárában található függvények nem tekinthetők a Microsoft Windows interfészének.

Számos C könyvtár implementáció létezik, amelyeket különböző operációs rendszerek és C fordítóprogramok egyaránt biztosítanak. A népszerű implementációk közül néhány a következő:

Fordítók beépített függvényei

[szerkesztés]

Egyes fordítóprogramok (például a GCC[10]) a C szabványos könyvtár számos függvényének beépített változatát biztosítják; azaz a függvények implementációi a lefordított object-fájlba kerülnek, és a program a beépített változatokat hívja meg a C könyvtár megosztott objectumfájljában(wd) lévő függvények helyett. Ez csökkenti a függvényhívások többletköltségét, különösen, ha a függvényhívásokat inline(wd) változatokkal helyettesítjük, és lehetővé teszi az optimalizálás más formáit (mivel a fordító ismeri a beépített változatok vezérlés-áramlási(wd) jellemzőit), de zavarokat okozhat a hibakeresés során (például a beépített változatok nem helyettesíthetők instrumentált változatokkal).

A beépített függvényeknek azonban úgy kell viselkedniük, mint az ISO C szabványnak megfelelő közönséges függvényeknek. A fő következmény az, hogy a programnak képesnek kell lennie arra, hogy a függvények címét átvéve mutatót hozzon létre ezekre a függvényekre, és ezen mutató segítségével hívja meg a függvényt. Ha a program két különböző fordítási egységében ugyanarra a függvényre mutató két mutatót származtatunk, akkor a két mutatónak egyenlőnek kell lennie, azaz a cím a függvény nevének feloldásával jön létre, amely külső (programszintű) hivatkozással rendelkezik.

Linking, libm

[szerkesztés]

A FreeBSD[11] és a glibc[12] alatt néhány függvény, például a sin() alapértelmezés szerint nincs linkelve, helyette a libm matematikai könyvtárba van csomagolva. Ha bármelyiküket használjuk, a linkernek meg kell adni a -lm direktívát. A POSIX megköveteli, hogy a c99 fordító támogassa az -lm opciót, és hogy a math.h, complex.h és fenv.h fejlécekben deklarált függvények elérhetőek legyenek a linkeléshez, ha a -lm opciót megadjuk, de azt nem írja elő, hogy a függvények alapértelmezés szerint linkelve legyenek.[13] A musl úgy tesz eleget ennek a követelménynek, hogy mindent egyetlen libc könyvtárba helyez, és egy üres libm-et biztosít.[14]

Detektálás

[szerkesztés]

A C szabvány szerint a __STDC_HOSTED__ makrót 1-re kell definiálni, ha az implementáció hosztolt. A hosztolt implementáció rendelkezik a C-szabvány által meghatározott összes fejléccel. Az implementáció lehet szabadonálló (freestanding) is, ami azt jelenti, hogy ezek a fejlécek nem lesznek jelen. Ha a megvalósítás önálló, akkor a freestanding __STDC_HOSTED__ értékét 0-ra kell definiálni.

Problémák és megoldások

[szerkesztés]

Puffer túlcsordulási sebezhetőségek

[szerkesztés]

A C szabványos könyvtár néhány függvénye az elfogadásuk óta hírhedt arról, hogy puffertúlcsordulási sebezhetőségeket tartalmaznak, és általában hibás programozásra ösztönöznek.[15][16] A legtöbbet kritizált tételek a következők:

  • a string-manipulációs rutinok, beleértve a strcpy() és strcat() programokat, a határok ellenőrzésének (bounds checking(wd)) hiánya és a lehetséges puffertúlcsordulás miatt, ha a határokat nem ellenőrzik manuálisan;
  • string rutinok általában, mellékhatások(wd), felelőtlen pufferhasználat ösztönzése, nem mindig érvényes null végződésű(wd) kimenet garantálása, lineáris hosszszámítás;[17]
  • printf() rutincsalád, a call stack elrontására, ha a formázott karakterlánc nem felel meg a megadott argumentumoknak. Ez az alapvető hiba a támadások egy egész osztályát hozta létre: a formázott karakterlánc-támadásokat(wd);
  • gets() és scanf() I/O rutinok családja, a bemeneti hossz ellenőrzésének (bármilyen, akár egyszerű) hiánya miatt.

A gets() extrém esetét kivéve, minden biztonsági rés elkerülhető a memóriakezelést, a korlátok ellenőrzését, a bemeneti ellenőrzést stb. végző segédkód bevezetésével. Ez gyakran olyan wrapper formájában történik, amely biztonságosabbá és könnyebben használhatóvá teszi a szabványos könyvtári függvényeket. Ez már B. Kernighan és R. Pike The Practice of Programming című könyvében is megjelenik, ahol a szerzők általában olyan wrappereket használnak, amelyek hibaüzeneteket írnak ki, és hiba esetén kilépnek a programból.

Az ISO C bizottság közzétette a TR 24731-1[18] műszaki jelentést, és jelenleg a TR 24731-2-n[19] dolgozik, hogy ennek megfelelően javaslatot tegyen néhány határérték-ellenőrzéssel és automatikus pufferelosztással rendelkező függvény elfogadására. Az előbbi komoly kritikát kapott, némi dicsérettel,[20][21] az utóbbi pedig vegyes visszhangot váltott ki.

Az aggályok ellenére a TR 24731-1-et az ISO/IEC 9899:2011 (C11) K. mellékletébe (Bounds-checking interfaces) integrálták a C-szabványok közé, és megközelítőleg a Microsoft C/++ futásidejű (CRT) könyvtárában implementálták a Win32 és Win64 platformokra.

(Alapértelmezés szerint a Microsoft Visual Studio C és C++ fordítói figyelmeztetést adnak ki, ha régebbi, „nem biztonságos” függvényeket használnak. A Microsoft TR 24731-1 implementációja azonban finoman szólva is inkompatibilis mind a TR 24731-1-gyel, mind a K melléklettel,[22] így a hordozható projekteknél gyakori, hogy letiltják vagy figyelmen kívül hagyják ezeket a figyelmeztetéseket. Közvetlenül kikapcsolhatók a következő módon: 

#pragma warning(disable : 4996)

a kérdéses site[s] hívás előtt/körül, vagy közvetve 

#define _CRT_SECURE_NO_WARNINGS 1

fejlécek hozzáadása előtt.[23] (A /D_CRT_NO_SECURE_WARNINGS=1 parancssori opciónak ugyanolyan hatást kell kifejtenie, mint ennek a #define-nek.)

Problémák a futási folyamatokkal kapcsolatban, sebezhetőség a versenyfeltételekkel szemben

[szerkesztés]

A strerror() rutint kritizálják, hogy nem szálbiztos(wd) és egyébként sebezhető a versenyfeltételekkel szemben.

Hibakezelés

[szerkesztés]

A C szabványos könyvtár függvényeinek hibakezelése nem következetes és néha zavaros. A Linux kézikönyv math_error oldala szerint: „A jelenlegi (2.8-as verzió) helyzet a glibc alatt kusza. A legtöbb (de nem minden) függvény hiba esetén kivételt (exception) okoz. Egyesek errno-t is beállítanak. Néhány függvény beállítja az errno-t, de nem vált ki kivételt. Nagyon kevés függvény egyiket sem teszi.”[24]

Szabványosítás

[szerkesztés]
Bővebben: C (programozási nyelv)#Történet

Az eredeti C nyelv nem rendelkezett beépített funkciókkal, például I/O műveletekkel, ellentétben a hagyományos nyelvekkel, mint például a COBOL és a Fortran. Idővel a C felhasználói közösségek megosztották egymással az ötleteket és a ma C szabványos könyvtáraknak nevezett implementációkat. Ezen ötletek közül sok végül beépült a szabványosított C nyelv meghatározásába.

Mind a Unix, mind a C az AT&T Bell Laboratories-ban született az 1960-as évek végén és az 1970-es évek elején. Az 1970-es években a C nyelv egyre népszerűbbé vált. Számos egyetem és szervezet kezdte el létrehozni a nyelv saját változatát saját projektjeihez. Az 1980-as évek elejére nyilvánvalóvá váltak a különböző C implementációk közötti kompatibilitási problémák. 1983-ban az Amerikai Nemzeti Szabványügyi Intézet (ANSI) létrehozott egy bizottságot, hogy létrehozza a C szabványos specifikációját „ANSI C”(wd) néven. Ez a munka 1989-ben az úgynevezett C89 szabvány létrehozásában csúcsosodott ki. Az így létrejött szabvány része volt egy szoftverkönyvtárakból álló készlet, amelyet ANSI C szabványkönyvtárnak neveztek el.

POSIX standard library

[szerkesztés]
Bővebben: en:C POSIX library

A POSIX, valamint a SUS(wd) számos olyan rutint határoz meg, amelyeknek az alapvető C szabványos könyvtáron túlmenően is rendelkezésre kell állniuk. A POSIX specifikáció fejlécfájlokat tartalmaz többek között a többszálú futás(wd), a hálózatépítés(wd) és a reguláris kifejezések számára. Ezeket gyakran a C szabványos könyvtár funkcionalitása mellett valósítják meg, különböző fokú közelséggel. Például a glibc a libc.so-ban olyan funkciókat valósít meg, mint a {{Kód2i|fork]}, de mielőtt az NPTL-t(wd) beolvasztották volna a glibc-be, az egy külön könyvtár volt, saját linker flag argumentummal. Gyakran ezt a POSIX-specifikált funkciót a könyvtár részének tekintik; az alapvető C könyvtárat ANSI vagy ISO C könyvtárként azonosítják.}

BSD libc

[szerkesztés]

A BSD libc' a POSIX szabványos könyvtár egy szuperhalmaza, amelyet a BSD operációs rendszerekhez, például a FreeBSD, NetBSD, OpenBSD és macOS operációs rendszerekhez tartozó C könyvtárak támogatnak. A BSD libc tartalmaz néhány olyan bővítményt, amelyet az eredeti szabvány nem definiál, és amelyek közül sok először az 1994-es 4.4BSD kiadásban jelent meg (az első, amelyet nagyrészt az első szabvány 1989-es kiadása után fejlesztettek ki). A BSD libc néhány bővítménye a következő:

  • sys/tree.h – tartalmazza a red–black tree és a splay tree(wd)[25] implementációját[26][27]
  • sys/queue.h – láncolt lista, queue, hátsó várólista (tail queue) stb. megvalósításai[28][29]
  • fgetln() – definiált az stdio.h-ban. Ez egy fájl soronkénti olvasására használható.[30][31][32]
  • fts.h – tartalmaz néhány függvényt a fájlhierarchia bejárásához[33][34]
  • db.h – néhány funkció a Berkeley DB-hez(wd) való csatlakozáshoz[35][36]
  • strlcat() és strlcpy() – az strncat() és strncpy() biztonságos alternatívái[37][38][39][40][41]
  • err.h – tartalmaz néhány függvényt formázott hibaüzenetek nyomtatására[42][43]
  • vis.h – tartalmazza a vis() függvényt. Ez a függvény a nem nyomtatható karakterek vizuális formában történő megjelenítésére szolgál.[44][45][46]

A C szabványkönyvtár más nyelveken

[szerkesztés]

Egyes nyelvek a C szabványos könyvtár funkcióit saját könyvtáraikba foglalják. A könyvtárat a nyelv struktúrájához jobban hozzáigazíthatják, de a működési szemantika hasonló marad.[47]

C++

[szerkesztés]

A C++ nyelv a C szabványos könyvtár konstrukcióinak többségét beépíti a sajátjába, kivéve a C-specifikus műveleteket. A C szabványos könyvtár függvényei kétféleképpen exportálhatók a C++ szabványos könyvtárból.

A C-vel és a szabvány előtti C++-szal való visszafelé/keresztkompatibilitás érdekében a függvények a globális névtérben (::) érhetők el, a C szabványos fejlécnév beolvasása (#include-ing) után, mint a C-ben.[48] Így a C++98 program: 

#include <stdio.h>
int main() {
    return ::puts("Hello, world!") == EOF;
}

a C95(wd) programmal (látszólag) azonos viselkedést kell mutatnia 

#include <stdio.h>
int main(void) {
    return puts("Hello, world!") == EOF;
}

A C++98-tól kezdve a C függvények a ::std névtérben is elérhetővé válnak (pl. a C printf mint C++ ::std::printf, az atoi mint ::std::atoi, a feof mint ::std::feof), a megfelelő C fejléc <hdrname.h> helyett a <chdrname> fejléc beépítésével. Pl. <cstdio> helyettesíti az <stdio.h>-t és <cmath> az <math.h>-t; vegye figyelembe a .h kiterjesztés hiányát a C++ fejlécneveknél.

Így a fenti két programmal egyenértékű (általában előnyösebb) C++≥98 program a következő: 

#include <cstdio>
int main() {
    return std::puts("Hello, world") == EOF;
}

Egy using namespace ::std deklaráció a main felett vagy a main-on belül automatikusan alkalmazza a ::std:: előtagot, bár általában rossz gyakorlatnak számít globálisan használni a fejlécekben, mert ez szennyezi a globális névteret.[49]

A C fejlécek közül néhány C++≥98 verzió hiányzik; például a C≥11 <stdnoreturn.h> és <threads.h> fejléceknek nincs C++ megfelelője.[50]

Mások helyőrzőkké redukálódnak, mint például (a C++20-ig(wd)) a <ciso646> a C95 <iso646.h> számára, amelynek minden szükséges makrója kulcsszóként jelenik meg a C++98-ban. A C-specifikus szintaktikai konstrukciók általában nem támogatottak, még akkor sem, ha a fejlécük támogatott.[51]

Számos C fejléc elsősorban a C++ kompatibilitás miatt létezik, és ezek általában közel üresek a C++-ban. Például, a C99-17 <stdbool.h> csak a következőre van szükség: 

#define bool _Bool
#define false 0
#define true 1
#define __bool_true_false_are_defined 1

hogy a C++98 bool, false és true kulcsszavak támogatását színlelje a C-ben. A C++11 a kompatibilitás érdekében megköveteli a <stdbool.h> és a <cstdbool> fájlokat, de csak az __bool_true_false_are_defined-et kell definiálniuk. A C23(wd) elavulttá teszi a régebbi _Bool kulcsszót az új, C++98-nak megfelelő bool, false és true kulcsszavak javára, így a C≥23 és a C++≥11 <stdbool.h>/<cstddbool> fejlécek teljesen egyenértékűek. (Különösen a C23 nem igényel semmilyen __STDC_VERSION_BOOL_H__ makrót a <stdbool.h> számára).

A C könyvtári függvények elérését lehetőség szerint a ::std névtéren és a C++≥98 fejlécneveken keresztül kell előnyben részesíteni. Az elfogadás ösztönzése érdekében a C++98 eltörli a C (*.h) fejlécneveket, így lehetséges, hogy a C kompatibilis fejlécek használata egy különösen szigorú C++98-20 preprocesszort valamilyen diagnosztikai hibaüzenetre késztet. A C++23 azonban (szokatlan módon) törli ezeket a fejléceket, így az újabb C++ implementációknak/módoknak nem kellene panaszkodniuk anélkül, hogy külön kérnénk őket.[52]


Más nyelvek hasonló megközelítést alkalmaznak, és a C kompatibilis függvényeket/rutinokat egy közös névtér alá helyezik; ezek közé tartozik a D, a Perl és a Ruby.

Python

[szerkesztés]

A CPython a C könyvtár néhány függvényének burkolatát tartalmazza a saját közös könyvtárában, és közvetlenebb hozzáférést biztosít a C függvényekhez és változókhoz a ctypes csomagon keresztül.[53]

Általánosabban, a Python 2.x úgy határozza meg a beépített fájlobjektumokat, mint amelyek „a C stdio csomagjának felhasználásával vannak implementálva”[54], és gyakran hivatkozik a C szabványos könyvtár viselkedésére; a rendelkezésre álló műveletek (open, read, write stb.) várhatóan ugyanúgy viselkednek, mint a megfelelő C függvények (fopen, fread, fwrite stb.).

A Python 3 specifikációja azonban jóval kevésbé támaszkodik a C-specifikációra, mint a Python 2.

Rust

[szerkesztés]

A Rust a crate libc-t kínálja, amely lehetővé teszi a különböző C szabványos (és egyéb) könyvtári függvények és típusdefiníciók használatát.[55]

Összehasonlítás más nyelvek szabványos könyvtáraival

[szerkesztés]

A C szabványkönyvtár kicsi néhány más nyelv szabványkönyvtárához képest. A C könyvtár matematikai függvények alapkészletét, karakterlánc-kezelést, típuskonverziókat(wd), valamint fájl- és konzol-alapú I/O-t biztosít. Nem tartalmaz olyan szabványos „konténertípusokat”(wd), mint a C++ szabványos sablonkönyvtár, nem is beszélve a teljes grafikus felhasználói felület (GUI) eszközkészletről, hálózati eszközökről és egyéb funkciók sokaságáról, amelyeket a Java és a .NET Framework szabványosan biztosít. A kis szabványos könyvtár fő előnye, hogy a működő ISO C környezet biztosítása sokkal könnyebb, mint más nyelvek esetében, és ennek következtében a C program új platformra történő átvitele viszonylag egyszerű.

Jegyzetek

[szerkesztés]
  1. ↑ Wellons, Chris: My review of the C standard library in practice, 2023. február 11. (Hozzáférés: 2024. december 29.)
  2. ↑ ISO/IEC (2018). ISO/IEC 9899:2018(E): Programming Languages - C §7
  3. ↑ Difference between C standard library and C POSIX library. stackoverflow.com , 2012. (Hozzáférés: 2015. március 4.)
  4. ↑ C Standards (amerikai angol nyelven). C: C Standards . Keil. (Hozzáférés: 2011. november 24.)
  5. ↑ The GNU C Library – Introduction. gnu.org . (Hozzáférés: 2013. december 5.)
  6. ↑ A C karakterosztályozás olyan műveletek csoportja a C szabványos könyvtárban, amelyek egy karaktert egy adott karakterosztályhoz való tartozásra tesztelnek; például ábécé, vezérlő stb. Az egybájtos és wide-karakterek egyaránt támogatottak.
  7. ↑ Az informatikában a kölcsönös kizárás (mutual exclusion) az egyidejűség-szabályozás egyik tulajdonsága, amelyet a versenyfeltételek megelőzése céljából hoztak létre.
  8. ↑ Re: Does Newlib support mmu-less CPUs?. Cygwin.com, 2006. március 23. [2008. november 22-i dátummal az eredetiből archiválva]. (Hozzáférés: 2011. október 28.)
  9. ↑ musl libc. Etalabs.net. (Hozzáférés: 2011. október 28.)
  10. ↑ FSF. 6.64 Other Built-in Functions Provided by GCC, A GNU Manual. self-published (2024. február 13.) 
  11. ↑ Compiling with cc. (Hozzáférés: 2013. március 2.)
  12. ↑ c - What functions is the libm intended for?. Stack Overflow . (Hozzáférés: 2021. február 24.)
  13. ↑ c99 - compile standard C programs. The Open Group Base Specifications Issue 7, 2018 edition . The Open Group. (Hozzáférés: 2021. február 24.)
  14. ↑ musl FAQ. www.musl-libc.org . (Hozzáférés: 2021. február 24.)
  15. ↑ Cobb, Michael: buffer overflow. TechTarget , 2021. július 1. (Hozzáférés: 2024. december 29.)
  16. ↑ A gets() jól ismert sebezhetőségét kihasználó Morris-féreg már 1988-ban elkészült.
  17. ↑ A C szabványos könyvtárban a karakterlánc hosszának kiszámítása és a karakterlánc végének keresése lineárisan bonyolult és nem hatékony, ha ugyanazokra vagy egymáshoz kapcsolódó karakterláncokra többször használják.
  18. ↑ ISO/IEC TR 24731-1: Extensions to the C Library, Part I: Bounds-checking interfaces. open-std.org, 2007. március 28. (Hozzáférés: 2014. március 13.)
  19. ↑ ISO/IEC WDTR 24731-2: Extensions to the C Library, Part II: Dynamic Allocation Functions. open-std.org, 2008. augusztus 10. (Hozzáférés: 2014. március 13.)
  20. ↑ Do you use the TR 24731 'safe' functions in your C code? - Stack overflow
  21. ↑ Austin Group Review of ISO/IEC WDTR 24731. (Hozzáférés: 2011. október 28.)
  22. ↑ Field Experience With Annex K—Bounds Checking Interfaces'. (Hozzáférés: 2024. október 9.)
  23. ↑ Security Features in the CRT—Eliminating deprecation warnings, 2023. február 1. (Hozzáférés: 2024. október 9.)
  24. ↑ math_error - detecting errors from mathematical functions. man7.org , 2008. augusztus 11. (Hozzáférés: 2014. március 13.)
  25. ↑ A splay tree egy bináris keresőfa, amelynek további tulajdonsága, hogy a nemrég elért elemekhez gyorsan újra hozzá lehet férni.
  26. ↑ tree. Man.freebsd.org , 2007. december 27. (Hozzáférés: 2013. augusztus 25.)
  27. ↑ Super User's BSD Cross Reference: /OpenBSD/sys/sys/tree.h. bxr.su
  28. ↑ queue. Man.freebsd.org , 2011. május 13. (Hozzáférés: 2013. augusztus 25.)
  29. ↑ Super User's BSD Cross Reference: /OpenBSD/sys/sys/queue.h. bxr.su
  30. ↑ fgetln. Man.freebsd.org , 1994. április 19. (Hozzáférés: 2013. augusztus 25.)
  31. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/stdio/fgetln.c. bxr.su
  32. ↑ Super User's BSD Cross Reference: /OpenBSD/include/stdio.h. bxr.su
  33. ↑ fts. Man.freebsd.org , 2012. március 18. (Hozzáférés: 2013. augusztus 25.)
  34. ↑ Super User's BSD Cross Reference: /OpenBSD/include/fts.h. bxr.su
  35. ↑ db. Man.freebsd.org , 2010. szeptember 10. (Hozzáférés: 2013. augusztus 25.)
  36. ↑ Super User's BSD Cross Reference: /OpenBSD/include/db.h. bxr.su
  37. ↑ Miller, Todd C. and Theo de Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, June 6–11, 1999, pp. 175–178.
  38. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strlcat.c. bxr.su
  39. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strlcpy.c. bxr.su
  40. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strncat.c. bxr.su
  41. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/string/strncpy.c. bxr.su
  42. ↑ err. Man.freebsd.org , 2012. március 29. (Hozzáférés: 2013. augusztus 25.)
  43. ↑ Super User's BSD Cross Reference: /OpenBSD/include/err.h. bxr.su
  44. ↑ vis(3). Man.FreeBSD.org . (Hozzáférés: 2013. szeptember 14.)
  45. ↑ Super User's BSD Cross Reference: /OpenBSD/lib/libc/gen/vis.c. bxr.su
  46. ↑ Super User's BSD Cross Reference: /OpenBSD/include/vis.h. bxr.su
  47. ↑ Az operációs szemantika (operational semantics) a formális programozási nyelvek szemantikájának egy olyan kategóriája, amelyben egy program bizonyos kívánt tulajdonságait, mint például a helyesség, a biztonság vagy a titkosság, a program végrehajtására és eljárásaira vonatkozó logikai kijelentésekből származó bizonyítások konstruálásával, nem pedig a kifejezések matematikai jelentéseinek hozzárendelésével (denotációs szemantika) igazolják.
  48. ↑ C++ Standard Library Headers—C compatibility headers, <https://en.cppreference.com/w/cpp/header#C_compatibility_headers>. Hozzáférés ideje: 9 October 2024
  49. ↑ Kieras, David: Using "using": How to use the std namespace (PDF). EECS381 Handouts . EECS Department, University of Michigan, 2015. február 15. [2022. december 24-i dátummal az eredetiből archiválva]. (Hozzáférés: 2024. október 9.) „A single using namespace std; statement in a single header file in a complex project can make a mess out of the namespace management for the whole project. So, no top level [using namespace] statements in a header file!”
  50. ↑ C++ Standard Library headers—Unsupported C headers. (Hozzáférés: 2024. október 9.)
  51. ↑ C++ Standard Library headers—Meaningless C headers. (Hozzáférés: 2024. október 9.)
  52. ↑ C++ Standard Library headers—C compatibility headers. (Hozzáférés: 2024. október 9.)
  53. ↑ ctypes—A foreign function library for Python. docs.python.com. (Hozzáférés: 2024. október 9.)
  54. ↑ The Python Standard Library, §5.9: File Objects. (Hozzáférés: 2024. október 9.) „File objects are implemented using C’s stdio package and can be created with the built-in open() function.”
  55. ↑ Crate libc'. Rust Crates . (Hozzáférés: 2024. október 9.)

További információk

[szerkesztés]

Kapcsolódó szócikkek

[szerkesztés]

Fordítás

[szerkesztés]
  • Ez a szócikk részben vagy egészben a C standard library című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=C_standard_library&oldid=27907273”