hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
ハンデキャップ 各種競技
ゴルフ（マッチプレー）
ゴルフのマッチプレーにおいても、プレイヤー同士の実力差が大きい場合にハンデキャップをつける。代表的なものとして、実力が上のプレイヤーが1ホールにつき1打ずつのハンデキャップを負う「エブリワン」などがある。
ボウリング
ボウリングでは最近のゲーム点数合計や平均値からハンデの点数を割り出し、実得点に加算して集計を行う。ハンデキャップの点数はHDCPと表現する。
ボクシング
ボクシングでは体重差がある場合は、体重が重い選手のグローブを重くするグローブハンデを行う。
プロレス
プロレスでは、興行を盛り上げるため1対2、2対3など対戦者間の人数で差をつけるハンディキャップマッチを行うことがある。
モータースポーツ
ツーリングカーレースの一部において、前のレースの優勝者・ポイントランキング上位者等を対象に車両におもりを乗せたり、リストリクター径を絞ってエンジンパワーを制限する方式が導入されている。またレース開始時のグリッドを一定の範囲で前レースの結果の逆順にするリバースグリッド制も存在する。界隈では上記のような結果に対して背負わされるものがハンデと認識されているが、マシン設計段階でスペック（過給器の有無や駆動形式など）に合わせて異なった最低重量や最大排気量を運営が設定するのも、広い意味ではハンデキャップといえる。
ハンデキャップ 各種競技
将棋
実力差がある場合は駒落ちという形でハンデを設定する。奨励会の一部の対局や男性棋士がゲストの女流棋戦などで用いられる。
囲碁
実力差がある場合は置き碁や逆コミという形でハンデを設定する。またゲームの性質上先手が有利であることから、互先では地の計算の段階でコミを出す形でゲームの均衡を図っている。
連珠
通常の五目並べでは先手の必勝法が判明しているため、先手に限って三三、四四、長連は禁手として、ゲームの均衡を図っている。
オセロ
オセロでは対局前に隅に黒石を置く方法で、ハンデを設定する。
浮動小数点数
浮動小数点数（ふどうしょうすうてんすう、英: floating-point number）は、実数をコンピュータで処理（演算や記憶、通信）するために有限桁の小数で近似値として扱う方式であり、人間が多く用いる10進数での数値の計算や表記に加えて、コンピュータの数値表現で多く用いる2進数の数値でも採用されている。多くの場合、符号部、固定長の指数部、固定長の仮数部、の3つの部分を組み合わせて、数値を表現する。
浮動小数点数 概要
この節はパターソンらの記述に基づく。
実数は0以上かつ1以下のような有限の範囲でも、無限個の値（種類）が存在するため、コンピュータでは妥当なビット数で有限個の値（種類）の近似値で扱う必要がある。
実数-1/3は10進数表現では無限小数となるが、有限桁の小数で近似値を表記できる。下の例では10進数での4桁としている。
-1/3
-1 x 0.33333333333333...
-1 x 0.3333 x 100
-1 x 3.333  x 10-1
下の2つの表記は科学記数法 (scientific notation) とよばれ、小数点より左側の整数部分を1桁とする。
科学記数法のうち、仮数部の最上位の桁が0以外（10進表記では1から9）であるものを、正規化数 (normalized number) とよび、
上記の最後の表示が該当する。科学記数法も、10進数表記での浮動小数点数である。
実数-1/3はまた、2進数でもその近似値を有限桁の小数で表記できる。下の例では2進数17桁としている。
-1/3
-1 x 0.01010101010101010101010101010101...
-1 x 0.0101010101010101
-1 x (2-2 + 2-4 + 2-6 + 2-8 + 2-10 + 2-12 + 2-14 + 2-16)
浮動小数点数 概要
-1 x (1/4 + 1/16 + 1/64 + 1/256 + 1/1024 + 1/4096 + 1/16384 + 1/65536)
-0.333328247（近似値の10進数表記）
2進数の小数も科学記数法で表記できる。
-1 x 0.0101010101010101 x 20
-1 x 0.101010101010101 x 2-1
-1 x 1.01010101010101 x 2-2
上記は同じ値を、小数点の位置を移動し異なる表記にしているため、2進数表記での浮動小数点と呼ばれる。一番下の表記は、正規化数である。
コンピュータ内部での演算処理に最も適した浮動小数点数の表現は基数2であり、符号 (sign) S、仮数 (significand) F、指数 (exponent) Eにより下記の式で表記できる。
(-1)S x F x 2E
数値に対する演算をあまり行なわずに数値を格納したり比較をする場合，あるいは演算が10進数でなければ正しく表せないような（お金の計算などの）用途では，計算機内部で10進数表現が
用いられる場合がある。
浮動小数点数 浮動小数点数のフォーマット
浮動小数点数のフォーマットには、以下で説明するものの他、以前は多数あった。
IEEE 754 形式の
で表現されている。各部は次のように定義されている。
つまり、IEEE 754 形式で表現する値は
半精度の場合： (−1)符号部 × 2指数部 − 15 ×（1 + 仮数部）
単精度の場合： (−1)符号部 × 2指数部 − 127 ×（1 + 仮数部）
倍精度の場合： (−1)符号部 × 2指数部 − 1023 ×（1 + 仮数部）
四倍精度の場合： (−1)符号部 × 2指数部 − 16383 ×（1 + 仮数部）
である。
ただし、IEEE 754 形式の指数部は複雑で、以下のような役割も持つ。
0 を 0 で割ろうとすると NaN になる。また、 も、求めるとNaNになる。
2.5を例にとると、
であることから、まず次のように考える。
(−1)0 × 2.5 × 20
浮動小数点数 浮動小数点数のフォーマット
仮数部は1未満でなければならないため、仮数の値2.5を（この例では右へ）シフトし正規化する。基数は2、コンピュータの内部表現は2進法であるため、シフト量は1ビットである。さらに、右シフトして1⁄2になったことを相殺するため、指数に1を加える（もし左シフトなら、指数から1を引く）。
値をシフトすることで表現範囲を広げ、丸め誤差を少なくなるようにしている。この操作を正規化という。正規化は基数の±1乗を繰り返し求めればよい。
このままでは (−1)0 × 1.25 × 21 となり、仮数の絶対値は1未満ではないが、仮数部は 仮数 − 1 と決められているため、次のようになる。
(−1)0 × (1 + 0.25) × 21
指数部は、指数に127をバイアスすることが決まっているため
(−1)0 × (1 + 0.25) × 2(128 − 127)
2進法では、
浮動小数点は、最上位ビットから符号部、指数部、仮数部の順に符号化するため
2進値：01000000001000000000000000000000、16進値：40200000
IEEE 754 形式から派生した浮動小数点数の形式。符号部 1 ビット ・ 指数部 8 ビット ・ 仮数部 7 ビットである。
つまり、bfloat16 形式で表現する値は
(−1)符号部 × 2指数部 − 127 ×（1 + 仮数部）
である。
浮動小数点数 浮動小数点数のフォーマット
採用事例
IEEE 754 形式から派生した浮動小数点数の形式。以下の2種類がある。E4M3は無限大を表現できない。2023年にOpen Compute Projectで仕様が制定されたが、IEEEがWorking Group P3109にてそれらの結論とは異なる仕様を検討中である。
採用事例
その他の独自規格としては、2019年のIBMのhybrid FP8や、2021年のTeslaのconfigurable FP8、2022年のGraphcoreのFP8
がある。AMD, Arm, Google, Intel, Meta, NVIDIAがOpen Compute Projectで合意するまでは仕様が分裂気味だったが、一応の決着を見た所、IEEEのWorking Group P3109がE4M3で無限大を表現できるように異なる仕様を検討している。
IEEE 754 形式から派生した浮動小数点数の形式。以下の2種類がある。無限大とNaNは表現できない。
採用事例
IEEE 754 形式から派生した浮動小数点数の形式。無限大とNaNは表現できない。
採用事例
浮動小数点数 浮動小数点数のフォーマット
IBM方式は、IBM社がSystem/360で導入し、以後同社の標準としてSystem/370などのメインフレームで使った方式である（System/390では、従来形式のサポートは残すもののIEEE 754を使用するよう改めた）。指数部が2の冪ではなく16の冪を表すという特徴がある。この方式は、より大きな範囲を少ないビット数の指数部で表すことができ、そのぶんのビットを仮数部の桁数に使うことで精度も確保できるように一見思える。しかし、仮数部にケチ表現を使うことができず、さらに指数部の変化の前後で、仮数部のLSBが表現する値の刻み幅が16倍変化するため、2べきの場合に比べて最悪の場合には2進で3ビット分の精度が損なわれるため、一般には大成功であったと評されたSystem/360の設計において良くなかった点の一つとして挙げられる。（浮動小数点数の加減算の際に必要となる仮数部のシフトが4ビット単位となるのでシフト回数が減ることで演算が15%程度高速になる利点も16進数が採用された理由であった。）
浮動小数点数 浮動小数点数のフォーマット
特に単精度において、前世代機のIBM 7094（全部で36ビット）よりも桁数を減らした（32ビット）ことと相まって精度が大きく損なわれた。その他にも問題があり、ユーザグループであるSHAREから改善提案が出され、その多くを受け入れて多大なコストのかかる改修をおこなったほどであり、これを記憶しているIBMの古参社員は「身の縮む思い」をおぼえているという。
また、計算対象の数値がベンフォードの法則に従って分布していた場合、計算対象として精度の低い数（仮数部の最上位4ビットが0b0001）の現れる確率は1/15にはならず、もっと高い。
IBM方式の単精度浮動小数点数では、符号部1ビット、指数部7ビット、仮数部24ビットで表現されている。各部は次のように定義されている。
符号部は仮数の符号を表す。
指数部は−1663～−16−64と16−64～1663の範囲が表現できる。
1.5を単精度のIBM方式で表現するには、次のようになる。
(−1)0 × 1.5 × 160
仮数部は1未満でなければならないため、値を（この例では右へ）シフトする。ただし、基数が16で、コンピュータの内部表現は2進法であるため、シフト量は4ビットである（24 = 16）。加えて正規化し、その結果は次の通り。
(−1)0 × 0.09375 × 161
浮動小数点数 浮動小数点数のフォーマット
次に指数部を、64をバイアスしたゲタ履き表現（エクセス64）で表現する。バイアスにより、0～127のビットパターンで、整数値−64～+63を表現するということになる（−64 + 64 = 0、63 + 64 = 127）。
よって、今回の例では以下のようになる。
(−1)0 × 0.09375 × 16(65 − 64)
2進法では、
浮動小数点は、最上位ビットから符号部、指数部、仮数部の順に符号化するため
2進値：0 1000001 000110000000000000000000、16進値：41180000
任意精度演算と、従来の指数部と仮数部を共に固定長とする形式の中庸と言えるような方式が、いくつか提案されている。絶対値が1に近い値では指数部の桁数を短くし、仮数部の桁数を多くとって、よく使われる値を精度よく表現する。絶対値が極端に大きい値や小さい値には、精度とひきかえに指数部の桁数を増やすことで対応する。以下で述べる方式を提案している文献では、アプリケーションとして、通常の浮動小数点計算には、指数が大きくなり過ぎることがあって向かないとされているen:Graeffe's methodをうまく扱えたという例が示されている。欠点としては、精度が変化するため従来の精度一定を前提としたノウハウに修正が必要かもしれない。
浮動小数点数 浮動小数点数のフォーマット
松井正一と伊理正夫が提案した方式で、符号と絶対値による表現法である。論文中に示された例では、64ビットの倍精度浮動小数点数として、仮数部の長さnを示す情報6ビットと、（符号部を含む）mビットの指数部とnビットの仮数部（m+n = 58）からなる。彼らは、オーバーフローを起こさせないための、より大きい数やより小さい数の表現や、無限大などの例外的な値を含めた算術（IEEE標準の±∞や−0の扱いに似ているが、より拡張されている）も提案している。
浜田穂積が提案した方式で、Universal Representation of Real numbersの意でURRと名付けられている。−∞ ～ 0 ～ ∞ の区間を、次のように分割しながら、二進法による表現に対応付ける、というのが基本的な考え方で、「符号と絶対値」形ではなく、浮動小数点の表現としては比較的珍しい2の補数の形をしている。
ここで±1の前後は、区間の両端の比が2なので、指数部の表現は終わったとみなすことができ、残りの桁は仮数部のように扱う（±1の前後は、以後は1/2で等差分割する）。次のように分割を続ける。
以降は、符号ビットが0である0 ～ 0.5 と 2 ～ ∞ の区間に絞って説明する。
浮動小数点数 浮動小数点数のフォーマット
ここで、2 = 220、4 = 221、16 = 222、256 = 223 である。このように 0 や ±∞ を含む区間は「二重指数分割」する。
このように、区間の両端の比が2より大きい場合は、「等比分割」する。
以上のような操作の結果として、指数部が0以上の場合は
指数部が0未満の場合は
ビット反転して0以上にした後に上述の方法を適用した指数部を、再びビット反転したものとなる。
こうして、負数に拡張されたガンマ符号によって自分の長さを含む指数部と、残りの仮数部から成る、と見ることができるような表現が得られる。
利点として、ビット表現を2の補数と解釈しても値・絶対値の大小関係が一致しているため、
という点が挙げられる。
表現形式の取り決め事項が、最下位ビットの追加・切り捨てだけで任意に変換でき、精度の問題に過ぎない、ビット長のみである。また、2の補数の形を採るという考え方が提案当初は独創的であった。このため、異なる処理系との間のデータ交換を容易にする普遍性(「URR」のUはUniversal「普遍性」の頭文字)を当方式は備えていた。しかし、指数部に使われる整数の符号化にはガンマ符号以外にも様々な手法が使えるため、後に、互換性の無い様々な亜種の出現を許した。
欠点としては、−∞を除くワードのあらゆるビット表現に浮動小数点数としての意味が与えられるため、例外的な値を表現する方法を別に考えなければいけない、などといった点がある。浜田は1000...を符号なしの∞（射影モード用。符号なしの0と対応する）とし、表現可能な最大と最小の絶対値を持つ値を、具体的にその値を表すのではなく±∞と±0を表現するものとする（0は、通常の0を符号なしの0とし、符号付きの+0や−0は、無限大で割った結果など例外的な値としてのみ現れる）、という方法を提案している。
この表現法の初出は1981年だが、1983年に改良版が提案されているのでそちらをまずは参照すべきである。
いくつかの実装の報告や改良の提案などがある。
この方法は浜田方式のリバイバルのようなものである。
浜田方式との違いは、指数部の表現方法である。浜田方式は(整数として解釈した時の大小関係を保つように修正を加えた)ガンマ符号を用いるのに対し、当方式は指数部を上位ビットと固定長の下位ビットに分け、上位ビットは(浜田方式と同様の修正を加えた)アルファ符号で表現する。このため、絶対値が1付近では、下位ビットに固定長のビットを要する当方式より浜田方式の方が仮数部ビットを多くとれて精度が高くなるが、そこから少し離れると当方式の方が精度が良くなり、更に離れると浜田方式の方が良くなる。
浮動小数点数 エラー（誤差）
オーバーフロー／アンダーフロー
演算結果が指数部で表現できる範囲を超える場合があるが、最大値を超えた場合はオーバーフロー、絶対値の最小より小さい場合はアンダーフローという。IEEE 754の場合、アンダーフローは、まず結果が非正規化数となり精度が低下し、さらに進むと結果が0になる。
桁落ち
絶対値がほぼ等しい異符号の数値同士の加算後や、同符号でほぼ等しい数値同士の減算の後、正規化で有効数字が減少すること。詳細は桁落ちを参照。
情報落ち
浮動小数点数値を加減算するときはまず指数を揃えなければならない。絶対値の非常に小さな値と絶対値の非常に大きな値との浮動小数点数の加減算を行うときは、まず指数を絶対値の大きい方に揃える桁合わせを行ない、それから加減算を行なう。そのため絶対値の小さな値は仮数部が右側に多くシフトされて下位の桁の部分が反映されずに結果の値が丸められて情報が欠落する。情報欠落ともいう。詳細は情報落ちを参照。
浮動小数点数 エラー（誤差）
積み残し
情報落ちが繰り返し起こる場合を言う。たとえば  を n=0 の初項からn=100に向かって順番に加えて計算しようとすると、ある項から先で情報落ちが起こり、それ以降の項は無視されてしまうことになる。これを積み残しと呼ぶ。値の小さい項から大きい項に向かって加算をする（この例では逆順に加算をする）ことで対処できる場合もある（必ずしもそうすれば全て完全にうまくいくとは限らない）。対処としては、有理数演算などによって無誤差の計算を行うか、カハンのsummationアルゴリズムなどいくつかの効率的な手法が提案されている。
丸め誤差
仮数部の桁数が有限であるため、収まらない部分の最上位桁で四捨五入（2進法では0捨1入）して仮数部の桁数に丸めることによる誤差。
日本代表
日本代表（にほんだいひょう、にっぽんだいひょう）とは、日本を代表して国際会議や世界的な大会に参加する個人もしくは団体。団体を指す場合には「日本代表団」とも呼ばれる。また、スポーツの選手個人を指す場合は「代表選手」とも呼ぶ。
日本代表 スポーツにおける用例
かつては競技スポーツ全般において日本代表チームを「全日本」と呼ぶことが通例だったが、現在では一部競技を除き、この呼称は使われなくなってきた。また、外国のチームも含めて、以前は「ナショナルチーム」と呼ばれる場合も多かったが、現在では「代表チーム」と呼ぶことで落ち着いている。
これに対し現在の日本では、主要な競技スポーツにおけるほとんどの日本代表チームは、代表監督の苗字を頭につけて「＊＊ジャパン」「xxJAPAN」のように呼ばれる。この呼び方は1980年代のラグビー日本代表から始まり、1990年代のサッカー日本代表に波及し、ほぼすべての団体球技に対して用いられている。
日本で開催された2006年バスケットボール世界選手権に出場したバスケットボール男子日本代表監督の名前は、ジェリコ・パブリセヴィッチ。長くて、「パブリセヴィッチジャパン」とは連呼しづらいため、代表チームは監督名で呼ばれないと思われていた。しかし、当時のメディアは監督のファーストネームを使って「ジェリコジャパン」と呼んでいた。2010年にトーマス・ウィスマンが同代表監督に就任した際は、トーマスの愛称「トム」を使って「トムジャパン」と呼んでいる。また、サッカーのアルベルト・ザッケローニ監督に関しても、2010年の就任当初から姓を略して愛称化した「ザックジャパン」と略されていた。
日本代表 スポーツにおける用例
近年は、「＊＊ジャパン」という呼び方に対する短所も明らかになっている。監督が交代すると呼び方も変わり、チーム作りのコンセプトも変わってしまうため、チーム作りにおいて前任者の思想・チーム戦術などが受け継がれないということがよく生じている。また、選手の個性や実力よりも監督の名前と注目度ばかりが先行してしまうことも生じてしまう。こうした側面から、2008年に開催された北京オリンピックでは男女バレーボールや男子サッカー、野球などの「＊＊ジャパン」と呼ばれた競技がことごとく不振に終わっている。同年8月23日の日本経済新聞のコラムでは、「監督のカリスマ性や過剰な物語性よりも、選手の伸びやかなプレーに勝利の女神はほほ笑む。」と書いている。また、日刊スポーツのコラムでも前者の短所に触れて「継続性がない○○ジャパン」と書いている。
上記名称に対して、例外も幾つか存在する。
その他、マジック:ザ・ギャザリングなどのテーブルゲーム、国際数学オリンピック日本代表や、ミス・ユニバースなどの国際的なミスコンテスト日本代表などが挙げられる。
GNUコンパイラコレクション
GNU Compiler Collection（グヌーコンパイラコレクション）は、GNUのコンパイラ群である。略称は「GCC（ジーシーシー）」。GNUツールチェーンの中核となる構成要素（コンポーネント）にもなっている。
GNUコンパイラコレクション 概説
最新標準パッケージには C、C++、Objective-C、Objective-C++、Fortran、Ada、Go、Dのコンパイラ並びにこれらのライブラリが含まれている。 バージョン7以前では、Javaもサポートされていた。
当初はCコンパイラとして開発し、GCCは GNU C Compiler を意味していた。しかし、もともと多言語を想定して設計しており、 GNU C Compiler と呼ばれていたときでも多くの言語に対応していた。現在でも GNU C Compiler の意味で「GCC」と呼ぶことも多い。ちなみに GNU C Compiler の実行ファイルの名称もgccである。なお、GNU C++コンパイラをG++、GNU JavaコンパイラをGCJ、GNU AdaコンパイラをGNATと呼ぶ。
GNUコンパイラコレクション 概説
CコンパイラとしてのGCCは、ANSI規格 (ANSI X3.159-1989) にほぼ適合するC言語コンパイラ処理系であった。登場当初の時点では、オペレーティングシステム (OS) 標準に付属するCコンパイラがANSI規格に適合していない部分が多いものがあった。そのため、GCCはANSI規格を広める役割を果たした。GCC自身はK&Rの範囲内のC言語で記述していたので、OS付属のコンパイラでコンパイルできた。ただし、GNU拡張という独自の仕様もあり、GCCでコンパイルできるものがANSI適合コンパイラでコンパイルできるとは限らない。
GNUコンパイラコレクション 歴史
1985年、当時マサチューセッツ工科大学 (MIT) の研究者であったリチャード・ストールマンによって、既成のコンパイラを拡張する形で開発が始められた。当初コンパイラはPastelというPascalの方言によって書かれていた。その後ストールマンとLeonard H. Tower, Jr.によってC言語で書き直され、GNUプロジェクトの一つとして1987年に公開された。さらに2012年にはLawrence CrowlとDiego NovilloによってC++で書き直された。
EGCS（エッグズ、Experimental/Enhanced GNU Compiler System）は、1997年に当時開発中のGCC 2.8をベースとしてCygnus社のEGCS Steering Committee（後のGCC Steering Committee）により開発された拡張版GCCである。1999年4月、GCCと再統合されてEGCSがGCCの公式バージョンとなり、GCCの開発主力はGCC Steering Committeeに委ねられた。また、この時点でGCCはGNU Compiler Collectionの意味となった。統合後初めてリリースされたバージョンは、1999年7月のGCC 2.95である。
GNUコンパイラコレクション 構成
GCCは通常のコンパイラと同様にフロントエンド部、最適化部、バックエンド部から構成される。
フロントエンド部は字句解析、構文解析などを行い、対応言語ごとに用意されている。たとえばC++フロントエンド、Javaフロントエンドなどがある。
バックエンド部のコード生成部（コードジェネレータ）、および最適化部（オプティマイザ）は全言語で共通である。したがってGCCの対応の言語同士の間では、生成コードの質や対応するCPUの種類は原理的に同じになる。なお、フロントエンドおよびバックエンドの間でやりとりされる中間形式としてレジスタ転送言語 (RTL) が使用される。
CコンパイラとしてのGCCの開発のために開発された構文解析部生成系bisonやフリーな字句解析部生成系flexといったプログラムを使用してGNU Cコンパイラその他の各種フロントエンドは構築されている。これらは単独の自由ソフトウェアとしても有用なものである。
GCCはバージョン4から中間形式が2つ追加された。まず、各言語は通常フロントエンド言語の木構造を保持した共通中間形式のGENERICに変換されその後GIMPLEという中間形式で木の最適化SSAをおこなってからRTLの最適化がおこなわれる。また、CやC++のコンパイル時にフロントエンドの構文解析、字句解析においてbisonやflexを使用しなくなった。
GNUコンパイラコレクション 影響と評価
GCCはそれ自身が有用な自由ソフトウェアだが、OSやDOSエクステンダ（DJGPP、EMXなど）を構築するための基盤ツールとしても非常に有用であり、商用・非商用を問わず多くの環境で標準的なCコンパイラとして採用されている。特にLinuxやFreeBSDなど、自由ソフトウェアとしてのOSは、もしGCCが存在しなかったならば大きく違ったものになっていたであろうと言われている。実際Linuxの生みの親であるリーナス・トーバルズはGCCをGNUプロジェクトの中で最も重要なものとして挙げている。
また、多くの組み込みOS や、ゲームの開発環境でもGCCを採用している場合も多い。これは、クロス開発を容易なものとするGCCの広範なプロセッサへの対応が評価されていることによる。
その一方で、ある時期までは生成コードの最適化において、特定のプロセッサへの最適化を図る商用コンパイラに大きく水をあけられていた時期もあった。特に科学技術演算で多用されるベクトル演算機構への対応や、特定のベンチマークなどでは顕著であった。これは多様な環境に対応することを第一とし、個別のプロセッサ向けの最適化を追求してこなかったことも大きな要因であったが、最近ではこれを改善するための試みも始められている。（最適化を参照）
GNUコンパイラコレクション 影響と評価
GCCを巡っては、GNU General Public License（特にバージョン3）との関係が問題視される場合がある。
GPLには強いコピーレフト性があり、リンクやコードの一部の使用によってプログラム全体にGPLが伝播する性質があるが、GCCにはGCC Runtime Library Exception（GCCランタイムライブラリ例外）が存在するため、GCCをコンパイラとして利用する限りにおいては作成物にGPLを強制することはない。しかし、GCC自体の再頒布にはソースコードの提供義務やTiVo化の禁止などの条件が付きまとうことになる。
そのため「GPLフリー」を目指して、OS（あるいはプラットフォーム）の標準コンパイラをGCCから別のものに切り替える動きも有り、一例としてFreeBSDでは、2012年に標準コンパイラをGCCからClang/LLVMに切り替えた。
GNUコンパイラコレクション GNU Cコンパイラ拡張
GNU C コンパイラの特徴のひとつは、前述のようにANSIあるいはISO等の標準への準拠である。もうひとつの特徴は独自の拡張機能である。このような拡張を「GCC拡張機能」とよぶ。GCC拡張機能は数多いが、多引数マクロ、基本型としての複素数型、式の演算結果としての左辺値、初期化式の拡張、Cでのインライン関数定義、ネストした関数定義、ラベルに対する&演算子の適用などがある。
このような拡張は、C99における標準Cの拡張として逆に取り込まれたものも多い。
言語機能の拡張のほかに、標準外機能としてasm文によるインラインアセンブラの機能はユニークである。ただし、GCCにおいてはこのインラインアセンブラ機能を利用して記述したコードに対しても最適化が行われる（プログラマが意図してアセンブリ言語を用いて書いたとしても、その通りのコードが出力されない可能性がある）点に注意が必要である。
その他、研究論文の発表における実装例のベースとして、あるいは実験的機能実装のベースとしてGCC (G++)が使われることも多い。そのような拡張の最近の例としては、スタックバッファオーバーフローに関する脆弱性の回避のためのGCC拡張ProPoliceなどがある。
GNUコンパイラコレクション 最適化
GCCは高度な最適化を行うが、CPUベンダやRISCワークステーションメーカが提供するコンパイラと比べると見劣りする場合もある。マルチアーキテクチャゆえに、機種依存しない最適化が中心となるため、特定の CPU に特化した専用コンパイラと比べてやや不利な立場といえる。
2005年4月にリリースされたGCC4.0はループ最適化の改善や自動ベクトル化など最適化機構が大幅に見直されている反面、GCC3.x で書かれたコードがコンパイルエラーになることがあり、互換性において若干の問題点がある。GCC4.2ではバグ修正、最適化の改善に加え、新機能としてC、C++、FortranでOpenMPに対応し、さらにGCC4.3ではループの自動並列化によるマルチスレッド処理が可能となるなど、マルチプロセッサ環境では大幅にアプリケーションの性能を引き上げることが可能になった。ただし、マルチスレッドやベクトルプロセッサを使用しないことを前提としたシングルスレッドアプリケーションにおける最適化においては3.x系よりも一部のプログラムにおいて劣る場合もある。
GNUコンパイラコレクション 最適化
2010年4月にリリースされたGCC4.5ではリンク時最適化が導入され、複数のオブジェクトファイルにまたがるプログラムに対してより効果的に最適化ができるようになった。なおリンク時最適化とは単にリンク時に行う最適化を意味し、プロシージャ間最適化やプログラム全体最適化を改善する上で求められるようになった。
1990年頃のGCC1.xや2.xは、特にMC680x0系に対して商用コンパイラを凌駕する最適化品質を誇っていたとされる。ただし、これは同時代の68k系商用コンパイラとの相対的な比較・評価であり絶対的な指標によるものではない。
また1990年代後半のPGCCはインテル Pentium専用の最適化を行うGCC（正確にはegcs）の派生であり、通常版と比べてPentium CPU上でより効率良く動作するコードを生成する。
Bomis
Bomis, Inc.（ボミス・インク）は、1996年設立のインターネット企業であり、主要事業は検索エンジンポータル「bomis.com」（2010年頃閉鎖）での広告販売であった。フリー百科事典プロジェクトNupediaおよびウィキペディアに資金援助をおこなった。2006年以来、ティム・シェルがCEO（最高経営責任者）を務めていた。
Bomis 概要
Bomis.comでは人気のあるサーチ対象のウェブリングを作成・提供している。ウェブリングのカテゴリーは2005年現在おおまかに「かわいこちゃん」「エンターテインメント」「スポーツ」「ポルノ」「その他」および「サイエンス・フィクション」にカテゴリー分けされている。「ポルノ」「かわいこちゃん」「エンターテインメント」のカテゴリーは最も更新頻度が高く、人気も高い。加えて、Bomis社はOpen Directory Projectのサーチ・ディレクトリをコピーしたものを提供している。検索に関連するページでは広告掲載およびアフィリエイトから収益を得ている。
またBomisは2005年まで「Bomisプレミアム」（"Bomis Premium", premium.bomis.com）というウェブサイトを運営していた。これは顧客に対して上質のポルノ・コンテンツを提供するものだった。
Bomis 概要
2005年半ばまで、Bomisは"Bomis Babe Report"(Bomisのかわいこちゃん通信)という無料のブログを公開しており、これは著名人、モデル、大人向けエンターテインメント業界のニュースや論評を伝えるものであった。この"Bomis Babe Report"は「Bomisプレミアム」へ多くのリンクをはり、Bomisに新しく加わったモデルの情報を逐一伝えていた。またBomisはnekkid.infoという、エロチックな写真のフリー・レポジトリを運営しており、さらに「高精度かわいこちゃん検索エンジン」を謳う「The Babe Engine」を運営していた。これはグラマラスな写真からポルノグラフィーまで多様な写真をインデックスしたものだった。
こうしたポルノグラフィー関連と検索に加えて、Bomisは客観主義（英語版ウィキペディア"Objectivism"を参照）およびその他のリバタリアニズム的政治思想を支持するウェブサイトをホスティングしていた。この中には書籍や引用のデータベース「Freedom's Nest」、そして今や消滅した大規模な客観主義コミュニティー「We the Living」も含まれている。
Bomis Nupediaおよびウィキペディアとの関わり
BomisはNupediaを開始し、Nupediaに従事させるために雇ったラリー・サンガーからウィキペディアのアイディアを得た。Bomisはこれらのプロジェクトにウェブスペースと帯域を提供し、これらのプロジェクトとはかかわるがドメイン名などオープンソースやオープンコンテントで無い部分を所有した。しかし、2003年6月20日、これらの所有権をウィキメディア財団に移譲する計画だと発表した。
Bomis その後
Bomis.comは2010年頃に閲覧不能となった。
2012年12月、「Bomisに何が起こったか？」（"What Happened to Bomis?"）という質問がQuoraに寄せられ、Bomisの創業者であるジミー・ウェールズが2013年1月に以下のように回答した。
Moving Picture Experts Group
Moving Picture Experts Group（ムービング・ピクチャー・エクスパーツ・グループ、動画専門家集団）あるいはMPEG（エムペグ）は、ビデオとオーディオに対して符号を付与する基準の開発責任を負ったISO/IECのワーキンググループで1988年1月に設立し、その最初の会議はオタワ(カナダ)で1988年5月に開催された。2005年の終わりの時点で、MPEGは、様々な産業、大学および研究機関から約350人のメンバーが参加している。MPEGの公式名称はISO/IEC JTC 1/SC 29/WG 11である。「Motion 〜」などとも呼ばれる。
グループの略称をMPEGといい、またはそこがつくった動画等の標準規格の名称としてMPEGが使われるようになった。標準規格の名称がMPEGであり、略称ではない。音声圧縮方式のMP3やファイルフォーマットのMP4はMPEGが規格化した方式である。MPEG-2システムはH.222.0、MPEG-2ビデオはH.262、MPEG-4 Part 10 AVCはH.264と同じ内容であるように、MPEGとITU-Tは共同で規格化作業を行うことがある。
Moving Picture Experts Group 主なMPEG規格
MPEGは以下のような圧縮フォーマットおよび付随的な基準を標準化した。ヒトの視覚は目に入る左上頂点から認識する特性があることから、それを原理的に取り入れ、各種な圧縮展開方策が取られている。
※表中のMP－xはMPEGーｘの省略です。
※CD、BD、HD DVDは標準的な片面1層の容量で、読込速度も1倍速再生で倍速は含まない。また、各メディアに複数の規格があるが、一般的な物とする。
アプリケーションプログラミングインタフェース
アプリケーションプログラミングインタフェース（API、英: application programming interface）とは、広義ではソフトウェアコンポーネント同士が情報をやりとりするインタフェースの仕様である。
APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラリ（例えば、C++のStandard Template LibraryやJava APIなど）がある。
商業的に使われる狭義では、各種システムやサービス（ハードウェア、OS、ミドルウェアおよびWebサービス等）を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ライブラリは含まない。
アプリケーションプログラミングインタフェース
APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。
アプリケーションプログラミングインタフェース 概要
広義のAPIでは単なるライブラリのインタフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。
前述のとおりAPIは各種システム／サービスがそのシステム／サービスを利用するアプリケーションに対して公開するインタフェースである。APIの重要な役割は、システム／サービス提供者が公式に仕様（外部仕様）を定義し、管理している各種機能を利用するための操作方法（インタフェース）を提供することである。APIは多くの場合、アプリケーションを構築する言語と同じ言語のライブラリ、あるいは通信プロトコル形式として提供され、システム／サービス開発者によって提供・管理される。
アプリケーションプログラミングインタフェース APIと非API
アプリケーションがシステム／サービスを利用するには、APIを無視してシステム／サービスの現在の実装および内部仕様に依存した方法がある。人と同じ操作をアプリケーションにさせたり、たまたま設定が書き込まれていたファイルをアプリケーションで読み取るなどである。この手法を非APIと言い英語圏ではnon-APIあるいはnon APIと呼ぶ。システム／サービス提供者はアプリケーションがAPI以外の仕様や実装に依存していることは関知せず、API以外の仕様や実装が永続的に維持されることも保証しない。このため非APIを使ったアプリケーションは、バグ修正などで少しでもシステム／サービスの内部仕様に変更があれば、たちまち動かなくなってしまう。この点、APIを使用する場合は、システム／サービスが更新されてもAPIが提供者によって後方互換性を維持してくれるため、アプリケーション側の変更は必要ない(ただし頻繁ではないが提供者により互換性がなくなる場合もある)。アプリケーションがシステム／サービスを操作するにあたり、APIにだけ依存することでこのような互換性の問題を避けることができる。
アプリケーションプログラミングインタフェース APIと非API
ただし、APIを使う場合、APIの提供者から使用回数などに制限を掛けられる場合がありそれをらの制限を回避するためやAPIを提供していないシステム／サービスを使うために非APIを使う技術が重要になる場合もある。
#（参考情報）ライブラリ形式の非API、#（参考情報）ライブラリとAPIも参照
アプリケーションプログラミングインタフェース 詳細
APIはソフトウェアライブラリと対応しているのが一般的である。
APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。
1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。
広義のAPIはソフトウェアフレームワークと対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転や他の類似の機構によってフレームワーク側が流れを制御する。
APIはプロトコルの実装となっていることもある。
プロトコルは、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される。
アプリケーションプログラミングインタフェース 詳細
APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMIは、JRMPプロトコルまたはRMI-IIOPとしてのIIOPを実装している。
プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。
オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。
2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJavaで書かれたプログラムがC#で書かれたサービスをSOAPやIIOP経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。
アプリケーションプログラミングインタフェース 詳細
一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリを使って複数プロセス間で行うこともあるし、タプルスペースのような共有技法を使うこともある。
アプリケーションプログラミングインタフェース ウェブAPI
ウェブAPIはHTTP要求メッセージ定義とJSON形式等の応答メッセージ定義で構成される。Web 2.0ではSOAPベースからRESTベースへと変化している。ウェブAPIはマッシュアップにより複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする。
APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。
WebAPIは様々なスタイルで表現される。例えばリソースの表現は以下の様式がありうる。
パスは厳密な階層構造をもつリソースの表現に適している。クエリ文字列およびリクエストボディは自由な表現が可能なため任意のリソースに利用できる。
広く知られるWebAPIスタイルの例として以下が挙げられる。
アプリケーションプログラミングインタフェース 実装
POSIX標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOSやBSD系システムで実装されている。ただし、ABIや実行ファイル形式は標準化されていないため、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。
一方、APIおよびABIに互換性があるシステムならば、どこでも同じバイナリをそのまま実行可能である。これはアプリケーションソフトウェアベンダーにもユーザーにも有益であり、ベンダーは互換API/ABIが実装されていれば新システムが登場してもアプリケーション製品を修正・リビルドせずに済むし、ユーザーも古いソフトウェアを後方互換性のある新システムにインストールして利用できる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。
アプリケーションプログラミングインタフェース 実装
WindowsはAPI/ABIに後方互換性があり、例えばVisual C++とWindows SDKを使用して開発されたアプリケーションは、ビルド時にWindows APIヘッダーをインクルードする前にWINVERおよび_WIN32_WINNTなどのシンボルが適切に定義されていれば、指定したバージョン以降のすべてのWindowsで動作する。廃止されたAPI関数などを使用していない限り、アプリケーションを修正・リビルドする必要はない。新しいバージョンのWindowsで追加された機能を使いたい場合、WINVERおよび_WIN32_WINNTをそのバージョンに合わせて定義するか、LoadLibrary関数を使用して動的ロードする。
なおWindows XP以降では、特定のバージョンのWindowsの実装や内部仕様に依存するなど、誤った実装や後方互換性を無視した実装により正常に動作しなくなってしまったアプリケーション向けに、「互換モード」が用意されている。これはシステム側が返す情報を特定バージョンのWindowsのものに偽装することで、アプリケーションをだますことにより動作させる救済措置であり、本来はアプリケーション側をAPI外部仕様に基づいて正しく修正することが好ましい。
アプリケーションプログラミングインタフェース 実装
Unix系OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinuxではLinux Standard Baseがある。BSD系OSも各種あるが、互換性のレベルは様々である。
Androidには「APIレベル」という概念が存在し、Android OSのバージョンごとにAPIレベルの番号が割り振られている。例えばAndroid 10はAPIレベル29に相当する。特定のAPIレベルで追加された機能（クラス、メソッド、フィールド）を利用するには、アプリケーションのビルド時に "AndroidManifest.xml"あるいは "build.gradle"にてtargetSdkVersionの値をそのAPIレベル番号以降に設定し、また指定されたバージョン以降のAndroid SDKを使ってビルドする必要がある。また、minSdkVersionの値によって、アプリケーションのインストールおよび実行に必要な最小システムバージョンを指定することができる。minSdkVersion以下の機能は（廃止されたものでない限り）無条件で使用できるが、minSdkVersionを超えるバージョンで追加された機能を使用する場合は、android.os.Build.VERSION クラスのSDK_INTフィールドの値に基づいて動的分岐する処理を実装する必要がある。
アプリケーションプログラミングインタフェース APIの例
ウィキメディア・エンタープライズAPI - 米国時間2025年11月10日に、Wikipediaを運営する非営利団体ウィキメディア財団は、AIを扱う企業へAIモデルのトレーニングを目的としたWikipedia等のデータ収集（スクレイピング）をする際に無断で行うのを止めて、ウィキメディア財団の提供する有料APIを利用し、Wikipedia等を出典としたことを示すクレジット表示と財政的支援を求める声明を発表した。
アプリケーションプログラミングインタフェース 公開の方針
APIの公開に関しては2つの一般的な方針がある。
自社のAPIを厳重に秘匿する。
例えばソニーはライセンスをもった開発者にしかPlayStationの公開APIを利用できないようにしている。なぜならPlayStationのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、PlayStation用コンソールの販売を中止している。）
自社のAPIを広く普及させる。
例えばマイクロソフトは計画的にAPIに関する情報を公開している。誰でも簡単にWindowsプラットフォーム用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。 OSなどのAPIは、いくつかのコードに分割され、ライブラリとして実装されており、OSと一緒に配布される。また直接アプリケーションの中に統合される必要があるAPIもある。
この2つの方針の中間もある。
アプリケーションプログラミングインタフェース APIと著作権の有無
アメリカ国内
2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを訴えた。Java APIを複製する許可（ライセンス）はOpenJDKプロジェクトやIBM J9などの実装には与えられていたが、一方AndroidのDalvik仮想マシンの実装はOpenJDKなどに基づいてはおらず、またGoogleはJava APIを複製する許可をとっていなかった。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年、最高裁によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した。ただしその後の審理を経て、2021年には著作権があってもフェアユースの下に利用可能であるとの判断が下されている。
日本国内
日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている。
他
互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。
アプリケーションプログラミングインタフェース 類似する概念
特にDDIやファームウェアインタフェースを使う場合は、ソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。
アプリケーションプログラミングインタフェース 言語束縛とインタフェースジェネレータ
複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。
以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。
アプリケーションプログラミングインタフェース （参考情報）ライブラリ形式の非API
Microsoft Windows、macOS、iOS、AndroidなどのOSには、API以外に、俗に「隠しAPI」や「プライベートAPI」「非公開API」などと呼ばれるライブラリ形式の非APIが存在する。これらの非APIは特定の共通処理をアプリケーション側ではなくシステム内部でのみ再利用することを想定して実装されており、例えばWindowsでは一部の非API関数がシステムDLLにエクスポートされていることから、LoadLibrary 関数を使用して呼び出すことができる。Javaや.NET Frameworkの場合は、カプセル化を破壊することになるが、隠蔽されたメソッドであってもリフレクションを使用して呼び出すことができる。しかし、これらはシステム／サービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの隠し機能を使ったアプリケーションの動作は保証されないし、互換性も将来に渡って保証されることはない。不具合修正があれば容易に変更あるいは破棄される。例えばWindows APIにおいて、timeBeginPeriod(), timeEndPeriod() はアプリケーション開発者向けに正式公開・ドキュメント化されているAPI関数だが、これらは内部でNtSetTimerResolution()を呼び出している。NtSetTimerResolution()は、Windows NT系のシステムDLLのひとつ、"ntdll.dll"にエクスポートされているが、アプリケーション開発者向けのドキュメントには記載されていない非API関数であり、この非API関数をアプリケーションで直接使用した場合の結果は保証されない。EclipseではPlugin開発にて非APIを使った場合エラーを出す設定がある。Appleが提供するApp StoreではAppleが作成した非APIを使ったアプリケーションは掲載を拒否される。
アプリケーションプログラミングインタフェース （参考情報）ライブラリとAPI
APIは関数、プロシージャ、変数やデータ構造といったライブラリによって実装されることが多いが、狭義のAPIではライブラリとAPIは同一ではない。
ライブラリ形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリ形式である場合も同一視せず区別する必要があるという理由がある。
例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリ関数と呼ぶ。
ライブラリ関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばC言語の標準ライブラリ関数であるfwriteは、Windows上ではAPI関数である WriteFile を使って実装されている。WriteFileはOSの機能に直接アクセスできることからfwriteよりも高機能であり、別OSへの移植性を考えなければfwriteの代わりにWriteFileを直接利用してアプリケーションを記述することもできる。同様に、Linuxでは writeシステムコールを利用して実装されている。