The GNU C Library version 2.24 is now available
From: | Adhemerval Zanella <adhemerval.zanella-AT-linaro.org> | |
To: | GNU C Library <libc-alpha-AT-sourceware.org>, libc-announce-AT-sourceware.org, info-gnu-AT-gnu.org | |
Subject: | The GNU C Library version 2.24 is now available | |
Date: | Thu, 4 Aug 2016 15:10:29 -0300 | |
Message-ID: | <72190fd8-28d0-816c-a8d5-de981f7f5631@linaro.org> |
The GNU C Library ================= The GNU C Library version 2.24 is now available. The GNU C Library is used as *the* C library in the GNU system and in GNU/Linux systems, as well as many other systems that use Linux as the kernel. The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known. The GNU C Library webpage is at http://www.gnu.org/software/libc/ Packages for the 2.24 release may be downloaded from: http://ftpmirror.gnu.org/libc/ http://ftp.gnu.org/gnu/libc/ The mirror list is at http://www.gnu.org/order/ftp.html NEWS for version 2.24 ===================== * The minimum Linux kernel version that this version of the GNU C Library can be used with is 3.2, except on i[4567]86 and x86_64, where Linux kernel version 2.6.32 or later suffices (on architectures that already required kernel versions more recent than 3.2, those requirements remain unchanged). Linux 3.2 or later kernel headers are required on all architectures. * The pap_AN locale has been deleted. This has been deprecated for a long time. It has been replaced by pap_AW & pap_CW, both of which have long been included in previous releases. * The readdir_r and readdir64_r functions have been deprecated. It is recommended to use readdir and readdir64 instead. * The type “union wait” has been removed. It was deprecated in the early 1990s and never part of POSIX. Application code should use the int type instead of “union wait”. * A new NSS action is added to facilitate large distributed system administration. The action, MERGE, allows remote user stores like LDAP to be merged into local user stores like /etc/groups in order to provide easy to use, updated, and managed sets of merged credentials. The new action can be used by configuring it in /etc/nsswitch.conf: group: files [SUCCESS=merge] nis Implemented by Stephen Gallagher (Red Hat). * The deprecated __malloc_initialize_hook variable has been removed from the API. * The long unused localedef --old-style option has been removed. It hasn't done anything in over 16 years. Scripts using this option can safely drop it. * nextupl, nextup, nextupf, nextdownl, nextdown and nextdownf are added to libm. They are defined by TS 18661 and IEEE754-2008. The nextup functions return the next representable value in the direction of positive infinity and the nextdown functions return the next representable value in the direction of negative infinity. These are currently enabled as GNU extensions. Security related changes: * An unnecessary stack copy in _nss_dns_getnetbyname_r was removed. It could result in a stack overflow when getnetbyname was called with an overly long name. (CVE-2016-3075) * Previously, getaddrinfo copied large amounts of address data to the stack, even after the fix for CVE-2013-4458 has been applied, potentially resulting in a stack overflow. getaddrinfo now uses a heap allocation instead. Reported by Michael Petlan. (CVE-2016-3706) * The glob function suffered from a stack-based buffer overflow when it was called with the GLOB_ALTDIRFUNC flag and encountered a long file name. Reported by Alexander Cherepanov. (CVE-2016-1234) * The Sun RPC UDP client could exhaust all available stack space when flooded with crafted ICMP and UDP messages. Reported by Aldy Hernandez' alloca plugin for GCC. (CVE-2016-4429) * The IPv6 name server management code in libresolv could result in a memory leak for each thread which is created, performs a failing naming lookup, and exits. Over time, this could result in a denial of service due to memory exhaustion. Reported by Matthias Schiffer. (CVE-2016-5417) The following bugs are resolved with this release: [1170] localedata: ne_NP: update Nepali locale definition file [3629] manual: stpcpy description in string.texi refers to MS-DOG instead of MS-DOS. [6527] malloc: [powerpc] Malloc alignment insufficient for PowerPC [6796] math: fdim() does not set errno on overflow [10354] libc: posix_spawn should use vfork() in more cases than presently [11213] localedata: localedata: add copyright disclaimer to locale files [12143] localedata: chr_US: new Cherokee locale [12450] localedata: sgs_LT: new locale [12676] localedata: ln_CD: new locale [13237] localedata: LC_ADDRESS.country_name: update all locales w/latest CLDR data [13304] math: fma, fmaf, fmal produce wrong results [14259] build: --localedir arg to configure is ignored [14499] nptl: Does posix_spawn invoke atfork handlers / use vfork? [14750] libc: Race condition in posix_spawn vfork usage vs signal handlers [14934] localedata: es_CL: wrong first weekday chilean locale [15262] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of romanisation [15263] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of 1/0 and +/- [15264] localedata: LC_MESSAGES.yesstr/nostr: lacking in many locales [15368] nptl: raise() is not async-signal-safe [15479] math: ceil, floor, round and trunc raise inexact exception [15578] localedata: kk_KZ: various updates [16003] localedata: pap_AN: punt old locale [16137] localedata: iw_IL: punt old locale [16190] localedata: eo: new esperanto locale [16374] localedata: lv_LV: change currency symbol in LC_MONETARY to euro [16742] malloc: race condition: pthread_atfork() called before first malloc() results in unexpected locking behaviour/deadlocks [16975] localedata: LC_MESSAGES.yesexpr/noexpr: revisit capitalization in all locales [16983] localedata: postal_fmt does not allow %l and %n modifiers [17565] localedata: pt_PT: wrong (work-)week start [17899] math: [powerpc] floorl returns negative zero with FE_DOWNWARD [17950] build: Build fails with -msse [18205] localedata: be_BY*: wrong first_weekday and first_workday [18433] libc: posix_spawn does not return correctly upon failure to execute [18453] localedata: charmaps/IBM875: incorrect codes [18712] string: bits/string2.h incompatible with -O2 -Werror=packed -Wsystem-headers [18896] localedata: he_IL: improvements for currency [18911] localedata: ro_RO: Correcting week day name for "Tuesday" in Romanian locale data [18960] locale: s390: _nl_locale_subfreeres uses larl opcode on misaligned symbol [19056] libc: Deprecate readdir_r [19133] localedata: pt_*: days & months should be lowercase in Portuguese language [19198] localedata: nl_NL: small improvements for Dutch locales [19257] network: Per-thread memory leak in __res_vinit with IPv6 nameservers (CVE-2016-5417) [19269] build: tst-audit4 and tst-audit10 failures with gcc-6 on non avx machine [19400] locale: Language missing in "iso-639.def", trivial fix in description [19431] malloc: Deadlock between fflush, getdelim, and fork [19505] libc: Incorrect file descriptor validity checks in posix_spawn_file_actions_add{open,close,dup2} [19509] dynamic-link: dlsym, dlvsym do not report errors through dlerror when using RTLD_NEXT [19512] locale: Stale `#ifndef HAVE_BUILTIN_EXPECT' in `intl/{gettextP,loadinfo}.h' [19534] libc: execle, execlp may use malloc [19568] localedata: *_CH: Swiss locales have inconsistent start of week [19573] network: res_nclose and __res_maybe_init disagree about name server initialization, breaking Hesiod [19575] localedata: Status of GB18030 tables [19581] localedata: sr_* date_fmt string contains additional newline [19583] string: SSSE3_Fast_Copy_Backward flag needs to be enabled for AMD Excavator core [19592] math: [ldbl-128ibm] ceill incorrect in non-default rounding modes [19593] math: [ldbl-128ibm] truncl incorrect in non-default rounding modes [19594] math: [ldbl-128ibm] roundl incorrect in non-default rounding modes [19595] math: [ldbl-128ibm] fmodl incorrect for results in subnormal double range [19602] math: [ldbl-128ibm] fmodl handling of equal arguments with low part zero incorrect [19603] math: [ldbl-128ibm] remainderl, remquol incorrect sign handling in equality tests [19610] dynamic-link: ldconfig -X removes stale symbolic links [19613] libc: s390x (64 bit) macro expansion WCOREDUMP and others [19633] locale: strfmon_l applies global locale to number formatting [19642] network: Memory leak in getnameinfo [19648] libc: test-skeleton.c: Do not set RLIMIT_DATA [19653] libc: Potential for NULL pointer dereference (CWE-476) in glibc-2.22 [19654] math: [x86_64] Need testcase for BZ #19590 fix [19671] localedata: Missing Sanity Check for malloc() in 'tst-fmon.c' & 'tst-numeric.c' [19674] math: [ldbl-128ibm] powl incorrect overflow handling [19677] math: [ldbl-128ibm] remainderl equality test incorrect for zero low part [19678] math: [ldbl-128ibm] nextafterl, nexttowardl incorrect sign of zero result [19679] dynamic-link: gcc-4.9.3 C++ exception handling broken due to unaligned stack [19726] locale: Converting UCS4LE to INTERNAL with iconv() does not update pointers and lengths in error-case. [19727] locale: Converting from/to UTF-xx with iconv() does not always report errors on UTF-16 surrogates values. [19755] nscd: nscd assertion failure in gc [19758] dynamic-link: Typo in EXTRA_LD_ENVVARS for x86-64 [19759] libc: mempcpy shouldn't be inlined [19762] dynamic-link: HAS_CPU_FEATURE/HAS_ARCH_FEATURE are easy to misuse [19765] libc: s390 needs an optimized mempcpy [19779] glob: glob: buffer overflow with GLOB_ALTDIRFUNC due to incorrect NAME_MAX limit assumption (CVE-2016-1234) [19783] build: benchtests don't support --enable-hardcoded-path-in-tests [19787] network: Missing and incorrect truncation checks in getnameinfo [19790] math: [ldbl-128ibm] nearbyintl incorrect in non-default rounding modes [19791] network: Assertion failure in res_query.c with un-connectable name server addresses [19792] libc: MIPS: backtrace yields infinite backtrace with makecontext [19822] math: libm.so install clobbers old version [19825] network: resolv: send_vc can return uninitialized data in second response to getaddrinfo [19830] network: nss_dns: should check RDATA length against buffer length [19831] network: nss_dns: getaddrinfo returns uninitialized data when confronted with A/AAAA records of invalid size [19837] nss: nss_db: No retries for some long lines with a larger buffer [19848] math: powl(10,n) for n=-4,-5,-6,-7 is off by more than 1 ULP [19853] stdio: Printing IBM long double in decimal with high precision is sometimes incorrect [19860] build: x86_64: compile errors for tst-audit10 and tst-auditmod10b [19861] nptl: libpthread IFUNC resolver for fork can lead to crash [19862] network: resolv, nss_dns: Remove remaining logging of unexpected record types [19865] network: Assertion failure or memory leak in _nss_dns_getcanonname_r [19868] network: nss_dns: netent code does not skip over non-PTR records [19879] network: nss_dns: Stack overflow in getnetbyname implementation (CVE-2016-3075) [19881] string: Improve x86-64 memset [19907] string: Incorrect memcpy tests [19916] dynamic-link: S390: fprs/vrs are not saved/restored while resolving symbols [19925] libc: termios.h XCASE namespace [19928] string: memmove-vec-unaligned-erms.S is slow with large data size [19929] libc: limits.h NL_NMAX namespace [19931] stdio: Memory leak in vfprintf [19957] libc: clone(CLONE_VM) access invalid parent memory [19963] localedata: en_IL: New locale [19989] stdio: stdio.h cuserid namespace [19994] network: getaddrinfo does not restore RES_USE_INET6 flag in gethosts [19996] locale: langinfo.h nl_langinfo_l namespace [20005] stdio: fflush on a file opened with fmemopen resets position to 0 [20010] network: getaddrinfo: Stack overflow in hostent translation (CVE-2016-3706) [20012] stdio: libio: fmemopen append mode failure [20014] stdio: stdio.h namespace for pre-threads POSIX [20017] network: resolv: Use gmtime_r instead of gmtime in p_secstodate [20023] libc: fcntl.h timespec namespace [20024] math: [x86_64] vectorized sincos trashes the stack [20031] network: nss_hesiod: Heap overflow in get_txt_records [20041] time: sys/time.h timespec namespace [20043] libc: unistd.h missing cuserid for UNIX98 and before [20044] libc: unistd.h missing pthread_atfork for UNIX98 [20051] libc: ttyslot in wrong header under wrong conditions [20054] libc: gethostname not declared for XPG4 [20055] libc: termios.h missing tcgetsid for XPG4 [20072] dynamic-link: x86 init_cpu_features is called twice in static executable [20073] libc: sys/stat.h fchmod namespace [20074] libc: stdlib.h rand_r namespace [20076] libc: sys/stat.h missing S_IFSOCK, S_ISSOCK for XPG4 [20094] libc: stdlib.h should not declare grantpt, ptsname, unlockpt for XPG3 [20111] libc: struct sockaddr_storage cannot be aggregate-copied [20112] network: sunrpc: stack (frame) overflow in Sun RPC clntudp_call (CVE-2016-4429) [20115] string: Extra alignment in memset-vec-unaligned-erms.S [20119] libc: Wrong mask for processors level type from CPUID [20139] dynamic-link: Upper part of zmm is zeroed if Glibc is built with AS not supporting AVX512 [20151] math: [ldbl-128/ldbl-128ibm] j0l, j1l, y0l, y1l return sNaN for sNaN argument [20153] math: [ldbl-128ibm] sqrtl (sNaN) returns sNaN [20156] math: [ldbl-128ibm] ceill, rintl etc. return sNaN for sNaN argument [20157] math: [powerpc] fabsl (sNaN) wrongly raises "invalid" [20160] math: [powerpc] ceil, rint etc. return sNaN for sNaN input [20178] libc: posix_spawn{p} should not call exit [20191] stdio: libio: vtables hardening [20195] string: FMA4 detection requires CPUID execution with register eax=0x80000001 [20198] libc: quick_exit incorrectly destroys C++11 thread objects. [20205] math: [i386/x86_64] nextafterl incorrect incrementing negative subnormals [20212] math: acos (sNaN) returns sNaN [20213] math: asin (sNaN) returns sNaN [20214] network: Linux header sync with linux/in6.h and ipv6.h again. [20218] math: [i386] asinhl (sNaN) returns sNaN [20219] math: [i386] atanhl (sNaN) returns sNaN [20222] stdio: fopencookie: Mangle function pointers [20224] math: [i386] cbrtl (sNaN) returns sNaN [20225] math: ldexp, scalbn, scalbln return sNaN for sNaN input [20226] math: [i386/x86_64] expl, exp10l, expm1l return sNaN for sNaN input [20227] math: [i386/x86_64] logl (sNaN) returns sNaN [20228] math: [i386/x86_64] log10l (sNaN) returns sNaN [20229] math: [i386/x86_64] log1pl (sNaN) returns sNaN [20232] math: [ldbl-128] expm1l (sNaN) returns sNaN [20233] math: [ldbl-128ibm] expm1l (sNaN) returns sNaN [20234] math: [ldbl-128ibm] log1pl (sNaN) returns sNaN [20235] math: [i386/x86_64] log2l (sNaN) returns sNaN [20237] nss: nss_db: get*ent segfaults without preceding set*ent [20240] math: modf (sNaN) returns sNaN [20248] libc: debug/tst-longjump_chk2 calls printf from a signal handler [20250] math: frexp (sNaN) returns sNaN [20252] math: atan2 (sNaN, qNaN) fails to raise "invalid" [20255] math: [i386] fdim, fdimf return with excess range and precision / double rounding [20256] math: [i386/x86_64] fdiml returns sNaN for sNaN input [20260] string: ../sysdeps/x86/bits/string.h:1092:3: error: array subscript is below array bounds [-Werror=array-bounds] [20262] nis: _nss_nis_initgroups_dyn always returns NSS_STATUS_NOTFOUND [20263] nptl: robust mutex deadlocks if other thread requests timedlock (Only arm/linux) [20277] libc: $dp is not initialized correctly in sysdeps/hppa/start.S [20284] malloc: malloc: Corrupt arena avoidance causes unnecessary mmap fallbacks [20296] math: [i386/x86_64] scalbl returns sNaN for sNaN input, missing "invalid" exceptions [20314] nptl: make[4]: *** [/usr/include/stdlib.h] Error 1 [20316] localedata: id_ID: Februari instead of Pebruari [20327] string: POWER8 strcasecmp returns incorrect result [20347] math: Failure: Test: j0_downward (0xap+0) [20348] libc: FAIL: misc/tst-preadvwritev64 [20349] libc: 64-bit value is passed differently in p{readv,writev}{64} [20350] libc: There is no test for p{read,write}64 [20357] math: Incorrect cos result for 1.5174239687223976 [20384] build: Don't run libmvec-sincos-avx* tests on non avx machines Contributors ============ This release was made possible by the contributions of many people. The maintainers are grateful to everyone who has contributed changes or bug reports. These include: Adhemerval Zanella Andreas Schwab Andrew Senkevich Anton Blanchard Arnas Udovičius Aurelien Jarno Carlos Eduardo Seo Carlos O'Donell Chris Metcalf Chung-Lin Tang Claude Paroz Dimitris Pappas Dmitry V. Levin Dylan Alex Simon Eduardo Trápani Florian Weimer Gabriel F. T. Gomes Gunnar Hjalmarsson Gustavo Romero Guy Rutenberg H.J. Lu Hongjiu Zhang Jiyoung Yun John David Anglin Joseph Myers Khem Raj Maciej W. Rozycki Mark Wielaard Marko Myllynen Martin Galvan Matthew Fortune Matthias Wallnoefer Mike FABIAN Mike Frysinger Neskie Manuel Nick Alcock Paras pradhan Paul E. Murphy Paul Pluzhnikov Rajalakshmi Srinivasaraghavan Rical Jasan Richard Henderson Robin van der Vliet Roland McGrath Samuel Thibault Siddhesh Poyarekar Simion Onea Stefan Liebler Stephen Gallagher Szabolcs Nagy Timur Birsh Torvald Riegel Tulio Magno Quites Machado Filho Wilco Dijkstra Will Newton Yvan Roux Zack Weinberg -- If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.
Posted Aug 5, 2016 2:23 UTC (Fri)
by abatters (✭ supporter ✭, #6932)
[Link] (20 responses)
Bewildered and confused...
Posted Aug 5, 2016 3:15 UTC (Fri)
by ehiggs (subscriber, #90713)
[Link] (15 responses)
http://man7.org/linux/man-pages/man3/readdir_r.3.html
For convenience, the interesting bit for you is as follows:
* On systems where NAME_MAX is undefined, calling readdir_r() may be
* On some systems, readdir_r() can't read directory entries with
* In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
* It is expected that a future version of POSIX.1 will make
Posted Aug 5, 2016 15:02 UTC (Fri)
by cruff (subscriber, #7201)
[Link]
Posted Aug 5, 2016 19:44 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (13 responses)
Application code isn't supposed to use
I think that's misguided. For better or worse, a 255-character limit on traditional filesystems is here to stay. And while we can all easily _imagine_ scenarios where we could use (or abuse) longer file names, we all know that it's not very practical. (We could always up it to 1024 and call it a day.) In the end I think the complexities outweigh any possible benefit, especially given that the software interface with the traditional filesystem is effectively moving further and further down the stack. That doesn't make it any less important, but it means stability and consistency should be emphasized over flexibility. And in any event, other environments like Windows, OS X, and POSIX itself have much more onerous limitations to their interfaces, either in terms of length or content of filenames. So this isn't an area where sane people would attempt to push the limits when solving problems, at least not in a way which relies on filenames for storing arbitrary data.
Given the current security realities, I think it's better to focus on stabilizing and simplifying the syscall and libc landscape. While interfaces like readdir hide the complexity from application code, that's beside the point--there have been plenty of bugs and exploits in both glibc and the kernel related to their interface implementations. Arbitrary limits abound in software and that will never change. We shouldn't try to support dynamic limits at all costs, especially when the relative benefit is so miniscule and speculative.
That said, it's obviously far easier to use readdir than readdir_r. And, yeah, most implementations are thread safe. But at this point Linux is the only OS keeping up-to-date with POSIX, largely because Red Hat employees dominate the committee. The BSDs are falling further behind, and commercial vendors like Solaris and AIX effectively stopped caring altogether. Both AIX and Solaris seem to have focused on Linux/glibc compatibility (whether or not a POSIX addition) and other practical and usability concerns.
The thing is, if people never tried compiling their software on, e.g., Solaris, they would have never realized that NAME_MAX is not always defined. And while it's rare to see software that actually uses readdir_r, that only proves that few people paid attention to the issues to begin with. While we can sometimes improve the situation, as in this case by making readdir thread safe, we'll never be able to excise all the code that directly or indirectly relies on NAME_MAX, PATH_MAX, and similar limits. Heck, those constants influenced (and in some cases were influenced by) fixed limits in various RFCs. We'll never be able to leave them behind. I'd rather see us embrace them so we can work to simplify code bases.
I'm making far too much of this than it deserves. Mostly I'm responding to the opinion that seems to be widely held in some circles that we should support arbitrary limits in filesystem paths and similar kernel interfaces. While I don't agree with David Wheeler that we should restrict filenames to, e.g., UTF-8-encoding graphic characters (with some additional constraints on whitespace), I basically agree with the general sentiment. Secure interfaces are simple interfaces; simple interfaces often require drawing strict lines; and strict lines are sometimes arbitrary. So be it. More oever, in this area the lines have already been drawn by historical practice, and intentionally or unintentionally baked into the architecture of almost all software and software standards.
Posted Aug 5, 2016 20:43 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Aug 5, 2016 21:39 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (5 responses)
Posted Aug 5, 2016 21:55 UTC (Fri)
by barryascott (subscriber, #80640)
[Link]
Posted Aug 6, 2016 0:45 UTC (Sat)
by compenguy (guest, #25359)
[Link] (1 responses)
From experience I can say that the "DOS" commandline tools on windows *cannot* be coaxed into accepting the longer paths. I wound up re-implementing them in python (pycp and pymkdir) in order to manipulate very long paths in windows.
Posted Aug 6, 2016 10:19 UTC (Sat)
by k8to (guest, #15413)
[Link]
It's pretty awful to have to shove this garbage into the path strings. Code later has to know to take them back out again when showing them to users, printing them to error logs, etc.
Posted Aug 6, 2016 12:51 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Aug 6, 2016 17:25 UTC (Sat)
by Mook (subscriber, #71173)
[Link]
On the happy side, as of last week with .net 4.6.2 it's now possible to to use longer path names. Sometimes, maybe. (It looks like it might possibly work with Windows 10 with the recent update, since there's a OS-side switch involved too.) Assuming nothing else in the code between the user and the disk gets in the way.
It most definitely was limited to ~260 up to a few years ago, though.
Posted Aug 8, 2016 7:01 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
And curious whether the above is fine with path limits or filename limits being 256? Paths can easily exceed 256...
Posted Aug 6, 2016 17:13 UTC (Sat)
by ehiggs (subscriber, #90713)
[Link] (1 responses)
Well of course we need to have *some* restriction otherwise resource exhaustion becomes an attack vector. And then it indeed becomes arbitrary.
Posted Aug 6, 2016 19:42 UTC (Sat)
by lsl (subscriber, #86508)
[Link]
Preventing an untrusted entity from exhausting resources is probably more reliably done by limiting the resources available to it, regardless of what they're used for.
Posted Aug 7, 2016 18:36 UTC (Sun)
by xtifr (guest, #143)
[Link] (2 responses)
Speaking as someone who has fixed code to satisfy the requests of Hurd developers, the Hurd, as I understand it, does *not* have any arbitrary pathname limits. And, while you or I might be skeptical about the long-term prospects of the Hurd, I doubt you'll persuade the Gnu project to ignore it in their designs and plans.
Posted Aug 10, 2016 23:53 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Aug 11, 2016 15:19 UTC (Thu)
by zlynx (guest, #2285)
[Link]
:-)
Posted Aug 5, 2016 21:18 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Aug 5, 2016 23:52 UTC (Fri)
by lsl (subscriber, #86508)
[Link] (1 responses)
Posted Aug 9, 2016 15:26 UTC (Tue)
by vapier (guest, #15768)
[Link]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/...
Posted Nov 8, 2017 0:17 UTC (Wed)
by martinkunev (guest, #119485)
[Link]
Posted Aug 5, 2016 17:47 UTC (Fri)
by JoeBuck (subscriber, #2330)
[Link] (5 responses)
Posted Aug 5, 2016 18:23 UTC (Fri)
by excors (subscriber, #95769)
[Link] (4 responses)
From the bug report, it sounds like he wasn't the only one who appreciated that kind of sophisticated humour. I still see one reference to "M$" in localedata/charmaps/CP10007, and a couple of "Winblowz" in the ChangeLogs, but it appears most developers nowadays are a bit more grown-up.
Posted Aug 6, 2016 1:33 UTC (Sat)
by welinder (guest, #4699)
[Link] (2 responses)
That, or the fact that the number of people who remember MS-DOS is approaching zero rapidly. One of the two.
Posted Aug 6, 2016 21:03 UTC (Sat)
by clugstj (subscriber, #4020)
[Link] (1 responses)
Well, I hope not as that would mean that I'll be dying soon (or at least losing my mind).
Posted Aug 9, 2016 2:29 UTC (Tue)
by k8to (guest, #15413)
[Link]
Posted Aug 9, 2016 16:50 UTC (Tue)
by vapier (guest, #15768)
[Link]
readdir_r() deprecated?
readdir_r() deprecated?
unsafe because the interface does not allow the caller to specify
the length of the buffer used for the returned directory entry.
very long names. When the glibc implementation encounters such a
name, readdir_r() fails with the error ENAMETOOLONG after the
final directory entry has been read. On some other systems,
readdir_r() may return a success status, but the returned d_name
field may not be null terminated or may be truncated.
not required to be thread-safe. However, in modern
implementations (including the glibc implementation), concurrent
calls to readdir(3) that specify different directory streams are
thread-safe. Therefore, the use of readdir_r() is generally
unnecessary in multithreaded programs. In cases where multiple
threads must read from the same directory stream, using readdir(3)
with external synchronization is still preferable to the use of
readdir_r(), for the reasons given in the points above.
readdir_r() obsolete, and require that readdir() be thread-safe
when concurrently employed on different directory streams.
readdir_r() deprecated?
readdir_r() deprecated?
NAME_MAX
, but fpathconf(dirfd(dp), _PC_NAME_MAX)
. Indeed, both Solaris and Linux (or, at least, glibc GNU folks) push developers away from using NAME_MAX, PATH_MAX, etc, out of a dislike for fixed limits on filesystem names. Solaris has some convoluted syscall APIs for returning various data structures with dynamic (and effectively unbounded) sizes from kernel to user space.
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
Using UNC syntax allows the approx 32k path limit. UNC paths start with \\ and are basically unfriendly for humans.
You would need a nice UI to hide the \\ geeky stuff.
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
readdir_r() deprecated?
MS-DOG
MS-DOG
MS-DOG
MS-DOG
MS-DOG
MS-DOG