|
|
Subscribe / Log in / New account

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.


to post comments

readdir_r() deprecated?

Posted Aug 5, 2016 2:23 UTC (Fri) by abatters (✭ supporter ✭, #6932) [Link] (20 responses)

readdir_r() is thread-safe; readdir() is not thread-safe AFAIK. Why did they deprecate the thread-safe version in favor of the unsafe one? What is a multi-threaded program supposed to do? Put a global lock around every use? What about libraries?

Bewildered and confused...

readdir_r() deprecated?

Posted Aug 5, 2016 3:15 UTC (Fri) by ehiggs (subscriber, #90713) [Link] (15 responses)

The updated man page has more information on the issues with readdir_r:

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
unsafe because the interface does not allow the caller to specify
the length of the buffer used for the returned directory entry.

* On some systems, readdir_r() can't read directory entries with
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.

* In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is
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.

* It is expected that a future version of POSIX.1 will make
readdir_r() obsolete, and require that readdir() be thread-safe
when concurrently employed on different directory streams.

readdir_r() deprecated?

Posted Aug 5, 2016 15:02 UTC (Fri) by cruff (subscriber, #7201) [Link]

Thanks for posting that description. I was bewildered also, having used readdir_r extensively in multithreaded programs.

readdir_r() deprecated?

Posted Aug 5, 2016 19:44 UTC (Fri) by wahern (subscriber, #37304) [Link] (13 responses)

Application code isn't supposed to use 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.

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.

readdir_r() deprecated?

Posted Aug 5, 2016 20:43 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Windows allows up to 32k characters in a filename through Win32 APIs.

readdir_r() deprecated?

Posted Aug 5, 2016 21:39 UTC (Fri) by Sesse (subscriber, #53779) [Link] (5 responses)

I don't know the details, but I know .NET developers who had to move their projects into c:\p (from c:\Documents and Settings\Full name of the user\Visual Studio projects, or whatever) because they ended up hitting some path length limit. So in practice, at least with Microsoft's own tools and quite recently (3–4 years), the limit is much lower than 32k.

readdir_r() deprecated?

Posted Aug 5, 2016 21:55 UTC (Fri) by barryascott (subscriber, #80640) [Link]

the windows limit traditionally was 257, 255 for the path + 2 for c: drive.
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?

Posted Aug 6, 2016 0:45 UTC (Sat) by compenguy (guest, #25359) [Link] (1 responses)

You only get the very long paths/filenames on windows when calling into the unicode APIs, which is not AIUI what .NET does.

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.

readdir_r() deprecated?

Posted Aug 6, 2016 10:19 UTC (Sat) by k8to (guest, #15413) [Link]

It's worse than that. You have to use the unicode apis (which you should generally do on windows), and you have to pre-pend to your pathnames the magic long-pathname cookie. "\\?\" Thus UNC long pathnames become garbage like "\\?\\\servername\share\dir\dir\filename" and suchlike.

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.

readdir_r() deprecated?

Posted Aug 6, 2016 12:51 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Visual Studio project file paths are limited to some low ceiling and project filenames are limited to 237 or so (with the .vcxproj extension). Also, if your build sysytem doesn't use response files, many of the compiler tools can hit the command line length limit with the MSVC toolchain if you have many include directories.

readdir_r() deprecated?

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.

readdir_r() deprecated?

Posted Aug 8, 2016 7:01 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

Perhaps things have changed, but back in win7 it was some win32 apis, and not others. So I ended up with weird situations where you could write out filepaths that you couldn't read with many programs (at the the time, 7zip). So it was even more of a mess that just prepending special characters.

And curious whether the above is fine with path limits or filename limits being 256? Paths can easily exceed 256...

readdir_r() deprecated?

Posted Aug 6, 2016 17:13 UTC (Sat) by ehiggs (subscriber, #90713) [Link] (1 responses)

"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."

Well of course we need to have *some* restriction otherwise resource exhaustion becomes an attack vector. And then it indeed becomes arbitrary.

readdir_r() deprecated?

Posted Aug 6, 2016 19:42 UTC (Sat) by lsl (subscriber, #86508) [Link]

"No arbitrary limit" is generally understood to mean "limited only by available resources/memory".

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.

readdir_r() deprecated?

Posted Aug 7, 2016 18:36 UTC (Sun) by xtifr (guest, #143) [Link] (2 responses)

> For better or worse, a 255-character limit on traditional filesystems is here to stay.

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.

readdir_r() deprecated?

Posted Aug 10, 2016 23:53 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Indeed, 'no arbitrary limits' has been in the GNU Coding Standards for decades, in direct reaction to the Unix tradition of just using randomly fixed-size buffers everywh

readdir_r() deprecated?

Posted Aug 11, 2016 15:19 UTC (Thu) by zlynx (guest, #2285) [Link]

Nice.

:-)

readdir_r() deprecated?

Posted Aug 5, 2016 21:18 UTC (Fri) by ballombe (subscriber, #9523) [Link] (3 responses)

I assume GLIBC readdir use thread-local-storage which make readdir_r obsolete.

readdir_r() deprecated?

Posted Aug 5, 2016 23:52 UTC (Fri) by lsl (subscriber, #86508) [Link] (1 responses)

Why would you need TLS when readdir takes an opaque context argument anyway?

readdir_r() deprecated?

Posted Aug 9, 2016 15:26 UTC (Tue) by vapier (guest, #15768) [Link]

it doesn't use TLS (ignoring of course errno). thread safety is achieved by having a lock embedded in the opaque DIR structure, and then readdir grabs/releases that lock.

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/...

readdir_r() deprecated?

Posted Nov 8, 2017 0:17 UTC (Wed) by martinkunev (guest, #119485) [Link]

This means to write a portable program macro switches have to be used so that readdir() is called when the platform has glibc and readdir_r() when the platform has other versions of the standard library. How convinient...

MS-DOG

Posted Aug 5, 2016 17:47 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (5 responses)

There used to be many more references to MS-DOG in GNU documentation because RMS thought it was funny, and I remember years ago that he objected to efforts to clean them up. Perhaps he is mellowing in his old age, or paying less attention.

MS-DOG

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.

MS-DOG

Posted Aug 6, 2016 1:33 UTC (Sat) by welinder (guest, #4699) [Link] (2 responses)

> it appears most developers nowadays are a bit more grown-up.

That, or the fact that the number of people who remember MS-DOS is approaching zero rapidly. One of the two.

MS-DOG

Posted Aug 6, 2016 21:03 UTC (Sat) by clugstj (subscriber, #4020) [Link] (1 responses)

"the number of people who remember MS-DOS is approaching zero rapidly"

Well, I hope not as that would mean that I'll be dying soon (or at least losing my mind).

MS-DOG

Posted Aug 9, 2016 2:29 UTC (Tue) by k8to (guest, #15413) [Link]

The surgery is not in the least painful. At least as far as you'll remember.

MS-DOG

Posted Aug 9, 2016 16:50 UTC (Tue) by vapier (guest, #15768) [Link]

both should be fixed now in the latest git repo. feel free to highlight any others.


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds