Andi Kleen <[EMAIL PROTECTED]> wrote: > Hello, > > I was doing some binary size comparisons between -m32 and -m64 builds on > x86_64 > Linux (SUSE 10.2 with gcc 4.1.2). This is the same build environment, same > glibc, etc. > just one configured for i386-linux and built with -m32 and the other for > x86_64-linux > > One thing I noticed is that a few executable sizes differ widely: > > (.text sizes) 64bit 32bit > ./src/csplit 95481 27704 > ./src/nl 87879 19551 > ./src/ptx 98316 28623 > ./src/expr 88373 20731 > ./src/tac 83726 15935 > > The other differences are in the expected range of a few percent. > > On some investigation it looks like 64bit contains the regexpr functions and > some > other library functions, while the 32bit versions use the one from glibc. > I assume that must be a (harmless) bug since the glibc version (2.5) is > identical > between 32bit and 64bit.
Hi Andi, Thanks for reporting that. glibc-2.5's regex code probably still suffers from the bug that makes it misbehave on 64-bit systems for strings longer than 2^31 bytes. This has been fixed in gnulib's regex code since glibc-2.3.5. So, coreutils works around it, along with any other project that uses gnulib's regex module, by detecting the offending condition and providing a working replacement. Here's the relevant part of m4/regex.m4: /* Reject hosts whose regoff_t values are too narrow. These include glibc 2.3.5 on hosts with 64-bit ptrdiff_t and 32-bit int. */ if (sizeof (regoff_t) < sizeof (ptrdiff_t) || sizeof (regoff_t) < sizeof (ssize_t)) exit (1); When that configure-run test program fails, those programs link with the replacement regex functions from gnulib. If you want to save space in those executables, and you don't think there's a significant risk of malfunction[*], you can make coreutils use the library code like this: gl_cv_func_re_compile_pattern_working=yes ./configure [*] Can you even get a 2GB-long string into expr? I rarely use the regexp code in tac and nl, and use ptx even less frequently. Personally, I'm not worried about csplit failing if/when I run it on a file with such a long line -- I'll have other, more immediate problems with the file, like getting that line into memory :) _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils