explain_lca2010 - ക്ലൗഡിൽ ഓൺലൈനിൽ

പട്ടിക:

NAME

explain_lca2010 - മീഡിയം ഒന്നും കണ്ടെത്തിയില്ല: വായിക്കാൻ ശ്രമിക്കുന്നത് നിർത്തേണ്ട സമയമാകുമ്പോൾ തീവ്രത(3) ന്റെ
മനസ്സ്.

പ്രചോദനം

1980 കളുടെ തുടക്കത്തിലാണ് ലിബെക്സ്‌പ്ലെയ്‌ൻ എന്ന ആശയം എനിക്ക് ഉണ്ടായത്. എപ്പോഴെങ്കിലും ഒരു സിസ്റ്റം കോൾ
ഒരു പിശക് നൽകുന്നു, എന്താണ് തെറ്റ് സംഭവിച്ചതെന്ന് കേർണലിന് കൃത്യമായി അറിയാം... കൂടാതെ ഇത് കംപ്രസ് ചെയ്യുന്നു
8 ബിറ്റുകളിൽ കുറവ് പിശക്. കേർണലിന്റെ അതേ ഡാറ്റയിലേക്ക് യൂസർ സ്‌പെയ്‌സിന് ആക്‌സസ് ഉണ്ട്
പിശക് പ്രകോപിപ്പിക്കുന്നതിന് എന്താണ് സംഭവിച്ചതെന്ന് കൃത്യമായി കണ്ടുപിടിക്കാൻ ഉപയോക്തൃ ഇടത്തിന് സാധ്യമാകണം
മടങ്ങുക, നല്ല പിശക് സന്ദേശങ്ങൾ എഴുതാൻ ഇത് ഉപയോഗിക്കുക.

അത് അത്ര ലളിതമായിരിക്കുമോ?

പിശക് സന്ദേശങ്ങൾ as ചടുലത
നല്ല പിശക് സന്ദേശങ്ങൾ പലപ്പോഴും ഷെഡ്യൂൾ ചെയ്യുമ്പോൾ ഒഴിവാക്കപ്പെടുന്ന "ഒരു ശതമാനം" ടാസ്ക്കുകളാണ്
സമ്മർദ്ദം നിങ്ങളുടെ പദ്ധതിയെ ഞെരുക്കുന്നു. എന്നിരുന്നാലും, ഒരു നല്ല പിശക് സന്ദേശം വളരെ വലുതാക്കിയേക്കാം,
ഉപയോക്തൃ അനുഭവത്തിന് ആനുപാതികമല്ലാത്ത മെച്ചപ്പെടുത്തൽ, ഉപയോക്താവ് ഭയപ്പെടുത്തുന്ന അവസ്ഥയിലേക്ക് അലയുമ്പോൾ
അജ്ഞാത പ്രദേശം സാധാരണയായി കണ്ടുമുട്ടില്ല. ഇത് എളുപ്പമുള്ള കാര്യമല്ല.

ഒരു ലാർവ പ്രോഗ്രാമർ എന്ന നിലയിൽ, രചയിതാവ് (പൂർണ്ണമായും കൃത്യമായ) പിശകിന്റെ പ്രശ്നം കണ്ടില്ല
ഇതുപോലുള്ള സന്ദേശങ്ങൾ:
ഫ്ലോട്ടിംഗ് ഒഴിവാക്കൽ (കോർ ഡംപ്ഡ്)
ഇതര നോൺ-പ്രോഗ്രാമർ വ്യാഖ്യാനം ചൂണ്ടിക്കാണിക്കപ്പെടുന്നതുവരെ. എന്നാൽ അതൊന്നുമല്ല
Unix പിശക് സന്ദേശങ്ങളിൽ മാത്രമാണ് തെറ്റ്. ഇനിപ്പറയുന്നതുപോലുള്ള പിശക് സന്ദേശങ്ങൾ നിങ്ങൾ എത്ര തവണ കാണുന്നു:
$ ./വിഡ്ഢി
ഫയൽ തുറക്കാൻ കഴിയില്ല
$
ഈ ഘട്ടത്തിൽ ഒരു ഡെവലപ്പർക്ക് രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്:

1.
നിങ്ങൾക്ക് ഒരു ഡീബഗ്ഗർ പ്രവർത്തിപ്പിക്കാൻ കഴിയും ജിഡിബി(1), അല്ലെങ്കിൽ

2.
നിങ്ങൾക്ക് ഉപയോഗിക്കാം സ്ട്രെയ്സ്(1) അല്ലെങ്കിൽ ട്രസ്(1) അകത്തേക്ക് നോക്കുക.

· നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് ഈ ടൂളുകളിലേക്ക് ആക്സസ് പോലും ഉണ്ടായിരിക്കില്ല എന്നത് ഓർക്കുക
അവരെ ഉപയോഗിക്കാൻ. (ഇത് വളരെക്കാലമായി യൂണിക്സ് തുടക്കക്കാരൻ അർത്ഥമാക്കുന്നത് “എഴുതിയിട്ടേയുള്ളൂ ഒന്ന്
ഉപകരണ ഡ്രൈവർ".)

ഈ ഉദാഹരണത്തിൽ, എന്നിരുന്നാലും, ഉപയോഗിക്കുന്നു സ്ട്രെയ്സ്(1) വെളിപ്പെടുത്തുന്നു
$ സ്ട്രെയ്സ് -e കണ്ടെത്തുക=തുറക്കുക ./വിഡ്ഢി
തുറക്കുക ("ചിലത്/ഫയൽ", O_RDONLY) = -1 ENOENT (അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല)
ഫയൽ തുറക്കാൻ കഴിയില്ല
$
പിശക് സന്ദേശം നൽകുന്നതിനേക്കാൾ കൂടുതൽ വിവരമാണിത്. സാധാരണഗതിയിൽ, ദി
മണ്ടത്തരമായ സോഴ്സ് കോഡ് ഇതുപോലെ കാണപ്പെടുന്നു
int fd = ഓപ്പൺ("ചില / കാര്യം", O_RDONLY);
എങ്കിൽ (fd < 0)
{
fprintf(stderr, "ഫയൽ തുറക്കാൻ കഴിയില്ല\n");
പുറത്ത്(1);
}
ഉപയോക്താവിനോട് പറഞ്ഞിട്ടില്ല ഏത് ഫയൽ, കൂടാതെ ഉപയോക്താവിനോട് പറയുന്നതിൽ പരാജയപ്പെടുന്നു ഏത് പിശക്. ഫയൽ ആയിരുന്നു
അവിടെ പോലും? ഒരു അനുമതി പ്രശ്നം ഉണ്ടായിരുന്നോ? അത് തുറക്കാൻ ശ്രമിക്കുന്നതായി നിങ്ങളോട് പറയുന്നു
ഫയൽ, പക്ഷേ അത് ആകസ്മികമായി സംഭവിച്ചതായിരിക്കാം.

നിങ്ങളുടെ ക്ലൂ സ്റ്റിക്ക് എടുത്ത് ലാർവ പ്രോഗ്രാമറെ അടിക്കുക. അവനോട് പറയൂ തെറ്റ്(3).
അടുത്ത തവണ നിങ്ങൾ പ്രോഗ്രാം ഉപയോഗിക്കുമ്പോൾ മറ്റൊരു പിശക് സന്ദേശം കാണുന്നു:
$ ./വിഡ്ഢി
തുറക്കുക: അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല
$
പുരോഗതി, പക്ഷേ ഞങ്ങൾ പ്രതീക്ഷിച്ചതല്ല. പിശക് സന്ദേശം വന്നാൽ ഉപയോക്താവിന് എങ്ങനെ പ്രശ്നം പരിഹരിക്കാനാകും
എന്താണ് പ്രശ്നം എന്ന് അവനോട് പറയുന്നില്ലേ? ഉറവിടം നോക്കുമ്പോൾ നമുക്ക് കാണാം
int fd = ഓപ്പൺ("ചില / കാര്യം", O_RDONLY);
എങ്കിൽ (fd < 0)
{
തെറ്റ് ("തുറന്ന");
പുറത്ത്(1);
}
ക്ലൂ സ്റ്റിക്കുമായി മറ്റൊരു ഓട്ടത്തിനുള്ള സമയം. ഈ സമയം, പിശക് സന്ദേശം ഒരു ഘട്ടം എടുക്കുന്നു
മുന്നോട്ട് ഒരു ചുവട് പിന്നോട്ട്:
$ ./വിഡ്ഢി
ചില / കാര്യം: ഇങ്ങനെ ഒരു ഫയലോ ഡയറക്ടറിയോ ഇല്ല
$
ഇപ്പോൾ അത് തുറക്കാൻ ശ്രമിച്ച ഫയൽ എന്താണെന്ന് ഞങ്ങൾക്കറിയാം, പക്ഷേ അത് അങ്ങനെയായിരുന്നെന്ന് ഇപ്പോൾ അറിയിച്ചിട്ടില്ല തുറക്കുക(2)
അത് പരാജയപ്പെട്ടു. ഈ സാഹചര്യത്തിൽ, ഇത് ഒരുപക്ഷേ പ്രാധാന്യമർഹിക്കുന്നില്ല, പക്ഷേ ഇത് പ്രാധാന്യമർഹിക്കുന്നു
മറ്റ് സിസ്റ്റം കോളുകൾ. അത് ആകാമായിരുന്നു സൃഷ്ടിക്കുക(2) പകരം, അത് സൂചിപ്പിക്കുന്ന ഒരു പ്രവർത്തനം
വ്യത്യസ്ത അനുമതികൾ ആവശ്യമാണ്.
കോൺസ്റ്റ് ചാർ *ഫയലിന്റെ പേര് = "ചില / കാര്യം";
int fd = ഓപ്പൺ (ഫയലിന്റെ പേര്, O_RDONLY);
എങ്കിൽ (fd < 0)
{
തെറ്റ് (ഫയൽ പേര്);
പുറത്ത്(1);
}
മുകളിലെ ഉദാഹരണ കോഡ് നിർഭാഗ്യവശാൽ നോൺ-ലാർവ പ്രോഗ്രാമർമാർക്കും സാധാരണമാണ്. സമയം
ഞങ്ങളുടെ പടവാൻ പഠിതാവിനോട് പറയാൻ തീവ്രത(3) സിസ്റ്റം കോൾ.
$ ./വിഡ്ഢി
തുറക്കുക ചില / കാര്യം: ഇങ്ങനെ ഒരു ഫയലോ ഡയറക്ടറിയോ ഇല്ല
$
ഇത് ഉപയോക്താവിന് അവതരിപ്പിക്കാൻ കഴിയുന്ന വിവരങ്ങൾ പരമാവധിയാക്കുന്നു. കോഡ് ഇതുപോലെ കാണപ്പെടുന്നു
ഈ:
കോൺസ്റ്റ് ചാർ *ഫയലിന്റെ പേര് = "ചില / കാര്യം";
int fd = ഓപ്പൺ (ഫയലിന്റെ പേര്, O_RDONLY);
എങ്കിൽ (fd < 0)
{
fprintf(stderr, "open %s: %s\n", ഫയലിന്റെ പേര്, strerror(errno));
പുറത്ത്(1);
}
ഇപ്പോൾ നമുക്ക് സിസ്റ്റം കോൾ, ഫയലിന്റെ പേര്, പിശക് സ്ട്രിംഗ് എന്നിവയുണ്ട്. ഇതിൽ എല്ലാം അടങ്ങിയിരിക്കുന്നു
വിവരം സ്ട്രെയ്സ്(1) അച്ചടിച്ചത്. അത് ലഭിക്കുന്നത് പോലെ നല്ലതാണ്.

അതോ?

പരിമിതികൾ of തെറ്റ് ഒപ്പം തീവ്രത
1980-കളിൽ രചയിതാവ് കണ്ട പ്രശ്നം, പിശക് സന്ദേശം അപൂർണ്ണമാണ് എന്നതാണ്.
"അത്തരം ഫയലോ ഡയറക്‌ടറിയോ ഇല്ല" എന്ന് സൂചിപ്പിക്കുന്നത് "കുറെ"ഡയറക്‌ടറി, അല്ലെങ്കിൽ "വസ്തു” ഫയലിൽ
“കുറെ” ഡയറക്ടറി?

എന്നതിനായുള്ള മാൻ പേജിലേക്ക് ഒരു ദ്രുത നോട്ടം തീവ്രത(3) പറയുന്നു:
strerror - പിശക് നമ്പർ വിവരിക്കുന്ന റിട്ടേൺ സ്ട്രിംഗ്
നന്നായി ശ്രദ്ധിക്കുക: ഇത് പിശക് വിവരിക്കുന്നു അക്കം, തെറ്റല്ല.

മറുവശത്ത്, കേർണൽ അറിയാം എന്താണ് തെറ്റ്. എന്നതിൽ ഒരു പ്രത്യേക പോയിന്റ് ഉണ്ടായിരുന്നു
കേർണൽ കോഡ്, ഒരു നിർദ്ദിഷ്‌ട അവസ്ഥ മൂലമുണ്ടാകുന്ന, അവിടെ കേർണൽ കോഡ് ശാഖകളായി "ഇല്ല" എന്ന് പറഞ്ഞു.
ഒരു ഉപയോക്തൃ-സ്പേസ് പ്രോഗ്രാമിന് നിർദ്ദിഷ്ട അവസ്ഥ കണ്ടുപിടിക്കാനും മികച്ച പിശക് എഴുതാനും കഴിയുമോ
സന്ദേശം?

എന്നിരുന്നാലും, പ്രശ്നം കൂടുതൽ ആഴത്തിൽ പോകുന്നു. ഈ സമയത്ത് പ്രശ്നം ഉണ്ടായാലോ വായിക്കുക(2) സിസ്റ്റം
എന്നതിനേക്കാൾ വിളിക്കുക തുറക്കുക(2) വിളിക്കണോ? ഇതുമായി ബന്ധപ്പെട്ട പിശക് സന്ദേശത്തിന് ഇത് ലളിതമാണ്
തുറക്കുക(2) ഫയലിന്റെ പേര് ഉൾപ്പെടുത്താൻ, അത് അവിടെ തന്നെയുണ്ട്. എന്നാൽ ഒരു ഫയലിന്റെ പേര് ഉൾപ്പെടുത്താൻ കഴിയും
എന്നതുമായി ബന്ധപ്പെട്ട പിശകിൽ വായിക്കുക(2) സിസ്റ്റം കോൾ, നിങ്ങൾ ഫയലിന്റെ പേര് എല്ലാം നൽകണം
കോൾ സ്റ്റാക്കിന്റെ താഴെയുള്ള വഴിയും ഫയൽ ഡിസ്ക്രിപ്റ്ററും.

കൂടാതെ, ഗ്രേറ്റ് ചെയ്യുന്ന ബിറ്റ് ഇതാ: ഫയലിന്റെ പേര് എന്താണെന്ന് കേർണലിന് ഇതിനകം അറിയാം
ഡിസ്ക്രിപ്റ്റർ ബന്ധപ്പെട്ടിരിക്കുന്നു. എന്തിനാണ് ഒരു പ്രോഗ്രാമർ അനാവശ്യ ഡാറ്റ മുഴുവൻ കൈമാറേണ്ടത്
ഒരിക്കലും ഇഷ്യൂ ചെയ്യപ്പെടാത്ത ഒരു പിശക് സന്ദേശം മെച്ചപ്പെടുത്താൻ കോൾ സ്റ്റാക്കിന് താഴെയുള്ള വഴി? ഇൻ
വാസ്തവത്തിൽ, പല പ്രോഗ്രാമർമാരും ബുദ്ധിമുട്ടിക്കുന്നില്ല, തത്ഫലമായുണ്ടാകുന്ന പിശക് സന്ദേശങ്ങൾ മോശമാണ്
അതു.

എന്നാൽ അത് 1980-കളിൽ, ഒരു PDP11-ൽ, പരിമിതമായ വിഭവങ്ങളും പങ്കിട്ട ലൈബ്രറികളുമില്ല. തിരികെ
പിന്നെ, Unix-ന്റെ ഒരു രസവും ഉൾപ്പെടുത്തിയിട്ടില്ല / proc അടിസ്ഥാന രൂപത്തിൽ പോലും, കൂടാതെ lsof(1) പ്രോഗ്രാം
ഒരു പതിറ്റാണ്ടിലേറെ അകലെയായിരുന്നു. അതുകൊണ്ട് ആ ആശയം അപ്രായോഗികമായി ഉപേക്ഷിച്ചു.

ലെവൽ അപാരത പിന്തുണ
നിങ്ങൾ ലെവൽ ഇൻഫിനിറ്റി സപ്പോർട്ട് ആണെന്ന് സങ്കൽപ്പിക്കുക. നിങ്ങളൊരിക്കലും ഇല്ലെന്ന് നിങ്ങളുടെ ജോലി വിവരണം പറയുന്നു
എന്നേക്കും ഉപയോക്താക്കളോട് സംസാരിക്കണം. എന്തുകൊണ്ടാണ്, ഇപ്പോഴും ആളുകൾ ആഗ്രഹിക്കുന്ന ഒരു നിരന്തര പ്രവാഹം
നിങ്ങൾ, പ്രാദേശിക യുണിക്സ് ഗുരു, മറ്റൊരു പിശക് സന്ദേശം മനസ്സിലാക്കണോ?

വിചിത്രമെന്നു പറയട്ടെ, 25 വർഷത്തിന് ശേഷം, ലളിതമായ ഒരു അനുമതി സംവിധാനം ഉണ്ടായിരുന്നിട്ടും, പൂർണ്ണമായി നടപ്പിലാക്കി
സ്ഥിരത, മിക്ക Unix ഉപയോക്താക്കൾക്കും ഇപ്പോഴും "അത്തരം ഫയലോ ഡയറക്‌ടറിയോ ഇല്ല" എങ്ങനെ ഡീകോഡ് ചെയ്യണമെന്ന് അറിയില്ല,
അല്ലെങ്കിൽ അവർ ദിവസവും കാണുന്ന മറ്റേതെങ്കിലും ഗൂഢമായ പിശക് സന്ദേശങ്ങൾ. അല്ലെങ്കിൽ, കുറഞ്ഞത്, നിഗൂഢമായത്
അവരെ.

ഫസ്റ്റ് ലെവൽ ടെക് സപ്പോർട്ടിന് പിശക് സന്ദേശങ്ങൾ ഡീക്രിപ്റ്റ് ചെയ്യേണ്ട ആവശ്യമില്ലെങ്കിൽ അത് നല്ലതല്ലേ?
വിളിക്കാതെ തന്നെ ഉപയോക്താക്കൾക്ക് മനസ്സിലാകുന്ന പിശക് സന്ദേശങ്ങൾ ലഭിക്കുന്നത് നല്ലതല്ലേ
സാങ്കേതിക പിന്തുണ?

ഇക്കാലം / proc ഡീകോഡ് ചെയ്യുന്നതിന് ആവശ്യമായ വിവരങ്ങൾ നൽകാൻ Linux-ന് കഴിയും
പിശക് സന്ദേശങ്ങളിൽ ഭൂരിഭാഗവും, കൂടാതെ ഉപയോക്താവിനെ അവയുടെ ഏകദേശ കാരണത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു
പ്രശ്നം. പരിമിതമായ സിസ്റ്റങ്ങളിൽ / proc നടപ്പിലാക്കൽ, ദി lsof(1) കമാൻഡ് പൂരിപ്പിക്കാൻ കഴിയും
പല വിടവുകളും.

2008-ൽ, വിവർത്തന അഭ്യർത്ഥനകളുടെ സ്ട്രീം രചയിതാവിന് പലപ്പോഴും സംഭവിച്ചു. ഇത് ഇങ്ങനെയായിരുന്നു
25 വർഷം പഴക്കമുള്ള ആ ആശയം പുനഃപരിശോധിക്കാൻ സമയമായി, അതിന്റെ ഫലമാണ് ലിബെക്സ്പ്ലൈൻ.

ഉപയോഗിക്കുന്നു ദി ലൈബ്രറി

ലൈബ്രറിയിലേക്കുള്ള ഇന്റർഫേസ് സാധ്യമാകുന്നിടത്ത് സ്ഥിരത പുലർത്താൻ ശ്രമിക്കുന്നു. ഒന്നിൽ നിന്ന് തുടങ്ങാം
ഉദാഹരണം ഉപയോഗിക്കുന്നു തീവ്രത(3):
എങ്കിൽ (പേരുമാറ്റുക(പഴയ_പാത, പുതിയ_പാത) < 0)
{
fprintf(stderr, "%s %s എന്നതിന്റെ പേര് മാറ്റുക: %s\n", old_path, new_path,
strerror (errno));
പുറത്ത്(1);
}
ലിബെക്‌സ്‌പ്ലെയ്‌ന് പിന്നിലെ ആശയം ഒരു നൽകുക എന്നതാണ് തീവ്രത(3) ഇതിന് തുല്യമാണ് ഓരോന്നും സിസ്റ്റം കോൾ,
ആ സിസ്റ്റം കോളിന് പ്രത്യേകമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു, അതിനാൽ ഇതിന് കൂടുതൽ വിശദമായ പിശക് നൽകാൻ കഴിയും
വിഭാഗത്തിന്റെ "പിശകുകൾ" എന്ന തലക്കെട്ടിന് കീഴിൽ നിങ്ങൾ കാണുന്ന മിക്ക വിവരങ്ങളും അടങ്ങിയ സന്ദേശം
2, 3 ഒന്ന് പേജുകൾ, യഥാർത്ഥ വ്യവസ്ഥകൾ, യഥാർത്ഥ ആർഗ്യുമെന്റ് എന്നിവയെക്കുറിച്ചുള്ള വിവരങ്ങൾക്കൊപ്പം അനുബന്ധമായി നൽകിയിരിക്കുന്നു
മൂല്യങ്ങൾ, സിസ്റ്റം പരിധികൾ.

ദി ലഘുവായ കേസ്
ദി തീവ്രത(3) മാറ്റിസ്ഥാപിക്കൽ:
എങ്കിൽ (പേരുമാറ്റുക(പഴയ_പാത, പുതിയ_പാത) < 0)
{
fprintf(stderr, "%s\n", explain_rename(old_path, new_path));
പുറത്ത്(1);
}

ദി തെറ്റ് കേസ്
ഒരു സ്പഷ്ടമായി കടന്നുപോകാനും സാധിക്കും പിശക്(3) മൂല്യം, നിങ്ങൾ ആദ്യം ചിലത് ചെയ്യണമെങ്കിൽ
ശല്യപ്പെടുത്തുന്ന പ്രോസസ്സിംഗ് പിശക്, പിശക് വീണ്ടെടുക്കൽ പോലെ:
എങ്കിൽ (പേരുമാറ്റുക(പഴയ_പാത, പുതിയ_പാത < 0))
{
int old_errno = തെറ്റ്;
...കോഡ് ആ ശല്യപ്പെടുത്തുന്നു പിശക്...
fprintf(stderr, "%s\n", explain_errno_rename(old_errno,
പഴയ_പാത, പുതിയ_പാത));
പുറത്ത്(1);
}

ദി മൾട്ടി-ത്രെഡ് കേസുകൾ
ചില ആപ്ലിക്കേഷനുകൾ മൾട്ടി-ത്രെഡുള്ളവയാണ്, അതിനാൽ ലിബെക്സ്പ്ലെയ്‌നിന്റെ ഇന്റേണൽ പങ്കിടാൻ കഴിയില്ല
ബഫർ. ഉപയോഗിച്ച് നിങ്ങളുടെ സ്വന്തം ബഫർ നൽകാം
എങ്കിൽ (അൺലിങ്ക് (പാഥനാമം))
{
ചാർ സന്ദേശം[3000];
explain_message_unlink(സന്ദേശം, വലുപ്പം(സന്ദേശം), പാതനാമം);
പിശക്_ഡയലോഗ്(സന്ദേശം);
മടക്കം -1;
}
പൂർണ്ണതയ്ക്കായി, രണ്ടും പിശക്(3) കൂടാതെ ത്രെഡ്-സേഫ്:
ssize_t nbytes = റീഡ് (fd, ഡാറ്റ, വലിപ്പം (ഡാറ്റ));
എങ്കിൽ (nbytes < 0)
{
ചാർ സന്ദേശം[3000];
int old_errno = തെറ്റ്;
...പിശക് വീണ്ടെടുക്കൽ...
explain_message_errno_read(സന്ദേശം, വലുപ്പം(സന്ദേശം),
old_errno, fd, data, sizeof(data));
പിശക്_ഡയലോഗ്(സന്ദേശം);
മടക്കം -1;
}

ഇവയ്ക്ക് പകരമാണ് strerror_r(3), അത് ഉള്ള സിസ്റ്റങ്ങളിൽ.

ഇന്റര്ഫേസ് പഞ്ചസാര
പ്രോഗ്രാമർമാരെ ഉപയോഗപ്പെടുത്താൻ സൗകര്യപ്രദമായ ഫംഗ്‌ഷനുകളായി ഒരു കൂട്ടം ഫംഗ്‌ഷനുകൾ ചേർത്തു
libexplain ലൈബ്രറി, രചയിതാവിന്റെ ഏറ്റവും സാധാരണയായി ഉപയോഗിക്കുന്ന libexplain ഫംഗ്‌ഷനുകളായി മാറുക
കമാൻഡ് ലൈൻ പ്രോഗ്രാമുകൾ:
int fd = explain_creat_or_die(ഫയലിന്റെ പേര്, 0666);
ഈ ഫംഗ്ഷൻ ഒരു പുതിയ ഫയൽ സൃഷ്ടിക്കാൻ ശ്രമിക്കുന്നു. അതിന് കഴിയുന്നില്ലെങ്കിൽ, അത് ഒരു പിശക് സന്ദേശം പ്രിന്റ് ചെയ്യുന്നു
EXIT_FAILURE ഉപയോഗിച്ച് പുറത്തുകടക്കുന്നു. പിശക് ഇല്ലെങ്കിൽ, അത് പുതിയ ഫയൽ ഡിസ്ക്രിപ്റ്റർ നൽകുന്നു.

ഒരു അനുബന്ധ പ്രവർത്തനം:
int fd = explain_creat_on_error(ഫയലിന്റെ പേര്, 0666);
പരാജയത്തിൽ പിശക് സന്ദേശം പ്രിന്റ് ചെയ്യും, എന്നാൽ യഥാർത്ഥ പിശക് ഫലം നൽകുന്നു, ഒപ്പം
പിശക്(3) അവിഹിതമാണ്, അതുപോലെ.

എല്ലാം The മറ്റ് സിസ്റ്റം കോളുകൾ
പൊതുവേ, ഓരോ സിസ്റ്റം കോളിനും അതിന്റേതായ ഉൾപ്പെടുത്തൽ ഫയൽ ഉണ്ട്
#ഉൾപ്പെടുന്നുപേര്.h>
ഇത് ആറ് ഫംഗ്ഷനുകൾക്കുള്ള ഫംഗ്ഷൻ പ്രോട്ടോടൈപ്പുകൾ നിർവചിക്കുന്നു:

· വിശദീകരിക്കാൻ_പേര്,

വിശദീകരിക്കുക_errno_പേര്,

വിശദമാക്കുക_message_പേര്,

വിശദീകരിക്കുക_message_errno_പേര്,

· വിശദീകരിക്കാൻ_പേര്_അല്ലെങ്കിൽ_മരിക്കുക ഒപ്പം

· വിശദീകരിക്കാൻ_പേര്_ഓൺ_എറർ.

എല്ലാ ഫംഗ്‌ഷൻ പ്രോട്ടോടൈപ്പിലും ഡോക്‌സിജൻ ഡോക്യുമെന്റേഷനും ഈ ഡോക്യുമെന്റേഷനും ഉണ്ട് is അല്ല നീക്കംചെയ്തു
ഉൾപ്പെടുത്തിയ ഫയലുകൾ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ.

ദി കാത്തിരിക്കുക(2) സിസ്റ്റം കോളിന് (സുഹൃത്തുക്കൾക്കും) പരാജയത്തെ വ്യാഖ്യാനിക്കുന്ന ചില അധിക വകഭേദങ്ങളുണ്ട്
EXIT_SUCCESS അല്ലാത്ത ഒരു എക്സിറ്റ് സ്റ്റാറ്റസ് ആകാൻ. ഇത് ബാധകമാണ് സിസ്റ്റം(3) ഉം അടയ്ക്കുക(3) ആയി
നന്നായി.

കവറേജിൽ 221 സിസ്റ്റം കോളുകളും 547 ioctl അഭ്യർത്ഥനകളും ഉൾപ്പെടുന്നു. ഇനിയും നിരവധി സംവിധാനങ്ങളുണ്ട്
വിളി ഇനിയും നടപ്പാക്കാനുണ്ട്. ഒരിക്കലും തിരികെ വരാത്ത സിസ്റ്റം കോളുകൾ പുറത്ത്(2), നിലവിലില്ല
ലൈബ്രറിയിൽ, ഒരിക്കലും ഉണ്ടാകില്ല. ദി exec സിസ്റ്റം കോളുകളുടെ കുടുംബം ആകുന്നു പിന്തുണച്ചു, കാരണം
ഒരു പിശക് ഉണ്ടാകുമ്പോൾ അവർ മടങ്ങിവരും.

പൂച്ച
പൂർണ്ണമായ പിശക് റിപ്പോർട്ടിംഗിനൊപ്പം ഒരു സാങ്കൽപ്പിക "കാറ്റ്" പ്രോഗ്രാമിന് ഇതുപോലെയായിരിക്കാം,
libexplain ഉപയോഗിച്ച്.
#ഉൾപ്പെടുന്നു
#ഉൾപ്പെടുന്നു
#ഉൾപ്പെടുന്നു
ലിബെക്‌സ്‌പ്ലെയ്‌നിനായി ഒന്ന് ഉൾപ്പെടുന്നു, കൂടാതെ സാധാരണ സംശയിക്കുന്നവരും. (നിങ്ങൾ കുറയ്ക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ
പ്രീപ്രൊസസ്സർ ലോഡ്, നിങ്ങൾക്ക് പ്രത്യേകം ഉപയോഗിക്കാംപേര്.h> ഉൾപ്പെടുന്നു.)
സ്റ്റാറ്റിക് അസാധുവാണ്
പ്രോസസ്സ് (FILE *fp)
{
വേണ്ടി (;;)
{
ചാർ ബഫർ[4096];
size_t n = explain_fread_or_die(ബഫർ, 1, sizeof(ബഫർ), fp);
എങ്കിൽ (!n)
പൊട്ടി;
വിശദീകരിക്കുക_fwrite_or_die(ബഫർ, 1, n, stdout);
}
}
ദി പ്രക്രിയ ഫംഗ്ഷൻ ഒരു ഫയൽ സ്ട്രീം സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിലേക്ക് പകർത്തുന്നു. ഒരു പിശക് സംഭവിച്ചാൽ
ഒന്നുകിൽ വായിക്കുന്നതിനോ എഴുതുന്നതിനോ വേണ്ടി, അത് റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു (കൂടാതെ പാതയുടെ പേര് ഇതിൽ ഉൾപ്പെടുത്തും
പിശക്) കൂടാതെ EXIT_FAILURE ഉപയോഗിച്ച് കമാൻഡ് പുറത്തുകടക്കുന്നു. ട്രാക്കുചെയ്യുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ വിഷമിക്കുന്നില്ല
പാതയുടെ പേരുകൾ, അല്ലെങ്കിൽ അവ കോൾ സ്റ്റാക്കിലൂടെ കടന്നുപോകുന്നു.
int
പ്രധാന (int argc, char ** argv)
{
വേണ്ടി (;;)
{
int c = getopt(argc, argv, "o:");
എങ്കിൽ (c == EOF)
പൊട്ടി;
സ്വിച്ച് (സി)
{
കേസ് 'o':
വിശദീകരിക്കുക_freopen_or_die(optarg, "w", stdout);
പൊട്ടി;
ഈ കോഡിന്റെ രസകരമായ ഭാഗം libexplain പിശകുകൾ റിപ്പോർട്ട് ചെയ്യാൻ കഴിയും എന്നതാണ് ഉൾപ്പെടെ The പാതയുടെ പേര് പോലും
നിങ്ങൾ എങ്കിൽ ചെയ്യരുത് ഇവിടെ ചെയ്യുന്നത് പോലെ stdout വ്യക്തമായി വീണ്ടും തുറക്കുക. നമ്മൾ വിഷമിക്കുക പോലും ചെയ്യുന്നില്ല
ഫയലിന്റെ പേര് ട്രാക്ക് ചെയ്യുന്നു.
സ്ഥിരസ്ഥിതി:
fprintf(stderr, "ഉപയോഗം: %ss [ -o ] ...\n",
argv[0]);
തിരികെ EXIT_FAILURE;
}
}
എങ്കിൽ (optind == argc)
പ്രക്രിയ (stdin);
മറ്റാരെങ്കിലും
{
അതേസമയം (optind < argc)
{
FILE *fp = explain_fopen_or_die(argv[optind]++, "r");
പ്രക്രിയ (fp);
വിശദീകരിക്കുക_fclose_or_die(fp);
}
}
സ്റ്റാൻഡേർഡ് ഔട്ട്‌പുട്ട് പരോക്ഷമായി അടയ്‌ക്കും, പക്ഷേ ഒരു പിശക് റിപ്പോർട്ട് വരാൻ വളരെ വൈകി
പുറപ്പെടുവിച്ചു, അതിനാൽ ഞങ്ങൾ അത് ഇവിടെ ചെയ്യുന്നു, ബഫർ ചെയ്ത I/O ഇതുവരെ ഒന്നും എഴുതിയിട്ടില്ലെങ്കിൽ, കൂടാതെ
ഒരു ENOSPC പിശക് അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും ഉണ്ട്.
വിശദീകരിക്കുക_fflush_or_die(stdout);
തിരികെ EXIT_SUCCESS;
}
അത്രയേയുള്ളൂ. പൂർണ്ണ പിശക് റിപ്പോർട്ടിംഗ്, വ്യക്തമായ കോഡ്.

റസ്റ്റിയുടെ സ്കെയിൽ of ഇന്റര്ഫേസ് നന്മ
നിങ്ങളിൽ ഇത് പരിചിതമല്ലാത്തവർക്കായി, റസ്റ്റി റസ്സലിന്റെ "എങ്ങനെയാണ് ഞാൻ ഇത് ദുരുപയോഗം ചെയ്യുന്നത് ബുദ്ധിമുട്ടിക്കുന്നത്?"
API ഡിസൈനർമാർ നിർബന്ധമായും വായിക്കേണ്ട പേജാണ്.
http://ozlabs.org/~rusty/index.cgi/tech/2008‐03‐30.html

10. ഇത് അസാധ്യമാണ് ലേക്ക് നേടുക തെറ്റ്.

ലക്ഷ്യങ്ങൾ ഉയർന്നതും അഭിലാഷത്തോടെ ഉയർന്നതുമായിരിക്കണം.
നിങ്ങൾ ഇല്ലാത്തപ്പോൾ പൂർത്തിയാക്കി.

libexplain ലൈബ്രറി വ്യാജ പോയിന്ററുകളും മറ്റ് പല വ്യാജ സിസ്റ്റം കോൾ പാരാമീറ്ററുകളും കണ്ടെത്തുന്നു,
ഏറ്റവും പ്രയാസകരമായ സാഹചര്യങ്ങളിൽപ്പോലും സെഗ്‌ഫാൾട്ടുകൾ ഒഴിവാക്കാൻ സാധാരണയായി ശ്രമിക്കുന്നു.

ത്രെഡ് സുരക്ഷിതമായി രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ് ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി. കൂടുതൽ യഥാർത്ഥ ലോക ഉപയോഗത്തിന് സാധ്യതയുണ്ട്
ഇത് മെച്ചപ്പെടുത്താൻ കഴിയുന്ന സ്ഥലങ്ങൾ വെളിപ്പെടുത്തുക.

ഏറ്റവും വലിയ പ്രശ്നം യഥാർത്ഥ ഫംഗ്ഷൻ പേരുകൾ തന്നെയാണ്. കാരണം സി ഇല്ല
നെയിം-സ്‌പെയ്‌സ്, ലിബെക്‌സ്‌പ്ലെയ്‌ൻ ലൈബ്രറി എപ്പോഴും ഒരു എക്‌സ്‌ലൈൻ_നെയിം പ്രിഫിക്‌സ് ഉപയോഗിക്കുന്നു. ഇതാണ്
ചിഹ്ന വൈരുദ്ധ്യങ്ങൾ ഒഴിവാക്കുന്നതിനായി ഒരു വ്യാജ-നാമം-സ്ഥലം സൃഷ്ടിക്കുന്നതിനുള്ള പരമ്പരാഗത രീതി.
എന്നിരുന്നാലും, ഇത് ചില അസ്വാഭാവിക-ശബ്ദ പേരുകൾക്ക് കാരണമാകുന്നു.

9. ദി കമ്പൈലർ or ലിങ്കർ ചെയ്യില്ല ചെയ്യട്ടെ നിങ്ങളെ നേടുക it തെറ്റ്.

വിശദീകരിക്കാൻ_ഓപ്പൺ_ഓപ്പൺ_ഡൈ ഉദ്ദേശിച്ചിടത്ത് വിശദീകരിക്കുക എന്നതാണ് പൊതുവായ തെറ്റ്.
ഭാഗ്യവശാൽ, ഈ ഘട്ടത്തിൽ കംപൈലർ പലപ്പോഴും ഒരു തരം പിശക് പുറപ്പെടുവിക്കും (ഉദാ അസൈൻ ചെയ്യാൻ കഴിയില്ല
const char * rvalue to an int lvalue).

8. ദി കമ്പൈലർ ഉദ്ദേശിക്കുന്ന മുന്നറിയിപ്പ് if നിങ്ങളെ നേടുക it തെറ്റ്.

Explan_rename_or_die ഉദ്ദേശിക്കുമ്പോൾ വിശദീകരിക്കുക_പേരുമാറ്റം ഉപയോഗിക്കുകയാണെങ്കിൽ, ഇത് മറ്റ് കാരണങ്ങളുണ്ടാക്കാം
പ്രശ്നങ്ങൾ. GCC ന് ഉപയോഗപ്രദമായ warn_unused_result ഫംഗ്‌ഷൻ ആട്രിബ്യൂട്ടും ലിബെക്‌സ്‌പ്ലെയ്‌നും ഉണ്ട്
എല്ലാ വിശദീകരണങ്ങളോടും ലൈബ്രറി അറ്റാച്ചുചെയ്യുന്നു_പേര് നിങ്ങൾ ചെയ്യുമ്പോൾ ഒരു മുന്നറിയിപ്പ് സൃഷ്ടിക്കാൻ ഫംഗ്ഷൻ കോളുകൾ
ഈ തെറ്റ് ചെയ്യുക. ഇതുമായി സംയോജിപ്പിക്കുക ജിസി -വെറർ ഇത് ലെവൽ 9 നന്മയിലേക്ക് പ്രോത്സാഹിപ്പിക്കുന്നതിന്.

7. ദി വ്യക്തമായ ഉപയോഗം is (ഒരുപക്ഷേ) The ശരിയാണ് ഒന്ന്.

ഫംഗ്‌ഷൻ പേരുകൾ അവയുടെ അർത്ഥം അറിയിക്കാൻ തിരഞ്ഞെടുത്തു, പക്ഷേ ഇത് എല്ലായ്പ്പോഴും അങ്ങനെയല്ല
വിജയിച്ചു. വിശദീകരിക്കുമ്പോൾ_പേര്_അല്ലെങ്കിൽ_മരിച്ച് വിശദീകരിക്കുക_പേര്_on_error തികച്ചും വിവരണാത്മകമാണ്,
അധികം ഉപയോഗിക്കാത്ത ത്രെഡ് സേഫ് വേരിയന്റുകൾ ഡീകോഡ് ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്. ഫംഗ്ഷൻ പ്രോട്ടോടൈപ്പുകൾ സഹായിക്കുന്നു
മനസ്സിലാക്കുന്നതിനുള്ള കംപൈലർ, കൂടാതെ ഹെഡർ ഫയലുകളിലെ ഡോക്‌സിജൻ അഭിപ്രായങ്ങൾ ഉപയോക്താവിനെ സഹായിക്കുന്നു
ധാരണയിലേക്ക്.

6. ദി പേര് പറയുന്നു നിങ്ങളെ എങ്ങനെ ലേക്ക് ഉപയോഗം അതു.

വിശദീകരിക്കാൻ വായിക്കേണ്ടത് വളരെ പ്രധാനമാണ്_പേര്_or_die ഇങ്ങനെ "വിശദീകരിക്കുക (പേര് അല്ലെങ്കില് മരിക്കുക)".
ഒരു സ്ഥിരതയുള്ള വിശദീകരിക്കൽ_ നെയിം-സ്പേസ് പ്രിഫിക്‌സ് ഉപയോഗിക്കുന്നത് ദൗർഭാഗ്യകരമായ ചില പാർശ്വഫലങ്ങൾ ഉണ്ടാക്കുന്നു
വ്യക്തമായ വകുപ്പും.

പേരുകളിലെ പദങ്ങളുടെ ക്രമവും വാദങ്ങളുടെ ക്രമത്തെ സൂചിപ്പിക്കുന്നു. വാദം
എപ്പോഴും പട്ടികപ്പെടുത്തുന്നു അവസാനിക്കുന്നു സിസ്റ്റം കോളിന് കൈമാറിയ അതേ ആർഗ്യുമെന്റുകൾക്കൊപ്പം; എല്ലാം of അവരെ. എങ്കിൽ
_errno_ എന്ന പേരിൽ പ്രത്യക്ഷപ്പെടുന്നു, അതിന്റെ ആർഗ്യുമെന്റ് എല്ലായ്പ്പോഴും സിസ്റ്റം കോൾ ആർഗ്യുമെന്റുകൾക്ക് മുമ്പാണ്. എങ്കിൽ
_message_ എന്ന പേരിൽ പ്രത്യക്ഷപ്പെടുന്നു, അതിന്റെ രണ്ട് ആർഗ്യുമെന്റുകൾ എപ്പോഴും ആദ്യം വരും.

5. Do it വലത് or it ഉദ്ദേശിക്കുന്ന ഇടവേള at റൺടൈം.

libexplain ലൈബ്രറി വ്യാജ പോയിന്ററുകളും മറ്റ് പല വ്യാജ സിസ്റ്റം കോൾ പാരാമീറ്ററുകളും കണ്ടെത്തുന്നു,
ഏറ്റവും പ്രയാസകരമായ സാഹചര്യങ്ങളിൽപ്പോലും സെഗ്‌ഫാൾട്ടുകൾ ഒഴിവാക്കാൻ സാധാരണയായി ശ്രമിക്കുന്നു. ഇത് ചെയ്തിരിക്കണം
റൺടൈമിൽ ഒരിക്കലും തകരരുത്, എന്നാൽ കൂടുതൽ യഥാർത്ഥ ഉപയോഗം ഇത് മെച്ചപ്പെടുത്തുമെന്നതിൽ സംശയമില്ല.

ചില പിശക് സന്ദേശങ്ങൾ അന്തിമ ഉപയോക്താക്കളേക്കാൾ ഡെവലപ്പർമാരെയും പരിപാലിക്കുന്നവരെയും ലക്ഷ്യം വച്ചുള്ളതാണ്
ബഗ് പരിഹാരത്തിൽ സഹായിക്കാനാകും. "ഇൻഫോർമേറ്റീവ് ആവുക" എന്നതുപോലെ "പ്രവർത്തിക്കുമ്പോൾ ബ്രേക്ക്" അല്ല
റൺടൈം” (സിസ്റ്റം കോൾ ബാർഫുകൾക്ക് ശേഷം).

4. പിന്തുടരുക സാധാരണ കൺവെൻഷൻ ഒപ്പം നിങ്ങൾ ചെയ്യും നേടുക it ശരി.

സിക്ക് നെയിം-സ്‌പെയ്‌സ് ഇല്ലാത്തതിനാൽ, ലിബെക്‌സ്‌പ്ലെയ്‌ൻ ലൈബ്രറി എല്ലായ്‌പ്പോഴും ഒരു വിശദീകരണ_നാമം ഉപയോഗിക്കുന്നു
ഉപസർഗ്ഗം. ഒഴിവാക്കാനായി ഒരു വ്യാജ-നാമം-സ്പേസ് സൃഷ്ടിക്കുന്നതിനുള്ള പരമ്പരാഗത മാർഗമാണിത്
ചിഹ്ന വൈരുദ്ധ്യങ്ങൾ.

എല്ലാ ലിബെക്സ്പ്ലെയ്ൻ കോളുകളുടെയും പിന്നിലുള്ള ആർഗ്യുമെന്റുകൾ സിസ്റ്റം കോളിന് സമാനമാണ്
വിവരിക്കുന്നു. ഇതുമായി പൊതുവായ ഒരു സ്ഥിരതയുള്ള കൺവെൻഷൻ നൽകാൻ ഉദ്ദേശിച്ചുള്ളതാണ്
സിസ്റ്റം സ്വയം വിളിക്കുന്നു.

3. വായിക്കുക The ഡോക്യുമെന്റേഷൻ ഒപ്പം നിങ്ങൾ ചെയ്യും നേടുക it ശരി.

ഓരോന്നിനും പൂർണ്ണമായ ഡോക്‌സിജൻ ഡോക്യുമെന്റേഷനാണ് ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി ലക്ഷ്യമിടുന്നത്
പൊതു API കോൾ (ആന്തരികമായും).

സന്ദേശം CONTENT

ലിബെക്‌സ്‌പ്ലെയ്‌നിൽ പ്രവർത്തിക്കുന്നത് നിങ്ങളുടെ കാർ ഓണായിരിക്കുമ്പോൾ അതിന്റെ അടിവശം നോക്കുന്നത് പോലെയാണ്
മെക്കാനിക്കിന്റെ ഹോസ്റ്റ്. അതിനടിയിൽ ചില വൃത്തികെട്ട വസ്‌തുക്കൾ ഉണ്ട്, കൂടാതെ ചെളിയും ചെളിയും
ഉപയോക്താക്കൾ ഇത് വളരെ അപൂർവമായി മാത്രമേ കാണൂ. ഒരു നല്ല പിശക് സന്ദേശം ഒരു ഉപയോക്താവിന് പോലും വിവരദായകമായിരിക്കണം
പലപ്പോഴും അടിവശം നോക്കേണ്ടി വരാതിരിക്കാനുള്ള ഭാഗ്യം ലഭിച്ചു
ഫോണിലൂടെ ഉപയോക്താവിന്റെ വിവരണം കേൾക്കുന്ന മെക്കാനിക്കിന് വിവരദായകമാണ്. ഇതാണ്
എളുപ്പമുള്ള കാര്യമില്ല.

ഞങ്ങളുടെ ആദ്യ ഉദാഹരണം വീണ്ടും സന്ദർശിക്കുമ്പോൾ, ലിബെക്സ്പ്ലെയ്ൻ ഉപയോഗിക്കുകയാണെങ്കിൽ കോഡ് ഇതുപോലെയാകും:
int fd = explain_open_or_die("some/thing", O_RDONLY, 0);
ഇതുപോലുള്ള ഒരു പിശക് സന്ദേശം ഉപയോഗിച്ച് പരാജയപ്പെടും
ഓപ്പൺ(പാഥനാമം = "ചിലത്/ഫയൽ", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല
(2, ENOENT) കാരണം നിലവിലെ ഡയറക്‌ടറിയിൽ "ചില" ഡയറക്ടറി ഇല്ല
ഇത് മൂന്ന് കഷണങ്ങളായി വിഭജിക്കുന്നു
സിസ്റ്റം-കോൾ പരാജയപ്പെട്ടു, സിസ്റ്റം-പിശക് കാരണം
വിശദീകരണം

മുമ്പ് കാരണം
"കാരണം" എന്നതിന് മുമ്പുള്ള സന്ദേശത്തിന്റെ ഭാഗം, അല്ലാത്തവയ്ക്ക് വളരെ സാങ്കേതികമായി കാണാൻ കഴിയും
സാങ്കേതിക ഉപയോക്താക്കൾ, മിക്കവാറും സിസ്റ്റം കോൾ തന്നെ കൃത്യമായി പ്രിന്റ് ചെയ്തതിന്റെ ഫലമായി
പിശക് സന്ദേശത്തിന്റെ തുടക്കം. അത് പോലെ തോന്നുന്നു സ്ട്രെയ്സ്(1) ഔട്ട്പുട്ട്, ബോണസ് ഗീക്കിനുള്ളത്
പോയിന്റ്.
ഓപ്പൺ(പാഥനാമം = "ചിലത്/ഫയൽ", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല
(2, ENOENT)
കോഡ് എഴുതുമ്പോൾ പിശക് സന്ദേശത്തിന്റെ ഈ ഭാഗം ഡെവലപ്പർക്ക് അത്യന്താപേക്ഷിതമാണ്,
ബഗ് റിപ്പോർട്ടുകൾ വായിക്കുകയും ബഗുകൾ പരിഹരിക്കുകയും ചെയ്യേണ്ട മെയിന്റനർമാർക്ക് ഒരുപോലെ പ്രധാനമാണ്
കോഡ്. എന്താണ് പരാജയപ്പെട്ടതെന്ന് കൃത്യമായി പറയുന്നു.

ഈ വാചകം ഉപയോക്താവിന് നൽകിയിട്ടില്ലെങ്കിൽ, ഉപയോക്താവിന് ഇത് പകർത്തി ഒട്ടിക്കാൻ കഴിയില്ല
ബഗ് റിപ്പോർട്ട്, അത് ബഗ് റിപ്പോർട്ടിൽ ഇല്ലെങ്കിൽ, യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിച്ചതെന്ന് പരിപാലിക്കുന്നയാൾക്ക് അറിയാൻ കഴിയില്ല
തെറ്റ്.

പലപ്പോഴും ടെക് ജീവനക്കാർ ഉപയോഗിക്കും സ്ട്രെയ്സ്(1) അല്ലെങ്കിൽ ട്രസ്(1) ഈ കൃത്യമായ വിവരങ്ങൾ ലഭിക്കാൻ, പക്ഷേ
ബഗ് റിപ്പോർട്ടുകൾ വായിക്കുമ്പോൾ ഈ വഴി തുറന്നിട്ടില്ല. ബഗ് റിപ്പോർട്ടർ സംവിധാനം വളരെ അകലെയാണ്
അകലെ, ഇപ്പോൾ, വളരെ വ്യത്യസ്തമായ അവസ്ഥയിലാണ്. അതിനാൽ, ഈ വിവരങ്ങൾ ഇതിൽ ഉണ്ടായിരിക്കണം
ബഗ് റിപ്പോർട്ട്, അതായത് അത് പിശക് സന്ദേശത്തിലായിരിക്കണം.

സിസ്റ്റം കോൾ പ്രാതിനിധ്യം സന്ദേശത്തിന്റെ ബാക്കി ഭാഗങ്ങൾക്ക് സന്ദർഭവും നൽകുന്നു. ആവശ്യമെങ്കിൽ
ഉദിക്കുന്നു, കുറ്റകരമായ സിസ്റ്റം കോൾ ആർഗ്യുമെന്റ് വിശദീകരണത്തിൽ പേര് ഉപയോഗിച്ച് പരാമർശിക്കാം
"കാരണം" ശേഷം. കൂടാതെ, എല്ലാ സ്ട്രിംഗുകളും പൂർണ്ണമായി ഉദ്ധരിച്ച് സി സ്ട്രിംഗുകളിൽ നിന്ന് രക്ഷപ്പെടുന്നു, അതിനാൽ
ഉൾച്ചേർത്ത ന്യൂലൈനുകളും പ്രിന്റ് ചെയ്യാത്ത പ്രതീകങ്ങളും ഉപയോക്താവിന്റെ ടെർമിനൽ പോകുന്നതിന് കാരണമാകില്ല
പുൽത്തകിടി.

ദി സിസ്റ്റം-പിശക് പുറത്തു വരുന്നതാണ് തീവ്രത(2), കൂടാതെ പിശക് ചിഹ്നവും. അക്ഷമയും
വിദഗ്‌ദ്ധരായ സിസാഡ്‌മിൻമാർക്ക് ഈ ഘട്ടത്തിൽ വായന നിർത്താനാവും, പക്ഷേ രചയിതാവിന്റെ ഇന്നേവരെയുള്ള അനുഭവം ഇതാണ്
തുടർന്നുള്ള വായന പ്രതിഫലദായകമാണെന്ന്. (ഇത് പ്രതിഫലദായകമല്ലെങ്കിൽ, ഇത് ഒരുപക്ഷേ ഒരു മേഖലയാണ്
മെച്ചപ്പെടുത്താൻ കഴിയുമെന്ന് വിശദീകരിക്കുക. കോഡ് സംഭാവനകൾ സ്വാഗതം ചെയ്യുന്നു, തീർച്ചയായും.)

ശേഷം കാരണം
സാങ്കേതികമല്ലാത്ത ഉപയോക്താക്കളെ ലക്ഷ്യമിട്ടുള്ള പിശക് സന്ദേശത്തിന്റെ ഭാഗമാണിത്. അത് അപ്പുറത്തേക്ക് നോക്കുന്നു
ലളിതമായ സിസ്റ്റം കോൾ ആർഗ്യുമെന്റുകൾ, കൂടുതൽ വ്യക്തമായ എന്തെങ്കിലും തിരയുന്നു.
നിലവിലെ ഡയറക്‌ടറിയിൽ "ചില" ഡയറക്ടറി ഇല്ല
ഈ ഭാഗം പിശകിന്റെ പ്രോക്സിമൽ കാരണം ലളിതമായ ഭാഷയിൽ വിശദീകരിക്കാൻ ശ്രമിക്കുന്നു, അത്
ഇവിടെ അന്താരാഷ്ട്രവൽക്കരണം അനിവാര്യമാണ്.

പൊതുവേ, ഉപയോക്താവിന് കഴിയുന്നത്ര വിവരങ്ങൾ ഉൾപ്പെടുത്തുക എന്നതാണ് നയം
അത് അന്വേഷിക്കേണ്ട ആവശ്യമില്ല (ബഗ് റിപ്പോർട്ടിൽ നിന്ന് അത് ഉപേക്ഷിക്കുകയുമില്ല).

അന്തർദേശീയവൽക്കരണം
ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറിയിലെ മിക്ക പിശക് സന്ദേശങ്ങളും അന്താരാഷ്ട്രവൽക്കരിക്കപ്പെട്ടിരിക്കുന്നു. അവിടെ
ഇതുവരെ പ്രാദേശികവൽക്കരണങ്ങളൊന്നുമില്ല, അതിനാൽ നിങ്ങളുടെ മാതൃഭാഷയിൽ വിശദീകരണങ്ങൾ വേണമെങ്കിൽ,
ദയവായി സംഭാവന ചെയ്യുക.

മുകളിലുള്ള "മിക്കവാറും" യോഗ്യതയുള്ളത്, ആശയത്തിന്റെ തെളിവ് എന്ന വസ്തുതയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു
നടപ്പാക്കലിൽ അന്താരാഷ്ട്രവൽക്കരണ പിന്തുണ ഉൾപ്പെട്ടിരുന്നില്ല. കോഡ് ബേസ് ആണ്
ക്രമാനുഗതമായി പരിഷ്‌ക്കരിക്കപ്പെടുന്നു, സാധാരണയായി സന്ദേശങ്ങൾ റീഫാക്‌ടറിംഗ് ചെയ്യുന്നതിന്റെ ഫലമായി ഓരോ പിശകും
സന്ദേശ സ്ട്രിംഗ് ഒരു തവണ കോഡിൽ ദൃശ്യമാകുന്നു.

യുടെ ഭാഗങ്ങൾ കൂട്ടിച്ചേർക്കേണ്ട ഭാഷകൾക്കായി വ്യവസ്ഥ ചെയ്തിട്ടുണ്ട്
സിസ്റ്റം-കോൾ പരാജയപ്പെട്ടു, സിസ്റ്റം-പിശക് കാരണം വിശദീകരണം
പ്രാദേശികവൽക്കരിച്ച പിശക് സന്ദേശങ്ങളിൽ ശരിയായ വ്യാകരണത്തിനായി വ്യത്യസ്ത ഓർഡറുകളിൽ.

പോസ്റ്റ്‌മോർട്ടം
ഒരു പ്രോഗ്രാമിന് ഇതുവരെ ലിബെക്സ്പ്ലെയ്ൻ ഉപയോഗിക്കാത്ത സമയങ്ങളുണ്ട്, നിങ്ങൾക്ക് ഉപയോഗിക്കാൻ കഴിയില്ല സ്ട്രെയ്സ്(1)
ഒന്നുകിൽ. ഒരു ഉണ്ട് വിശദീകരിക്കാൻ(1) ലിബെക്സ്പ്ലെയ്‌നിനൊപ്പം കമാൻഡ് ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, അത് ഉപയോഗിക്കാൻ കഴിയും
അടിസ്ഥാന സിസ്റ്റത്തിന്റെ അവസ്ഥ വളരെയധികം മാറിയിട്ടില്ലെങ്കിൽ, പിശക് സന്ദേശങ്ങൾ മനസ്സിലാക്കുക.
$ വിശദീകരിക്കാൻ പേരുമാറ്റുക ഫൂ /tmp/bar/baz -e ENOENT
പേരുമാറ്റുക(oldpath = "foo", newpath = "/tmp/bar/baz") പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല
(2, ENOENT) കാരണം ന്യൂപാത്തിൽ "ബാർ" ഡയറക്‌ടറി ഇല്ല "/ tmp"ഡയറക്‌ടറി
$
സിസ്റ്റം കോൾ ആർഗ്യുമെന്റ് നെയിം ഉപയോഗിച്ച് പാത്ത് അവ്യക്തത എങ്ങനെ പരിഹരിക്കപ്പെടുന്നു എന്നത് ശ്രദ്ധിക്കുക. ഓഫ്
തീർച്ചയായും, നിങ്ങൾ പിശകും സിസ്റ്റം കോളും അറിഞ്ഞിരിക്കണം വിശദീകരിക്കാൻ(1) ഉപയോഗപ്രദമാകും. ഒരു പോലെ
മാറ്റിനിർത്തിയാൽ, അത് സ്ഥിരീകരിക്കാൻ ലിബെക്സ്പ്ലെയ്ൻ ഓട്ടോമാറ്റിക് ടെസ്റ്റ് സ്യൂട്ട് ഉപയോഗിക്കുന്ന ഒരു മാർഗമാണിത്
libexplain പ്രവർത്തിക്കുന്നു.

തത്ത്വശാസ്ത്രം
"എനിക്ക് അന്വേഷിക്കാൻ അറിയാത്ത കാര്യങ്ങൾ ഉൾപ്പെടെ എല്ലാം എന്നോട് പറയൂ."

സ്ഥിരമായി ലിങ്ക് ചെയ്‌തിരിക്കുമ്പോൾ, നിങ്ങൾ മാത്രം കോഡ് ചെയ്യുന്ന തരത്തിലാണ് ലൈബ്രറി നടപ്പിലാക്കുന്നത്
യഥാർത്ഥത്തിൽ ഉപയോഗം ലിങ്ക് ചെയ്യപ്പെടും. ഓരോ സോഴ്‌സ് ഫയലിനും ഒരു ഫംഗ്‌ഷൻ ഉള്ളതിനാൽ ഇത് നേടാനാകും,
സാധ്യമാകുമ്പോഴെല്ലാം.

കൂടുതൽ വിവരങ്ങൾ നൽകാൻ കഴിയുമ്പോൾ, libexplain അങ്ങനെ ചെയ്യും. ഉപയോക്താവ് കുറവാണ്
തങ്ങൾക്കായി ട്രാക്ക് ചെയ്യണം, നല്ലത്. ഇതിനർത്ഥം യുഐഡികൾക്കൊപ്പം
ഉപയോക്തൃനാമം, GID-കൾ ഗ്രൂപ്പിന്റെ പേരിനൊപ്പം ഉണ്ട്, PID-കൾ പ്രക്രിയയ്‌ക്കൊപ്പമുണ്ട്
പേര്, ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ, സ്ട്രീമുകൾ എന്നിവ പാത്ത് നെയിമിനൊപ്പം ഉണ്ട്, തുടങ്ങിയവ.

പാതകൾ പരിഹരിക്കുമ്പോൾ, ഒരു പാത്ത് ഘടകം നിലവിലില്ലെങ്കിൽ, ലിബെക്സ്പ്ലെയ്ൻ സമാനമായി നോക്കും
ടൈപ്പോഗ്രാഫിക്കൽ പിശകുകൾക്കുള്ള ബദലുകൾ നിർദ്ദേശിക്കുന്നതിനായി പേരുകൾ.

ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി കഴിയുന്നത്ര ചെറിയ കൂമ്പാരം ഉപയോഗിക്കാൻ ശ്രമിക്കുന്നു, സാധാരണയായി ഒന്നുമില്ല. ഇതാണ്
പ്രക്രിയയുടെ അവസ്ഥയെ തടസ്സപ്പെടുത്തുന്നത് ഒഴിവാക്കാൻ, കഴിയുന്നിടത്തോളം, ചിലപ്പോൾ അങ്ങനെയാണെങ്കിലും
ഒഴിവാക്കാനാവില്ല.

ഗ്ലോബൽ വേരിയബിളുകൾ ഒഴിവാക്കിക്കൊണ്ട് ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി ത്രെഡ് സുരക്ഷിതമാക്കാൻ ശ്രമിക്കുന്നു
കഴിയുന്നത്ര സ്റ്റാക്കിൽ പ്രസ്താവിക്കുക. ഒരൊറ്റ പൊതുവായ സന്ദേശ ബഫർ ഉണ്ട്, കൂടാതെ
ഇത് ഉപയോഗിക്കുന്ന പ്രവർത്തനങ്ങൾ ത്രെഡ് സുരക്ഷിതമല്ലെന്ന് രേഖപ്പെടുത്തുന്നു.

libexplain ലൈബ്രറി ഒരു പ്രക്രിയയുടെ സിഗ്നൽ ഹാൻഡ്‌ലറുകളെ ശല്യപ്പെടുത്തുന്നില്ല. ഇത് ഉണ്ടാക്കുന്നു
ഒരു പോയിന്റർ ഒരു വെല്ലുവിളിയെ നേരിടുമോ എന്ന് നിർണ്ണയിക്കുന്നു, പക്ഷേ അസാധ്യമല്ല.

ഒരു സിസ്റ്റം കോൾ വഴിയും എ വഴിയും വിവരങ്ങൾ ലഭ്യമാകുമ്പോൾ / proc
പ്രവേശനം, സിസ്റ്റം കോൾ തിരഞ്ഞെടുക്കുന്നതാണ്. പ്രക്രിയയുടെ അവസ്ഥയെ തടസ്സപ്പെടുത്തുന്നത് ഒഴിവാക്കാനാണിത്.
ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ ലഭ്യമല്ലാത്ത സമയങ്ങളുമുണ്ട്.

വലിയ ഫയൽ പിന്തുണയോടെയാണ് libexplain ലൈബ്രറി സമാഹരിച്ചിരിക്കുന്നത്. വലുത്/ചെറുതായി ഒന്നുമില്ല
സ്കീസോഫ്രീനിയ. എപിഐയിലെ ആർഗ്യുമെന്റ് തരങ്ങളെ ഇത് ബാധിക്കുമ്പോൾ, പിശക് നൽകപ്പെടും
ആവശ്യമായ വലിയ ഫയൽ നിർവ്വചിക്കുന്നില്ലെങ്കിൽ.

FIXME: ഫയൽ സിസ്റ്റം ക്വാട്ടകൾ കോഡിൽ കൈകാര്യം ചെയ്യുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ജോലി ആവശ്യമാണ്. ഈ
ചിലർക്ക് ബാധകമാണ് പരിധി(2) അതിരുകൾ, അതുപോലെ.

ബന്ധുക്കളുടെ പാതകൾ വിവരമില്ലാത്ത സന്ദർഭങ്ങളുണ്ട്. ഉദാഹരണത്തിന്: സിസ്റ്റം ഡെമൺസ്,
സെർവറുകളും പശ്ചാത്തല പ്രക്രിയകളും. ഈ സന്ദർഭങ്ങളിൽ, പിശകിൽ കേവല പാതകൾ ഉപയോഗിക്കുന്നു
വിശദീകരണങ്ങൾ.

PATH പരിഹാരം

ഹ്രസ്വ പതിപ്പ്: കാണുക പാത്ത്_റെസല്യൂഷൻ(7).

ദൈർഘ്യമേറിയ പതിപ്പ്: മിക്ക ഉപയോക്താക്കളും ഒരിക്കലും കേട്ടിട്ടില്ല പാത്ത്_റെസല്യൂഷൻ(7), കൂടാതെ നിരവധി വിപുലമായ ഉപയോക്താക്കളും
ഒരിക്കലും വായിച്ചിട്ടില്ല. ഒരു വ്യാഖ്യാന പതിപ്പ് ഇതാ:

ഘട്ടം 1: ആരംഭിക്കുക of The ചിത്രം പ്രക്രിയ
പാതയുടെ പേര് സ്ലാഷ് (“/”) പ്രതീകത്തിലാണ് ആരംഭിക്കുന്നതെങ്കിൽ, ആരംഭിക്കുന്ന ലുക്കപ്പ് ഡയറക്‌ടറി ഇതാണ്
കോളിംഗ് പ്രക്രിയയുടെ റൂട്ട് ഡയറക്ടറി.

പാതയുടെ പേര് സ്ലാഷ് (“/”) പ്രതീകത്തിൽ ആരംഭിക്കുന്നില്ലെങ്കിൽ, ആരംഭ ലുക്ക്അപ്പ്
റെസല്യൂഷൻ പ്രക്രിയയുടെ ഡയറക്ടറിയാണ് പ്രോസസ്സിന്റെ നിലവിലെ പ്രവർത്തന ഡയറക്ടറി.

ഘട്ടം 2: നടക്കുക കൂടെ The പാത
നിലവിലെ ലുക്കപ്പ് ഡയറക്‌ടറി ആരംഭിക്കുന്ന ലുക്കപ്പ് ഡയറക്‌ടറിയിലേക്ക് സജ്ജമാക്കുക. ഇപ്പോൾ, ഓരോ അല്ലാത്തവർക്കും
പാത്ത് നെയിമിന്റെ അവസാന ഘടകം, ഇവിടെ ഒരു ഘടകം സ്ലാഷ് (“/”) കൊണ്ട് വേർതിരിച്ച ഒരു ഉപസ്‌ട്രിംഗാണ്
പ്രതീകങ്ങൾ, ഈ ഘടകം നിലവിലെ ലുക്ക്അപ്പ് ഡയറക്ടറിയിൽ തിരയുന്നു.

നിലവിലെ ലുക്കപ്പ് ഡയറക്‌ടറിയിൽ പ്രോസസ്സിന് തിരയൽ അനുമതി ഇല്ലെങ്കിൽ, ഒരു EACCES
പിശക് തിരികെ ലഭിച്ചു ("അനുമതി നിരസിച്ചു").
ഓപ്പൺ(പാഥനാമം = "/home/archives/.ssh/private_key", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു,
അനുമതി നിരസിച്ചു (13, EACCES) കാരണം പ്രോസസ്സിന് തിരയൽ അനുമതിയില്ല
"/home/archives/.ssh" ഡയറക്‌ടറിയുടെ പാത്ത്‌നെയിമിലേക്ക്, പ്രോസസ്സ് ഫലപ്രദമാണ് GID 1000
"pmiller" ഡയറക്‌ടറി ഉടമ 1001 "ആർക്കൈവുകൾ" എന്നതുമായി പൊരുത്തപ്പെടുന്നില്ല, അതിനാൽ ഉടമ
അനുമതി മോഡ് "rwx" അവഗണിക്കപ്പെട്ടു, മറ്റ് അനുമതി മോഡ് "---" ആണ്, കൂടാതെ
പ്രോസസ്സിന് പ്രത്യേകാവകാശമില്ല (DAC_READ_SEARCH കഴിവില്ല)

ഘടകം കണ്ടെത്തിയില്ലെങ്കിൽ, ഒരു ENOENT പിശക് ലഭിക്കും ("അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല").
unlink(pathname = "/home/microsoft/rubbish") പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല (2,
ENOENT) കാരണം "മൈക്രോസോഫ്റ്റ്" ഡയറക്‌ടറി "പാത്ത് നെയിമിൽ ഇല്ല"/ home"ഡയറക്‌ടറി

ഉപയോക്താക്കൾ പാത്ത് നെയിമുകൾ തെറ്റായി ടൈപ്പ് ചെയ്യുമ്പോഴും നിർദ്ദേശങ്ങൾ നൽകുമ്പോഴും അവർക്ക് ചില പിന്തുണയുണ്ട്
ENOENT തിരികെ നൽകി:
open(pathname = "/user/include/fcntl.h", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, അത്തരം ഫയലുകളൊന്നുമില്ല അല്ലെങ്കിൽ
ഡയറക്‌ടറി (2, ENOENT) കാരണം "/" എന്ന പാതയിൽ "ഉപയോക്തൃ" ഡയറക്ടറി ഇല്ല
ഡയറക്ടറി, പകരം "usr" ഡയറക്‌ടറിയാണോ നിങ്ങൾ ഉദ്ദേശിച്ചത്?

ഘടകം കണ്ടെത്തിയാൽ, ഒരു ഡയറക്ടറിയോ പ്രതീകാത്മക ലിങ്കോ അല്ല, ഒരു ENOTDIR
പിശക് തിരികെ ലഭിച്ചു ("ഒരു ഡയറക്ടറി അല്ല").
ഓപ്പൺ(പാഥനാമം = "/home/pmiller/.netrc/lca", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, ഒരു അല്ല
ഡയറക്‌ടറി (20, ENOTDIR) കാരണം പാത്ത്‌നാമിലെ ".netrc" റെഗുലർ ഫയൽ ആണ്
"/home/pmiller" ഡയറക്‌ടറി അല്ലാത്തപ്പോൾ ഒരു ഡയറക്‌ടറിയായി ഉപയോഗിക്കുന്നു

ഘടകം കണ്ടെത്തി ഒരു ഡയറക്‌ടറി ആണെങ്കിൽ, ഞങ്ങൾ നിലവിലെ ലുക്ക്അപ്പ് ഡയറക്‌ടറി അതിനായി സജ്ജമാക്കുന്നു
ഡയറക്ടറി, അടുത്ത ഘടകത്തിലേക്ക് പോകുക.

ഘടകം കണ്ടെത്തുകയും ഒരു പ്രതീകാത്മക ലിങ്ക് (സിംലിങ്ക്) ആണെങ്കിൽ, ഞങ്ങൾ ആദ്യം ഈ പ്രതീകാത്മകത പരിഹരിക്കുന്നു
ലിങ്ക് (നിലവിലെ ലുക്ക്അപ്പ് ഡയറക്‌ടറി ആരംഭിക്കുന്ന ലുക്കപ്പ് ഡയറക്‌ടറിക്കൊപ്പം). പിശക് മേൽ, അത്
പിശക് തിരികെ ലഭിച്ചു. ഫലം ഒരു ഡയറക്ടറി അല്ലെങ്കിൽ, ഒരു ENOTDIR പിശക് തിരികെ നൽകും.
unlink(pathname = "/tmp/dangling/rubbish") പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്ടറിയോ ഇല്ല (2,
ENOENT) കാരണം "തൂങ്ങിക്കിടക്കുന്ന" പാതയുടെ പേരിലുള്ള പ്രതീകാത്മക ലിങ്ക് "/ tmp"ഡയറക്‌ടറി
നിലവിലില്ലാത്ത "എവിടെയും" സൂചിപ്പിക്കുന്നു
സിംലിങ്കിന്റെ റെസല്യൂഷൻ വിജയിക്കുകയും ഒരു ഡയറക്ടറി തിരികെ നൽകുകയും ചെയ്താൽ, ഞങ്ങൾ കറന്റ് സജ്ജമാക്കുന്നു
ആ ഡയറക്ടറിയിലേക്ക് ഡയറക്ടറി നോക്കുക, അടുത്ത ഘടകത്തിലേക്ക് പോകുക. എന്നത് ശ്രദ്ധിക്കുക
ഇവിടെ റെസലൂഷൻ പ്രക്രിയയിൽ ആവർത്തനം ഉൾപ്പെടുന്നു. സ്റ്റാക്കിൽ നിന്ന് കേർണലിനെ സംരക്ഷിക്കുന്നതിന്
ഓവർഫ്ലോ, കൂടാതെ സേവന നിഷേധത്തിൽ നിന്ന് പരിരക്ഷിക്കുന്നതിന്, പരമാവധി പരിധികൾ ഉണ്ട്
ആവർത്തനത്തിന്റെ ആഴവും പിന്തുടരുന്ന പരമാവധി പ്രതീകാത്മക ലിങ്കുകളും. ഒരു ELOOP പിശകാണ്
പരമാവധി കവിയുമ്പോൾ തിരികെ നൽകും ("സിംബോളിക് ലിങ്കുകളുടെ വളരെയധികം തലങ്ങൾ").
ഓപ്പൺ(പാഥനാമം = "/tmp/dangling", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, നിരവധി ലെവലുകൾ
പ്രതീകാത്മക ലിങ്കുകൾ (40, ELOOP) കാരണം ഒരു പ്രതീകാത്മക ലിങ്ക് ലൂപ്പ് നേരിട്ടു
പാതയുടെ പേര്, "/tmp/dangling"-ൽ ആരംഭിക്കുന്നു
വളരെയധികം സിംലിങ്കുകൾ ഉണ്ടെങ്കിൽ ഒരു ELOOP അല്ലെങ്കിൽ EMLINK പിശക് ലഭിക്കാനും സാധ്യതയുണ്ട്, പക്ഷേ ഇല്ല
ലൂപ്പ് കണ്ടെത്തി.
ഓപ്പൺ(പാഥനാമം = "/tmp/rabit‐hole", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, നിരവധി ലെവലുകൾ
പ്രതീകാത്മക ലിങ്കുകൾ (40, ELOOP) കാരണം നിരവധി പ്രതീകാത്മക ലിങ്കുകൾ നേരിട്ടു
പാതയുടെ പേര് (8)
യഥാർത്ഥ പരിധി അച്ചടിച്ചതെങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക.

ഘട്ടം 3: കണ്ടെത്തുക The ഫൈനലിൽ എൻട്രി
പാത്ത് നെയിമിന്റെ അവസാന ഘടകത്തിന്റെ ലുക്ക്അപ്പ് മറ്റെല്ലാത്തേയും പോലെ തന്നെ പോകുന്നു
ഘടകങ്ങൾ, മുമ്പത്തെ ഘട്ടത്തിൽ വിവരിച്ചതുപോലെ, രണ്ട് വ്യത്യാസങ്ങളോടെ:

(i) അവസാന ഘടകം ഒരു ഡയറക്‌ടറി ആയിരിക്കണമെന്നില്ല (കുറഞ്ഞത് പാത്ത് റെസലൂഷൻ വരെയെങ്കിലും
പ്രക്രിയ ആശങ്കാകുലമാണ്. ഇത് ഒരു ഡയറക്‌ടറിയോ നോൺ-ഡയറക്‌ടറിയോ ആയിരിക്കാം, കാരണം
നിർദ്ദിഷ്ട സിസ്റ്റം കോളിന്റെ ആവശ്യകതകൾ).

(ii)
അന്തിമ ഘടകം കണ്ടെത്തിയില്ലെങ്കിൽ അത് ഒരു പിശക് ആയിരിക്കണമെന്നില്ല; ഒരുപക്ഷേ നമ്മൾ വെറുതെയായിരിക്കാം
അത് സൃഷ്ടിക്കുന്നു. ഫൈനൽ എൻട്രിയുടെ ചികിത്സയെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ വിവരിച്ചിരിക്കുന്നു
നിർദ്ദിഷ്ട സിസ്റ്റം കോളുകളുടെ മാനുവൽ പേജുകൾ.

(iii)
ഒരു പ്രതീകാത്മക ലിങ്ക് ആണെങ്കിൽ അവസാന ഘടകത്തിന് പ്രശ്നമുണ്ടാകാനും സാധ്യതയുണ്ട്
അത് പാലിക്കാൻ പാടില്ല. ഉദാഹരണത്തിന്, ഉപയോഗിക്കുന്നത് തുറക്കുക(2) O_NOFOLLOW ഫ്ലാഗ്:
ഓപ്പൺ(പാഥനാമം = "എ‐സിംലിങ്ക്", ഫ്ലാഗുകൾ = O_RDONLY | O_NOFOLLOW) പരാജയപ്പെട്ടു, നിരവധി ലെവലുകൾ
പ്രതീകാത്മക ലിങ്കുകൾ (ELOOP) കാരണം O_NOFOLLOW വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിലും പാതയുടെ പേര് ഒരു സൂചിപ്പിക്കുന്നു
പ്രതീകാത്മക ലിങ്ക്

(iv)
പാത്ത് നെയിം ടൈപ്പുചെയ്യുമ്പോൾ ഉപയോക്താക്കൾക്ക് തെറ്റുകൾ സംഭവിക്കുന്നത് സാധാരണമാണ്. ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി
ENOENT തിരികെ നൽകുമ്പോൾ നിർദ്ദേശങ്ങൾ നൽകാനുള്ള ശ്രമങ്ങൾ, ഉദാഹരണത്തിന്:
open(pathname = "/usr/include/filecontrl.h", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, അത്തരം ഫയലുകളൊന്നുമില്ല അല്ലെങ്കിൽ
ഡയറക്‌ടറി (2, ENOENT) കാരണം പാതനാമത്തിൽ "filecontrl.h" റെഗുലർ ഫയൽ ഇല്ല
"/ usr / ഉൾപ്പെടുത്തുക" ഡയറക്ടറി, പകരം "fcntl.h" റെഗുലർ ഫയലാണോ നിങ്ങൾ ഉദ്ദേശിച്ചത്?

(v) അവസാന ഘടകം ഒരു അല്ലാതെ മറ്റെന്തെങ്കിലും ആയിരിക്കണം
സാധാരണ ഫയൽ:
readlink(pathname = "just-a-file", data = 0x7F930A50, data_size = 4097) പരാജയപ്പെട്ടു,
അസാധുവായ ആർഗ്യുമെന്റ് (22, EINVAL) കാരണം പാത്ത് നെയിം ഒരു സാധാരണ ഫയലാണ്, പ്രതീകാത്മക ലിങ്കല്ല

(vi)
FIXME: "t" ബിറ്റ് കൈകാര്യം ചെയ്യൽ.

പരിധികൾ
പാത്ത് നെയിമുകളും ഫയലുകളുടെ പേരുകളും സംബന്ധിച്ച് നിരവധി പരിധികളുണ്ട്.

പാതയുടെ നീളം പരിധി
പാതനാമങ്ങൾക്ക് പരമാവധി നീളമുണ്ട്. പാതയുടെ പേര് (അല്ലെങ്കിൽ ചില ഇന്റർമീഡിയറ്റ്
പ്രതീകാത്മക ലിങ്കുകൾ പരിഹരിക്കുമ്പോൾ ലഭിച്ച പാതയുടെ പേര്) വളരെ ദൈർഘ്യമേറിയതാണ്, ഒരു ENAMETOOLONG
പിശക് തിരികെ ലഭിച്ചു ("ഫയലിന്റെ പേര് വളരെ ദൈർഘ്യമേറിയതാണ്"). സിസ്റ്റം പരിധി ഉൾപ്പെടുത്തിയിരിക്കുന്നത് എങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക
പിശക് സന്ദേശത്തിൽ.
ഓപ്പൺ (പാഥനാമം = "വളരെ നീണ്ട", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, ഫയലിന്റെ പേര് വളരെ വലുതാണ് (36,
ENAMETOOLONG) കാരണം പാതയുടെ പേര് സിസ്റ്റത്തിന്റെ പരമാവധി പാത ദൈർഘ്യം (4096) കവിയുന്നു

ഫയലിന്റെ ദൈർഘ്യ പരിധി
ചില Unix വേരിയന്റുകൾക്ക് ഓരോ പാത്ത് ഘടകത്തിലെയും ബൈറ്റുകളുടെ എണ്ണത്തിന് പരിധിയുണ്ട്.
അവരിൽ ചിലർ ഇത് നിശബ്ദമായി കൈകാര്യം ചെയ്യുന്നു, ചിലർ ENAMETOOLONG നൽകുന്നു; ലിബെക്സ്പ്ലെയ്ൻ
ലൈബ്രറി ഉപയോഗിക്കുന്നു pathconf(3) ഏതാണെന്ന് പറയാൻ _PC_NO_TRUNC. ഈ പിശക് സംഭവിക്കുകയാണെങ്കിൽ, ദി
libexplain ലൈബ്രറി പിശക് സന്ദേശത്തിലെ പരിധി പ്രസ്താവിക്കും, പരിധി ഇതാണ്
നിന്നും ലഭിച്ച pathconf(3) _PC_NAME_MAX. സിസ്റ്റം പരിധി ഉൾപ്പെടുത്തിയിരിക്കുന്നത് എങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക
പിശക് സന്ദേശത്തിൽ.
ഓപ്പൺ (പാഥനാമം = "system7/only-had-14-characters", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, ഫയൽ
പേര് വളരെ ദൈർഘ്യമേറിയതാണ് (36, ENAMETOOLONG) കാരണം "14-അക്ഷരങ്ങൾ മാത്രം" ഘടകമാണ്
സിസ്റ്റം പരിധിയേക്കാൾ നീളം (14)

ശൂന്യമായ പാതയുടെ പേര്
യഥാർത്ഥ യുണിക്സിൽ, ശൂന്യമായ പാത്ത് നെയിം നിലവിലെ ഡയറക്ടറിയെ പരാമർശിക്കുന്നു.
ശൂന്യമായ ഒരു പാത്ത്‌നെയിം വിജയകരമായി പരിഹരിക്കാൻ പാടില്ലെന്ന് ഇപ്പോൾ POSIX കൽപ്പിക്കുന്നു.
open(pathname = "", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, അത്തരം ഫയലോ ഡയറക്‌ടറിയോ ഇല്ല (2,
ENOENT) കാരണം ഒരു ശൂന്യമായ പാതയുടെ പേര് പരിഹരിക്കാൻ പാടില്ല എന്ന് POSIX കൽപ്പിക്കുന്നു
വിജയകരമായി

അനുമതികൾ
ഒരു ഫയലിന്റെ അനുമതി ബിറ്റുകൾ മൂന്ന് ബിറ്റുകളുടെ മൂന്ന് ഗ്രൂപ്പുകൾ ഉൾക്കൊള്ളുന്നു. ആദ്യ ഗ്രൂപ്പ്
കോളിംഗ് പ്രക്രിയയുടെ ഫലപ്രദമായ ഉപയോക്തൃ ഐഡി ഉടമയുടെ ഐഡിക്ക് തുല്യമാകുമ്പോൾ മൂന്ന് ഉപയോഗിക്കുന്നു
ഫയൽ. ഫയലിന്റെ ഗ്രൂപ്പ് ഐഡി ഒന്നുകിൽ തുല്യമാകുമ്പോൾ മൂന്നിന്റെ രണ്ടാമത്തെ ഗ്രൂപ്പ് ഉപയോഗിക്കുന്നു
കോളിംഗ് പ്രക്രിയയുടെ ഫലപ്രദമായ ഗ്രൂപ്പ് ഐഡി, അല്ലെങ്കിൽ സപ്ലിമെന്ററി ഗ്രൂപ്പ് ഐഡികളിൽ ഒന്നാണ്
കോളിംഗ് പ്രക്രിയ. രണ്ടും പിടിക്കാത്തപ്പോൾ, മൂന്നാമത്തെ ഗ്രൂപ്പ് ഉപയോഗിക്കുന്നു.
ഓപ്പൺ (പാഥനാമം = "/ etc / passwd", ഫ്ലാഗുകൾ = O_WRONLY) പരാജയപ്പെട്ടു, അനുമതി നിരസിച്ചു (13,
EACCES) കാരണം പ്രക്രിയയ്ക്ക് "passwd" റെഗുലറിന് എഴുതാനുള്ള അനുമതിയില്ല
"പാത്ത് നാമത്തിലുള്ള ഫയൽ/തുടങ്ങിയവ"ഡയറക്‌ടറി, UID 1000 "pmiller" എന്ന പ്രക്രിയ ഫലപ്രദമാണ്
സാധാരണ ഫയൽ ഉടമ 0 "റൂട്ട്" എന്നതുമായി പൊരുത്തപ്പെടുന്നില്ല അതിനാൽ ഉടമയുടെ അനുമതി മോഡ് "rw-"
അവഗണിക്കപ്പെട്ടു, മറ്റ് അനുമതി മോഡ് "r--" ആണ്, കൂടാതെ ഈ പ്രക്രിയയ്ക്ക് പ്രത്യേകാവകാശമില്ല
(DAC_OVERRIDE ശേഷിയില്ല)
ഭൂരിഭാഗം ഉപയോക്താക്കൾക്കും ഇത് അറിയാത്തതിനാൽ, ഈ വിശദീകരണത്തിന് ഗണ്യമായ ഇടം നൽകിയിട്ടുണ്ട്
പെർമിഷൻ സിസ്റ്റം എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്. പ്രത്യേകിച്ചും: ഉടമ, ഗ്രൂപ്പ്, മറ്റുള്ളവ
അനുമതികൾ എക്‌സ്‌ക്ലൂസീവ് ആണ്, അവ ഒരുമിച്ച് "OR" ചെയ്തിട്ടില്ല.

ശക്തം ഒപ്പം താൽപ്പര്യമുണ്ട് സിസ്റം കോളുകൾ

ഓരോ സിസ്റ്റം കോളിനും ഒരു പ്രത്യേക പിശക് ഹാൻഡ്‌ലർ എഴുതുന്ന പ്രക്രിയ പലപ്പോഴും വെളിപ്പെടുത്തുന്നു
രസകരമായ വിചിത്രങ്ങളും അതിർത്തി വ്യവസ്ഥകളും അല്ലെങ്കിൽ അവ്യക്തവും പിശക്(3) മൂല്യങ്ങൾ.

എനോമീഡിയം, ഇല്ല ഇടത്തരം കണ്ടെത്തി
ഒരു സിഡി പകർത്തിയ നടപടിയാണ് ഈ പേപ്പറിന്റെ തലക്കെട്ടിന്റെ ഉറവിടം.
$ dd if=/dev/cdrom ഓഫ്=ഫുബാർ.ഐസോ
dd: "/dev/cdrom" തുറക്കുന്നു: മീഡിയം ഒന്നും കണ്ടെത്തിയില്ല
$
എന്തിനാണ് തന്റെ കമ്പ്യൂട്ടർ തന്നോട് ഒരു മാനസികരോഗി എന്നൊന്നില്ലെന്ന് പറയുന്നതെന്ന് രചയിതാവ് ആശ്ചര്യപ്പെട്ടു
ഇടത്തരം. മാതൃഭാഷയായ ഇംഗ്ലീഷ് സംസാരിക്കുന്നവർ വലിയൊരു വിഭാഗം അല്ല എന്ന വസ്തുതയ്ക്ക് പുറമെ
"മാധ്യമം" എന്നത് ഒരു ബഹുവചനമാണെന്ന് അറിയാമെങ്കിലും, "മീഡിയം" എന്നത് അതിന്റെ ഏകവചനമായ സ്ട്രിംഗ് ആണെന്ന് പറയട്ടെ
വഴി തിരിച്ചു തീവ്രത(3) ENOMEDIUM-ന് ഏതാണ്ട് പൂർണ്ണമായും സ്വതന്ത്രമാകത്തക്കവിധം തീവ്രമാണ്
ഉള്ളടക്കം.

എപ്പോൾ തുറക്കുക(2) ENOMEDIUM നൽകുന്നു, libexplain ലൈബ്രറി വികസിപ്പിച്ചാൽ നന്നായിരിക്കും a
ഡ്രൈവ് തരം അനുസരിച്ച് ഇതിൽ കുറച്ച്. ഉദാഹരണത്തിന്:
... കാരണം ഫ്ലോപ്പി ഡ്രൈവിൽ ഡിസ്ക് ഇല്ല
... കാരണം സിഡി-റോം ഡ്രൈവിൽ ഡിസ്ക് ഇല്ല
... കാരണം ടേപ്പ് ഡ്രൈവിൽ ടേപ്പ് ഇല്ല
...കാരണം കാർഡ് റീഡറിൽ മെമ്മറി സ്റ്റിക്ക് ഇല്ല

അങ്ങനെ അത് സംഭവിച്ചു...
ഓപ്പൺ(പാഥനാമം = "/dev/cdrom", ഫ്ലാഗുകൾ = O_RDONLY) പരാജയപ്പെട്ടു, മീഡിയം ഒന്നും കണ്ടെത്തിയില്ല (123,
ENOMEDIUM) കാരണം CD-ROM ഡ്രൈവിൽ ഒരു ഡിസ്ക് ഉള്ളതായി തോന്നുന്നില്ല
രചയിതാവിന് മുമ്പ് അറിയാത്ത തന്ത്രം, ഉപകരണം ഉപയോഗിച്ച് ഉപകരണം തുറക്കുക എന്നതായിരുന്നു
O_NONBLOCK ഫ്ലാഗ്, അത് മീഡിയം ഇല്ലാതെ ഒരു ഡ്രൈവ് തുറക്കാൻ നിങ്ങളെ അനുവദിക്കും. അപ്പോൾ നിങ്ങൾ
പ്രശ്നം ഉപകരണം പ്രത്യേകം ioctls(2) അത് എന്താണെന്ന് കണ്ടെത്തുന്നതുവരെ അഭ്യർത്ഥിക്കുന്നു. (അല്ല
ഇത് POSIX ആണെങ്കിൽ ഉറപ്പാണ്, എന്നാൽ BSD, Solaris എന്നിവയിലും ഇത് ആ രീതിയിൽ പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു
The വോഡിം(1) ഉറവിടങ്ങൾ.)

സന്ദർഭത്തിൽ "ഡിസ്ക്", "ഡിസ്ക്" എന്നിവയുടെ വ്യത്യസ്ത ഉപയോഗങ്ങളും ശ്രദ്ധിക്കുക. സിഡി സ്റ്റാൻഡേർഡ് ഉത്ഭവിച്ചു
ഫ്രാൻസിൽ, എന്നാൽ മറ്റെല്ലാത്തിനും ഒരു "k" ഉണ്ട്.

EFAULT, ചീത്ത വിലാസം
പോയിന്റർ ആർഗ്യുമെന്റ് എടുക്കുന്ന ഏതൊരു സിസ്റ്റം കോളിനും EFAULT തിരികെ നൽകാനാകും. ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി
ഏത് വാദമാണ് തെറ്റ് എന്ന് കണ്ടുപിടിക്കാൻ കഴിയും, അത് പ്രക്രിയയെ തടസ്സപ്പെടുത്താതെ അത് ചെയ്യുന്നു
(അല്ലെങ്കിൽ ത്രെഡ്) സിഗ്നൽ കൈകാര്യം ചെയ്യൽ.

ലഭ്യമാകുമ്പോൾ, ദി മിനികോർ(2) മെമ്മറി റീജിയൻ സാധുതയുള്ളതാണോ എന്ന് ചോദിക്കാൻ സിസ്റ്റം കോൾ ഉപയോഗിക്കുന്നു.
ഇതിന് മൂന്ന് ഫലങ്ങൾ നൽകാനാകും: മാപ്പ് ചെയ്‌തെങ്കിലും ഫിസിക്കൽ മെമ്മറിയിലല്ല, മാപ്പ് ചെയ്‌തതും ഫിസിക്കൽ
മെമ്മറി, മാപ്പ് ചെയ്തിട്ടില്ല. ഒരു പോയിന്ററിന്റെ സാധുത പരിശോധിക്കുമ്പോൾ, ആദ്യത്തെ രണ്ടെണ്ണം "അതെ" ആണ്
അവസാനത്തേത് "ഇല്ല" ആണ്.

സി സ്ട്രിംഗുകൾ പരിശോധിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്, കാരണം ഒരു പോയിന്ററിനും വലുപ്പത്തിനും പകരം ഞങ്ങൾ മാത്രം
ഒരു പോയിന്റർ ഉണ്ട്. വലുപ്പം നിർണ്ണയിക്കാൻ ഞങ്ങൾ NUL കണ്ടെത്തേണ്ടതുണ്ട്, അതിന് കഴിയും
സെഗ്ഫോൾട്ട്, ക്യാച്ച്-22.

ഇത് പരിഹരിക്കുന്നതിന്, ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി ഉപയോഗിക്കുന്നു lstat(2) സിസെം കോൾ (അറിയപ്പെടുന്ന ഒരു കൂടെ
നല്ല രണ്ടാമത്തെ ആർഗ്യുമെന്റ്) സാധുതയ്ക്കായി സി സ്ട്രിംഗുകൾ പരിശോധിക്കാൻ. ഒരു പരാജയ റിട്ടേൺ && പിശക് == EFAULT
ഒരു "ഇല്ല", മറ്റെന്തെങ്കിലും "അതെ". ഇത് തീർച്ചയായും സ്‌ട്രിംഗുകളെ PATH_MAX ആയി പരിമിതപ്പെടുത്തുന്നു
പ്രതീകങ്ങൾ, പക്ഷേ ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറിക്ക് ഇത് സാധാരണയായി ഒരു പ്രശ്നമല്ല, കാരണം അതാണ്
മിക്കവാറും എല്ലായ്‌പ്പോഴും അത് ശ്രദ്ധിക്കുന്ന ഏറ്റവും നീളമേറിയ സ്ട്രിംഗുകൾ.

EMFILE, വളരെ വളരെ തുറക്കുക ഫയലുകൾ
ഒരു പ്രോസസ്സ് ഇതിനകം തന്നെ പരമാവധി ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ തുറന്നിരിക്കുമ്പോൾ ഈ പിശക് സംഭവിക്കുന്നു.
യഥാർത്ഥ പരിധി അച്ചടിക്കണമെങ്കിൽ, ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി ശ്രമിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് തുറക്കാൻ കഴിയില്ല
ഒരു ഫയൽ / proc അത് എന്താണെന്ന് വായിക്കാൻ.
open_max = sysconf(_SC_OPEN_MAX);
ഇത് അത്ര ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല, ഒരു ഉണ്ട് sysconf(3) പരിധി നേടുന്നതിനുള്ള വഴി.

ENFILE, വളരെ വളരെ തുറക്കുക ഫയലുകൾ in സിസ്റ്റം
ഓപ്പൺ ഫയലുകളുടെ ആകെ എണ്ണത്തിൽ സിസ്റ്റം പരിധി വരുമ്പോൾ ഈ പിശക് സംഭവിക്കുന്നു
എത്തി. ഈ സാഹചര്യത്തിൽ, ഉപയോഗപ്രദമല്ല sysconf(3) പരിധി നേടാനുള്ള വഴി.

ആഴത്തിൽ കുഴിക്കുമ്പോൾ, ലിനക്സിൽ ഒരു ഉണ്ടെന്ന് ഒരാൾക്ക് കണ്ടെത്താം / proc പ്രവേശനം ഞങ്ങൾക്ക് വായിക്കാം
ഈ മൂല്യം നേടുക. ക്യാച്ച്-22: ഞങ്ങൾക്ക് ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ തീർന്നു, അതിനാൽ ഞങ്ങൾക്ക് ഒരു ഫയൽ തുറക്കാൻ കഴിയില്ല
പരിധി വായിക്കുക.

Linux-ൽ അത് ലഭിക്കുന്നതിന് ഒരു സിസ്റ്റം കോൾ ഉണ്ട്, എന്നാൽ അതിന് [e]glibc റാപ്പർ ഫംഗ്‌ഷൻ ഇല്ല, അതിനാൽ
നിങ്ങൾ എല്ലാം വളരെ ശ്രദ്ധാപൂർവ്വം ചെയ്യണം:
നീളമുള്ള
explain_maxfile(അസാധു)
{
#ifdef __linux__
ഘടന __sysctl_args args;
int32_t maxfile;
size_t maxfile_size = വലുപ്പം(maxfile);
int name[] = { CTL_FS, FS_MAXFILE };
മെംസെറ്റ് (&args, 0, sizeof(struct __sysctl_args));
args.name = പേര്;
args.nlen = 2;
args.oldval = &maxfile;
args.oldlenp = &maxfile_size;
എങ്കിൽ (syscall(SYS__sysctl, &args) >= 0)
റിട്ടേൺ maxfile;
#അവസാനം
മടക്കം -1;
}
ലഭ്യമാകുമ്പോൾ പിശക് സന്ദേശത്തിൽ പരിധി ഉൾപ്പെടുത്താൻ ഇത് അനുവദിക്കുന്നു.

EINVAL “അസാധുവാണ് വാദം" vs ഇനോസിസ് "ഫംഗ്ഷൻ അല്ല നടപ്പിലാക്കി"
പിന്തുണയ്ക്കാത്ത പ്രവർത്തനങ്ങൾ (ഉദാ സിംലിങ്ക്(2) FAT ഫയൽ സിസ്റ്റത്തിൽ) റിപ്പോർട്ട് ചെയ്തിട്ടില്ല
ഒരു സിസ്റ്റം കോളിൽ നിന്ന് അടുത്തതിലേക്ക് സ്ഥിരമായി. EINVAL അല്ലെങ്കിൽ ഒന്നുകിൽ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്
ഇനോസിസ് മടങ്ങി.

തൽഫലമായി, ഈ പിശക് കേസുകൾ ശരിയാക്കാൻ ശ്രദ്ധ നൽകണം, പ്രത്യേകിച്ച്
EINVAL ഒന്നോ അതിലധികമോ സിസ്റ്റം കോൾ ആർഗ്യുമെന്റുകളിലെ പ്രശ്‌നങ്ങളെ സൂചിപ്പിക്കാം.

കുറിപ്പ് ആ പിശക്(3) is അല്ല എല്ലായിപ്പോഴും ഗണം
എങ്ങനെ, എങ്ങനെ എന്ന് നിർണ്ണയിക്കാൻ [e]glibc ഉറവിടങ്ങൾ വായിക്കേണ്ട സമയങ്ങളുണ്ട്
ചില സിസ്റ്റം കോളുകൾക്ക് പിശകുകൾ നൽകുമ്പോൾ.

feof(3), ഫയൽനോ(3)
ഈ ഫംഗ്‌ഷനുകൾക്ക് ഒരു പിശക് നൽകാൻ കഴിയില്ലെന്ന് പലപ്പോഴും അനുമാനിക്കപ്പെടുന്നു. എങ്കിൽ മാത്രമേ ഇത് ശരിയാകൂ
The സ്ട്രീം ആർഗ്യുമെന്റ് സാധുവാണ്, എന്നിരുന്നാലും ഒരു അസാധുവായത് കണ്ടുപിടിക്കാൻ അവർക്ക് കഴിയും
പോയിന്റർ.

fpathconf(3), pathconf(3)
റിട്ടേൺ മൂല്യം fpathconf(2) ഉം pathconf(2) നിയമപരമായി -1 ആയിരിക്കാം, അങ്ങനെയാണ്
ഉണ്ടോ എന്ന് നോക്കേണ്ടത് ആവശ്യമാണ് പിശക്(3) വ്യക്തമായി സജ്ജീകരിച്ചിരിക്കുന്നു.

ioctls(2)
റിട്ടേൺ മൂല്യം ioctls(2) നിയമപരമായി -1 ആയിരിക്കാം, അതിനാൽ അത് പരിശോധിക്കേണ്ടതുണ്ട്
പിശക്(3) വ്യക്തമായി സജ്ജീകരിച്ചിരിക്കുന്നു.

വായനക്കാരൻ(3)
റിട്ടേൺ മൂല്യം വായനക്കാരൻ(3) പിശകുകൾക്കും ഫയലിന്റെ അവസാനത്തിനും NULL ആണ്. അത്
ഉണ്ടോ എന്ന് നോക്കേണ്ടത് ആവശ്യമാണ് പിശക്(3) വ്യക്തമായി സജ്ജീകരിച്ചിരിക്കുന്നു.

setbuf(3), സെറ്റ്ബഫർ(3), setlinebuf(3), setvbuf(3)
ഈ ഫംഗ്‌ഷനുകളിൽ അവസാനത്തേത് ഒഴികെ എല്ലാം ശൂന്യമായി നൽകുന്നു. ഒപ്പം setvbuf(3) എന്ന് മാത്രമേ രേഖപ്പെടുത്തിയിട്ടുള്ളൂ
പിശകിൽ "പൂജ്യം അല്ലാത്തത്" തിരികെ നൽകുന്നു. ഉണ്ടോ എന്ന് നോക്കേണ്ടത് ആവശ്യമാണ് പിശക്(3) വ്യക്തമായി പറഞ്ഞിട്ടുണ്ട്
സജ്ജമാക്കുക.

strtod(3), സ്ട്രോൾ(3), strtold(3), സ്ട്രോൾ(3), സ്ട്രോൾ(3), സ്ട്രോൾ(3)
ഈ ഫംഗ്‌ഷനുകൾ പിശകിൽ 0 നൽകുന്നു, എന്നാൽ അതും ഒരു നിയമാനുസൃത റിട്ടേൺ മൂല്യമാണ്. അത്
ഉണ്ടോ എന്ന് നോക്കേണ്ടത് ആവശ്യമാണ് പിശക്(3) വ്യക്തമായി സജ്ജീകരിച്ചിരിക്കുന്നു.

ungetc(3)
ANSI C സ്റ്റാൻഡേർഡ് പ്രകാരം ബാക്കപ്പിന്റെ ഒരൊറ്റ പ്രതീകം മാത്രമേ നിർബന്ധമാക്കിയിട്ടുള്ളൂവെങ്കിലും, അത് മാറുന്നു
[e]glibc കൂടുതൽ അനുവദിക്കുന്നു... എന്നാൽ അതിനർത്ഥം ENOMEM-ൽ പരാജയപ്പെടാം എന്നാണ്. ഇതിന് കഴിയും
എങ്കിൽ EBADF-ലും പരാജയപ്പെടും fp വ്യാജമാണ്. നിങ്ങൾ EOF ഒരു പിശക് പാസാക്കിയാൽ ഏറ്റവും ബുദ്ധിമുട്ടാണ്
തിരിച്ചുവരവ് സംഭവിക്കുന്നു, പക്ഷേ തെറ്റ് സജ്ജീകരിച്ചിട്ടില്ല.

ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി ഈ പിശകുകളെല്ലാം ശരിയായി കണ്ടെത്തുന്നു, കേസുകളിൽ പോലും
പിശക് മൂല്യങ്ങൾ മോശമായി രേഖപ്പെടുത്തപ്പെട്ടിരിക്കുന്നു.

ENOSPC, ഇല്ല ഇടം ഇടത്തെ on ഉപകരണം
ഈ പിശക് ഒരു ഫയൽ സിസ്റ്റത്തിലെ ഒരു ഫയലിനെ പരാമർശിക്കുമ്പോൾ, libexplain ലൈബ്രറി മൗണ്ട് പ്രിന്റ് ചെയ്യുന്നു
പ്രശ്നം ഉള്ള ഫയൽ സിസ്റ്റത്തിന്റെ പോയിന്റ്. ഇത് പിശകിന്റെ ഉറവിടം വളരെയധികം ഉണ്ടാക്കും
വ്യക്തമാണ്.
എഴുതുക(ഫിൽഡുകൾ = 1 "ഉദാഹരണം", ഡാറ്റ = 0xbfff2340, data_size = 5) പരാജയപ്പെട്ടു, ഇടമില്ല
ഉപകരണത്തിൽ (28, ENOSPC) കാരണം ഫയൽ സിസ്റ്റത്തിൽ ഫയലുകൾ അടങ്ങിയിരിക്കുന്നു ("/ home") ഇല്ല
ഡാറ്റയ്ക്ക് കൂടുതൽ ഇടം
കൂടുതൽ പ്രത്യേക ഉപകരണ പിന്തുണ ചേർക്കുന്നതിനാൽ, പിശക് സന്ദേശങ്ങൾ ഉപകരണം ഉൾപ്പെടുത്തുമെന്ന് പ്രതീക്ഷിക്കുന്നു
ഉപകരണത്തിന്റെ പേരും യഥാർത്ഥ വലുപ്പവും.

EROFS, വായിക്കാൻ മാത്രം ഫയല് സിസ്റ്റം
ഈ പിശക് ഒരു ഫയൽ സിസ്റ്റത്തിലെ ഒരു ഫയലിനെ പരാമർശിക്കുമ്പോൾ, libexplain ലൈബ്രറി മൗണ്ട് പ്രിന്റ് ചെയ്യുന്നു
പ്രശ്നം ഉള്ള ഫയൽ സിസ്റ്റത്തിന്റെ പോയിന്റ്. ഇത് പിശകിന്റെ ഉറവിടം വളരെയധികം ഉണ്ടാക്കും
വ്യക്തമാണ്.

കൂടുതൽ പ്രത്യേക ഉപകരണ പിന്തുണ ചേർക്കുന്നതിനാൽ, പിശക് സന്ദേശങ്ങൾ ഉപകരണം ഉൾപ്പെടുത്തുമെന്ന് പ്രതീക്ഷിക്കുന്നു
പേരും തരവും.
ഓപ്പൺ (പാഥനാമം = "/dev/fd0", O_RDWR, 0666) പരാജയപ്പെട്ടു, റീഡ്-ഒൺലി ഫയൽ സിസ്റ്റം (30, EROFS)
കാരണം ഫ്ലോപ്പി ഡിസ്കിൽ റൈറ്റ് പ്രൊട്ടക്റ്റ് ടാബ് സെറ്റ് ഉണ്ട്

...കാരണം ഒരു CD-ROM എഴുതാൻ പറ്റില്ല
...കാരണം മെമ്മറി കാർഡിൽ റൈറ്റ് പ്രൊട്ടക്റ്റ് ടാബ് സെറ്റ് ഉണ്ട്
...കാരണം ½ ഇഞ്ച് മാഗ്നറ്റിക് ടേപ്പിന് ഒരു റൈറ്റ് റിംഗ് ഇല്ല

പേരുമാറ്റുക
ദി പേരുമാറ്റുക(2) ഒരു ഫയലിന്റെ സ്ഥാനമോ പേരോ മാറ്റാനും അത് നീക്കാനും സിസ്റ്റം കോൾ ഉപയോഗിക്കുന്നു
ആവശ്യമെങ്കിൽ ഡയറക്ടറികൾക്കിടയിൽ. ലക്ഷ്യസ്ഥാന പാതയുടെ പേര് ഇതിനകം നിലവിലുണ്ടെങ്കിൽ അത് അങ്ങനെയായിരിക്കും
ആറ്റോമിക് മാറ്റിസ്ഥാപിച്ചു, അതിനാൽ മറ്റൊരു പ്രക്രിയ ശ്രമിക്കുന്നതിന് ഒരു പോയിന്റും ഇല്ല
അത് ആക്‌സസ് ചെയ്യുക, അത് നഷ്‌ടമായി കാണപ്പെടും.

എന്നിരുന്നാലും പരിമിതികളുണ്ട്: നിങ്ങൾക്ക് മറ്റൊന്നിന്റെ മുകളിൽ മാത്രമേ ഒരു ഡയറക്ടറിയുടെ പേര് മാറ്റാൻ കഴിയൂ
ലക്ഷ്യസ്ഥാന ഡയറക്ടറി ശൂന്യമല്ലെങ്കിൽ ഡയറക്ടറി.
പേരുമാറ്റുക(oldpath = "foo", newpath = "bar") പരാജയപ്പെട്ടു, ഡയറക്ടറി ശൂന്യമല്ല (39,
ENOTEMPTY) കാരണം ന്യൂപാത്ത് ഒരു ശൂന്യമായ ഡയറക്ടറി അല്ല; അതായത്, അതിൽ എൻട്രികൾ അടങ്ങിയിരിക്കുന്നു
"" അല്ലാതെ ഒപ്പം ".."
നിങ്ങൾക്ക് നോൺ-ഡയറക്‌ടറിയുടെ മുകളിലുള്ള ഒരു ഡയറക്ടറിയുടെ പേര് മാറ്റാൻ കഴിയില്ല.
പേരുമാറ്റുക(oldpath = "foo", newpath = "bar") പരാജയപ്പെട്ടു, ഒരു ഡയറക്ടറി അല്ല (20, ENOTDIR)
കാരണം, oldpath ഒരു ഡയറക്ടറിയാണ്, എന്നാൽ newpath ഒരു സാധാരണ ഫയലാണ്, ഒരു ഡയറക്ടറി അല്ല
തിരിച്ചും അനുവദനീയമല്ല
പേരുമാറ്റുക(oldpath = "foo", newpath = "bar") പരാജയപ്പെട്ടു, ഒരു ഡയറക്‌ടറിയാണ് (21, EISDIR)
കാരണം newpath ഒരു ഡയറക്ടറിയാണ്, എന്നാൽ oldpath ഒരു സാധാരണ ഫയലാണ്, ഒരു ഡയറക്ടറി അല്ല

ഇത് തീർച്ചയായും ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറിയുടെ ജോലിയെ കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നു, കാരണം
അൺലിങ്ക് ചെയ്യുക(2) അല്ലെങ്കിൽ rm ആണ്(2) സിസ്റ്റം കോളിനെ പരോക്ഷമായി വിളിക്കുന്നു പേരുമാറ്റുക(2), അങ്ങനെ എല്ലാം
അൺലിങ്ക് ചെയ്യുക(2) അല്ലെങ്കിൽ rm ആണ്(2) പിശകുകൾ കണ്ടെത്തുകയും കൈകാര്യം ചെയ്യുകയും വേണം.

ഡ്യൂപ്പ്2
ദി ഡ്യൂപ്പ്2(2) റഫറൻസ് ചെയ്യുന്ന രണ്ടാമത്തെ ഫയൽ ഡിസ്ക്രിപ്റ്റർ സൃഷ്ടിക്കാൻ സിസ്റ്റം കോൾ ഉപയോഗിക്കുന്നു
ആദ്യത്തെ ഫയൽ ഡിസ്ക്രിപ്റ്ററിന്റെ അതേ ഒബ്ജക്റ്റ്. സാധാരണയായി ഇത് ഷെൽ ഇൻപുട്ട് നടപ്പിലാക്കാൻ ഉപയോഗിക്കുന്നു
കൂടാതെ ഔട്ട്പുട്ട് റീഡയറക്ഷൻ.

രസകരമായ കാര്യം, അതുപോലെ തന്നെ പേരുമാറ്റുക(2) ഒരു ഫയലിന് മുകളിൽ ആറ്റോമിക് ആയി പേരുമാറ്റാൻ കഴിയും
നിലവിലുള്ള ഫയൽ പഴയ ഫയൽ നീക്കം ചെയ്യുക, ഡ്യൂപ്പ്2(2) ഇതിനകം തുറന്ന ഒരു ഫയലിൽ ഇത് ചെയ്യാൻ കഴിയും
വിവരണക്കാരൻ.

ഒരിക്കൽ കൂടി, ഇത് ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറിയുടെ ജോലി കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നു, കാരണം അടയ്ക്കുക(2)
സിസ്റ്റം കോളിനെ പരോക്ഷമായി വിളിക്കുന്നു ഡ്യൂപ്പ്2(2), അങ്ങനെ എല്ലാം അടയ്ക്കുക(2) ന്റെ തെറ്റുകൾ ആയിരിക്കണം
കണ്ടെത്തി കൈകാര്യം, അതുപോലെ.

സാഹസങ്ങൾ IN IOCTL പിന്തുണ

ദി ioctls(2) സിസ്റ്റം കോൾ, ഡിവൈസ് ഡ്രൈവർ രചയിതാക്കൾക്ക് ആശയവിനിമയം നടത്താനുള്ള ഒരു മാർഗം നൽകുന്നു
നിലവിലുള്ള കേർണൽ API-യിൽ ചേരാത്ത ഉപയോക്തൃ-സ്പെയ്സ്. കാണുക ioctl_list(2).

ഡീകോഡിംഗ് അപേക്ഷ സംഖ്യാപുസ്തകം
ഒരു സൂക്ഷ്മമായ നോട്ടത്തിൽ നിന്ന് ioctls(2) ഇന്റർഫേസ്, വലുതും എന്നാൽ പരിമിതവും ഉള്ളതായി കാണപ്പെടും
സാധ്യമായ എണ്ണം ioctls(2) അഭ്യർത്ഥനകൾ. ഓരോന്നും വ്യത്യസ്തം ioctls(2) അഭ്യർത്ഥന ഫലപ്രദമാണ്
മറ്റൊരു സിസ്റ്റം കോൾ, എന്നാൽ ഒരു തരത്തിലുള്ള സുരക്ഷയും ഇല്ലാതെ - കംപൈലറിന് സഹായിക്കാൻ കഴിയില്ല a
പ്രോഗ്രാമർ ഇത് ശരിയാക്കുക. ഇതായിരിക്കാം പിന്നിലെ പ്രചോദനം tcflush(3) ഉം
സുഹൃത്തുക്കൾ.

നിങ്ങൾക്ക് ഡീകോഡ് ചെയ്യാൻ കഴിയുമെന്നാണ് പ്രാഥമിക ധാരണ ioctls(2) ഒരു വലിയ സ്വിച്ച് ഉപയോഗിച്ചുള്ള അഭ്യർത്ഥനകൾ
പ്രസ്താവന. ഇത് അപ്രായോഗികമായി മാറുന്നു, കാരണം ഒരാൾ അത് വളരെ വേഗത്തിൽ കണ്ടെത്തുന്നു
വ്യത്യസ്തമായവ നിർവചിക്കുന്ന ആവശ്യമായ എല്ലാ സിസ്റ്റം ഹെഡറുകളും ഉൾപ്പെടുത്തുന്നത് അസാധ്യമാണ് ioctls(2)
അഭ്യർത്ഥിക്കുന്നു, കാരണം അവർക്ക് പരസ്പരം നന്നായി കളിക്കാൻ ബുദ്ധിമുട്ടാണ്.

"സ്വകാര്യ" അഭ്യർത്ഥന നമ്പറുകളുടെയും ഉപകരണത്തിന്റെയും ഒരു ശ്രേണി ഉണ്ടെന്ന് ആഴത്തിലുള്ള നോട്ടം വെളിപ്പെടുത്തുന്നു
അവ ഉപയോഗിക്കാൻ ഡ്രൈവർ രചയിതാക്കളെ പ്രോത്സാഹിപ്പിക്കുന്നു. ഇതിനർത്ഥം ഇതിലും വലിയൊരു സാധ്യതയുണ്ടെന്നാണ്
അവ്യക്തമായ അഭ്യർത്ഥന നമ്പറുകളുള്ള ഒരു കൂട്ടം അഭ്യർത്ഥനകൾ, ഉടനടി ദൃശ്യമാകുന്നതിനേക്കാൾ. കൂടാതെ,
ചരിത്രപരമായ ചില അവ്യക്തതകളും ഉണ്ട്.

സ്വിച്ച് അപ്രായോഗികമാണെന്ന് ഞങ്ങൾക്കറിയാമായിരുന്നു, എന്നാൽ ഇപ്പോൾ അത് തിരഞ്ഞെടുക്കണമെന്ന് ഞങ്ങൾക്കറിയാം
ഉചിതമായ അഭ്യർത്ഥന നാമവും വിശദീകരണവും ഞങ്ങൾ അഭ്യർത്ഥന നമ്പർ മാത്രമല്ല പരിഗണിക്കണം
ഫയൽ വിവരണവും.

നടപ്പിലാക്കുന്നത് ioctls(2) ലിബെക്‌സ്‌പ്ലെയ്‌ൻ ലൈബ്രറിക്കുള്ളിലെ പിന്തുണയുടെ ഒരു പട്ടിക ഉണ്ടായിരിക്കണം
ചൂണ്ടിക്കാണിക്കുന്നു ioctls(2) അഭ്യർത്ഥന വിവരണങ്ങൾ. ഈ വിവരണങ്ങളിൽ ഓരോന്നിനും ഒരു ഓപ്ഷണൽ ഉൾപ്പെടുന്നു
ഒരു വ്യവഹാര പ്രവർത്തനത്തിലേക്കുള്ള പോയിന്റർ.

ഓരോ അഭ്യർത്ഥനയും യഥാർത്ഥത്തിൽ ഒരു പ്രത്യേക സോഴ്സ് ഫയലിൽ നടപ്പിലാക്കുന്നു, അതിനാൽ അത് ആവശ്യമാണ്
ഉൾപ്പെടുന്ന ഫയലുകൾ മറ്റുള്ളവരുമായി നന്നായി കളിക്കാനുള്ള ബാധ്യതയിൽ നിന്ന് ഒഴിവാക്കപ്പെടുന്നു.

പ്രതിനിധിത്തം
ലിബെക്‌സ്‌പ്ലെയ്‌ൻ ലൈബ്രറിയുടെ പിന്നിലെ തത്വശാസ്ത്രം അത്രയും വിവരങ്ങൾ നൽകുക എന്നതാണ്
സിസ്റ്റം കോളിന്റെ കൃത്യമായ പ്രാതിനിധ്യം ഉൾപ്പെടെ സാധ്യമാണ്. ഈ സന്ദർഭത്തിൽ
ioctls(2) ഇതിനർത്ഥം ശരിയായ അഭ്യർത്ഥന നമ്പർ (പേര് പ്രകാരം) കൂടാതെ ശരിയായ (അല്ലെങ്കിൽ
കുറഞ്ഞത് ഉപയോഗപ്രദമായ) മൂന്നാമത്തെ വാദത്തിന്റെ പ്രതിനിധാനം.

ദി ioctls(2) പ്രോട്ടോടൈപ്പ് ഇതുപോലെ കാണപ്പെടുന്നു:
int ioctl (int fildes, int request, ...);
നിങ്ങളുടെ ടൈപ്പ്-സുരക്ഷാ അലാറങ്ങൾ ഓഫാക്കിയിരിക്കണം. ആന്തരികമായി [e]glibc, ഇത് തിരിഞ്ഞു
വിവിധ രൂപങ്ങളിൽ:
int __ioctl (int fildes, int request, long arg);
int __ioctl (int fildes, int request, void * arg);
ഒപ്പം Linux കേർണൽ syscal interface പ്രതീക്ഷിക്കുന്നു
asmlinkage long sys_ioctl(അൺ സൈൻ ചെയ്യാത്ത int fildes, unsigned int request, unsigned long
ആർഗ്);
മൂന്നാം ആർഗ്യുമെന്റിന്റെ അങ്ങേയറ്റത്തെ വ്യതിയാനം ഒരു വെല്ലുവിളിയാണ്, ലിബെക്സ്പ്ലെയ്ൻ ലൈബ്രറി
ആ മൂന്നാമത്തെ ആർഗ്യുമെന്റിന്റെ പ്രതിനിധാനം അച്ചടിക്കാൻ ശ്രമിക്കുന്നു. എന്നിരുന്നാലും, ഒരിക്കൽ അഭ്യർത്ഥന നമ്പർ
അവ്യക്തമാക്കിയിരിക്കുന്നു, libexplain ലൈബ്രറിയുടെ ioctl പട്ടികയിലെ ഓരോ എൻട്രിയിലും ഒരു
ഇഷ്‌ടാനുസൃത പ്രിന്റ്_ഡാറ്റ ഫംഗ്‌ഷൻ (OO സ്വമേധയാ ചെയ്തു).

വിശദീകരണം
ഉപയോഗിക്കേണ്ട വിശദീകരണം നിർണ്ണയിക്കുന്നതിൽ കുറച്ച് പ്രശ്നങ്ങൾ ഉണ്ട്. അഭ്യർത്ഥന നമ്പർ ഒരിക്കൽ
അവ്യക്തമാക്കിയിരിക്കുന്നു, libexplain ലൈബ്രറിയുടെ ioctl പട്ടികയിലെ ഓരോ എൻട്രിക്കും ഒരു ഇഷ്‌ടാനുസൃതമുണ്ട്
print_explanation function (വീണ്ടും, OO സ്വമേധയാ ചെയ്തു).

സെക്ഷൻ 2, സെക്ഷൻ 3 സിസ്റ്റം കോളുകളിൽ നിന്ന് വ്യത്യസ്തമായി, മിക്കതും ioctls(2) അഭ്യർത്ഥനകൾക്ക് പിശകുകളൊന്നുമില്ല
രേഖപ്പെടുത്തി. ഇതിനർത്ഥം, നല്ല പിശക് വിവരണങ്ങൾ നൽകാൻ, കേർണൽ വായിക്കേണ്ടത് ആവശ്യമാണ്
കണ്ടെത്താനുള്ള ഉറവിടങ്ങൾ

· എന്ത് പിശക്(3) മൂല്യങ്ങൾ തിരികെ നൽകാം, കൂടാതെ

· ഓരോ തെറ്റിന്റെയും കാരണം.

കേർണലിനൊപ്പം ഫംഗ്‌ഷൻ കോൾ ഡിസ്‌പാച്ചിംഗിന്റെ OO സ്വഭാവം കാരണം, നിങ്ങൾ വായിക്കേണ്ടതുണ്ട്
എല്ലാം അത് നടപ്പിലാക്കുന്ന ഉറവിടങ്ങൾ ioctls(2) അഭ്യർത്ഥന, പൊതുവായ നടപ്പാക്കൽ മാത്രമല്ല. അത്
വ്യത്യസ്‌ത കേർണലുകൾക്ക് വ്യത്യസ്‌ത പിശക് നമ്പറുകളും സൂക്ഷ്മമായും ഉണ്ടായിരിക്കുമെന്ന് പ്രതീക്ഷിക്കാം
വ്യത്യസ്ത പിശക് കാരണങ്ങൾ.

EINVAL vs ENOTTY
സ്ഥിതി കൂടുതൽ മോശമാണ് ioctls(2) സിസ്റ്റം കോളുകൾക്കായുള്ള അഭ്യർത്ഥനകൾ, EINVAL കൂടാതെ
ഒരു എന്ന് സൂചിപ്പിക്കാൻ ENOTTY രണ്ടും ഉപയോഗിക്കുന്നു ioctls(2) അഭ്യർത്ഥന അതിൽ അനുചിതമാണ്
സന്ദർഭം, ഇടയ്ക്കിടെ ENOSYS, ENOTSUP, EOPNOTSUPP (സോക്കറ്റുകൾക്ക് ഉപയോഗിക്കാൻ ഉദ്ദേശിച്ചത്)
നന്നായി. ലിനക്സ് കേർണൽ സ്രോതസ്സുകളിൽ ഒരു പുരോഗമനാത്മകത സൂചിപ്പിക്കുന്നതായി തോന്നുന്ന അഭിപ്രായങ്ങളുണ്ട്
ശുചീകരണം പുരോഗമിക്കുന്നു. കൂടുതൽ കുഴപ്പങ്ങൾക്ക്, BSD ആശയക്കുഴപ്പത്തിലേക്ക് ENOIOCTL ചേർക്കുന്നു.

തൽഫലമായി, ഈ പിശക് കേസുകൾ ശരിയാക്കാൻ ശ്രദ്ധ നൽകണം, പ്രത്യേകിച്ച്
EINVAL ഒന്നോ അതിലധികമോ സിസ്റ്റം കോൾ ആർഗ്യുമെന്റുകളിലെ പ്രശ്‌നങ്ങളെ സൂചിപ്പിക്കാം.

intptr_t
C99 സ്റ്റാൻഡേർഡ് ഒരു പൂർണ്ണസംഖ്യ തരം നിർവചിക്കുന്നു, അത് ഏത് പോയിന്ററും കൈവശം വയ്ക്കാൻ കഴിയുമെന്ന് ഉറപ്പുനൽകുന്നു
പ്രാതിനിധ്യം നഷ്ടപ്പെടാതെ.

മുകളിലുള്ള ഫംഗ്‌ഷൻ syscall പ്രോട്ടോടൈപ്പ് എഴുതുന്നതാണ് നല്ലത്
നീളമുള്ള sys_ioctl (അൺ സൈൻ ചെയ്യാത്ത int fildes, unsigned int request, intptr_t arg);
ഉപകരണ-നിർദ്ദിഷ്ട അല്ലെങ്കിൽ ഫയൽ-സിസ്റ്റം-നിർദ്ദിഷ്ടമായ കോഗ്നിറ്റീവ് ഡിസോണൻസാണ് പ്രശ്നം
ioctls(2) നടപ്പിലാക്കലുകൾ, ഇനിപ്പറയുന്നവ:
നീളമുള്ള vfs_ioctl (struct file *filp, unsigned int cmd, unsigned long arg);
ഭൂരിഭാഗവും ioctls(2) അഭ്യർത്ഥനകൾക്ക് യഥാർത്ഥത്തിൽ ഒരു int *arg മൂന്നാം ആർഗ്യുമെന്റ് ഉണ്ട്. എന്നാൽ അത് ഉള്ളത്
ലോംഗ് ലീഡുകൾ പ്രഖ്യാപിച്ചു, ഇതിനെ ലോംഗ് *ആർഗ് ആയി കണക്കാക്കുന്നു. ഇത് 32-ബിറ്റുകളിൽ നിരുപദ്രവകരമാണ്
(sizeof(long) == sizeof(int)) എന്നാൽ 64‐bits (sizeof(long) != sizeof(int)).
എൻഡിയൻ-നെസ് അനുസരിച്ച്, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന മൂല്യം നിങ്ങൾ ചെയ്യുന്നു അല്ലെങ്കിൽ ലഭിക്കുന്നില്ല, പക്ഷേ നിങ്ങൾ എല്ലായിപ്പോഴും നേടുക
ഒരു മെമ്മറി സ്‌ക്രൈബിൾ അല്ലെങ്കിൽ സ്റ്റാക്ക് സ്‌ക്രൈബിളും.

ഇവയെല്ലാം ഇങ്ങനെ എഴുതുന്നു
int ioctl (int fildes, int request, ...);
int __ioctl (int fildes, int request, intptr_t arg);
നീളമുള്ള sys_ioctl (അൺ സൈൻ ചെയ്യാത്ത int fildes, unsigned int request, intptr_t arg);
നീളമുള്ള vfs_ioctl (സ്ട്രക്റ്റ് ഫയൽ * filp, ഒപ്പിടാത്ത int cmd, intptr_t arg);
ഏതാണ്ട് ഒരു സംഖ്യയെ പ്രതിനിധീകരിക്കാൻ പൂർണ്ണസംഖ്യ ഒരു പൂർണ്ണസംഖ്യ മാത്രമാണെന്ന് ഊന്നിപ്പറയുന്നു
എല്ലായ്പ്പോഴും ഒരു ബന്ധമില്ലാത്ത പോയിന്റർ തരം.

ഉപസംഹാരം

libexplain ഉപയോഗിക്കുക, നിങ്ങളുടെ ഉപയോക്താക്കൾ ഇത് ഇഷ്ടപ്പെടും.

പകർപ്പവകാശ

libexplain പതിപ്പ് 1.4
പകർപ്പവകാശം (സി) 2008, 2009, 2010, 2011, 2012, 2013, 2014 പീറ്റർ മില്ലർ

onworks.net സേവനങ്ങൾ ഉപയോഗിച്ച് വിശദീകരിക്കാൻ_lca2010 ഓൺലൈനായി ഉപയോഗിക്കുക