Bug#884075: [Bug regex/11053] Wrong results with backreferences

[Vincent Lefevre]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=29560

On 2022-09-05 19:37:18 -0500, Paul Eggert wrote:
> It looks like my comment
>  was incorrect,
> in that the two bugs are different bugs. glibc bug 11053 is fixed, but
> Debian bug 884075 is not fixed. Perhaps a better match for Debian bug 884075
> is glibc bug 10844.

Bug 10844 actually seems to be a different bug.
I've reported bug 29560 upstream concerning 1.

So there are 3 upstream bugs concerning bad results with backreferences
(but the regexp's are rather different is each case):

  https://sourceware.org/bugzilla/show_bug.cgi?id=10844
(ab*){1,9}\1

  https://sourceware.org/bugzilla/show_bug.cgi?id=17356
(.{0,1})(.{0,1})(.{0,1})\3\2\1

  https://sourceware.org/bugzilla/show_bug.cgi?id=29560
^(11+)\1+$|^1?$

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: Re: Bug#884075: [Bug regex/11053] Wrong results with backreferences

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=29560
Bug #884075 [glibc] glibc: Wrong results with regex backreferences
Changed Bug forwarded-to-address to 
'https://sourceware.org/bugzilla/show_bug.cgi?id=29560' from 
'https://sourceware.org/bugzilla/show_bug.cgi?id=10844'.

-- 
884075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[bts-link] source package glibc

[debian-bts-link]

#
# bts-link upstream status pull for source package glibc
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#

user debian-bts-l...@lists.debian.org

# remote status report for #884075 (http://bugs.debian.org/884075)
# Bug title: glibc: Wrong results with regex backreferences
#  * http://sourceware.org/bugzilla/show_bug.cgi?id=29560
#  * remote status changed: ASSIGNED -> UNCONFIRMED
usertags 884075 - status-ASSIGNED
usertags 884075 + status-UNCONFIRMED

thanks

Bug#854821: marked as done (iconv: behavior change with C.UTF-8)

[Debian Bug Tracking System]

Your message dated Thu, 8 Sep 2022 23:48:50 +0200
with message-id 
and subject line Re: Transliteration in C.UTF-8 locales
has caused the Debian Bug report #854821,
regarding iconv: behavior change with C.UTF-8
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
854821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854821
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc-bin
Version: 2.24-9
Severity: normal

Dear Maintainer,

I am trying to track down the root cause of a FTBFS in phpmyadmin (e.g,
https://launchpadlibrarian.net/301371947/buildlog_ubuntu-zesty-amd64.phpmyadmin_4%3A4.6.5.2-1_BUILDING.txt.gz,
which is due to a testcase failure at build-time:

"iconv(): Detected an illegal character in input string"

The test in question is basically doing:

$ echo "This is the Euro symbol '€'" |iconv -f UTF-8 -t ISO-8859-1//TRANSLIT

Since the builders default to C.UTF-8, if one prefaces this with

$ export LC_ALL=C.UTF-8

in various environments, we get:

Yakkety (libc.bin == 2.24-3ubuntu2) produces:
This is the Euro symbol 'EUR'

Zesty (libc.bin == 2.24-7ubuntu2) produces:
This is the Euro symbol 'iconv: illegal input sequence at position 25

Stretch & Sid (libc.bin == 2.24.9) produce:
This is the Euro symbol 'iconv: illegal input sequence at position 25

Given that phpmyadmin did build in Sid (earlier), I'm guessing that on
the next rebuild of phpmyadmin, it will fail in the same way as Ubuntu.

If the LC_ALL is set to POSIX or en_US.UTF-8 or C, the testcase passes
in all environments. I am not sure if this is due to the change back to
combining for transliteration in C.UTF-8, the update to Unicode 9, or a
combination of the two, but I think this behavior change was unintended?

The following is from my reporting system (running Ubuntu), but I am
able to reproduce the issue in a Sid schroot, as mentioned.

-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-37-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc-bin depends on:
ii  libc6  2.24-3ubuntu2

libc-bin recommends no packages.

Versions of packages libc-bin suggests:
ii  manpages  4.07-1

-- no debconf information

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
--- End Message ---
--- Begin Message ---
Version: 2.31-5

Hi,

On 2017-03-31 21:05, Michal Čihař wrote:
> Hi
> 
> I was just forced to look at this again (see #859219) and I think the
> transliteration is not working as it should.
> 
> What is actually reason to make it behave differently on C.UTF-8 than
> on other UTF-8 locales? Does it really have to be that either
> transliteration of "ç" is broken or transliteration of "€" is broken
> for this locale?
> 
> In most other UTF-8 locales (if not all, I've not tested this) both of
> them work just fine:
> 
> $ echo "ça va €" | LC_ALL=en_GB.UTF-8  iconv -f UTF-8 -t
> "ascii//TRANSLIT"
> ca va EUR
> $ echo "ça va €" | LC_ALL=de_DE.UTF-8  iconv -f UTF-8 -t
> "ascii//TRANSLIT"
> ca va EUR
> $ echo "ça va €" | LC_ALL=cs_CZ.UTF-8  iconv -f UTF-8 -t
> "ascii//TRANSLIT"
> ca va EUR
> $ echo "ça va €" | LC_ALL=C.UTF-8  iconv -f UTF-8 -t "ascii//TRANSLIT"
> ca va iconv: illegal input sequence at position 7

This has been fixed in glibc 2.31-5. Closing the bug accordingly.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature
--- End Message ---

Bug#874798: marked as done (libc6: mktime() does not set errno when it fails)

[Debian Bug Tracking System]

Your message dated Thu, 8 Sep 2022 23:48:55 +0200
with message-id 
and subject line Re: libc6: mktime() does not set errno when it fails
has caused the Debian Bug report #874798,
regarding libc6: mktime() does not set errno when it fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
874798: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874798
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.24-11+deb9u1
Severity: normal
Tags: upstream

When mktime() fails to convert a struct tm to a time_t, it returns -1.
It should also set errno to EOVERFLOW in order to distinguish the failure
from the legitimate case of converting "1 second before the epoch".

The following program, when run on a 32-bit system, shows that mktime
does not comply to the standard.  On recent amd64 systems, time_t is 64
bit long, therefore failure doesn't occur for the same broken down times.

Best regards,
g.b.

#define _POSIX_C_SOURCE 200112L

#include 
#include 
#include 
#include 
#include 

int main() {
struct tm tm0;
struct tm *ptm;
time_t t;
int eno;

assert(sizeof t == 4);  /* need 32 bit to trigger failure in 1900 */

/* nail timezone to UTC */
setenv("TZ", "UTC", 1);
tzset();

t = -1; /* 1 sec before epoch */
ptm = gmtime_r(&t, &tm0);
assert(ptm != NULL);
errno = 0;
t = mktime(&tm0);
eno = errno;
printf("struct TM: %d-%d-%d %02d:%02d:%02d (dst=%d)\n", 1900 + tm0.tm_year,
   1 + tm0.tm_mon, tm0.tm_mday, tm0.tm_hour, tm0.tm_min,
   tm0.tm_sec, tm0.tm_isdst);
printf("mktime(): retval %ld (expected -1), "
   "errno %d (expected 0)\n", (long) t, eno);

tm0.tm_year = 0;/* warp to year 1900 */
/* bad conversion for 32-bit time_t, should return -1 and set errno */
errno = 0;
t = mktime(&tm0);
eno = errno;
printf("struct TM: %d-%d-%d %02d:%02d:%02d (dst=%d)\n", 1900 + tm0.tm_year,
   1 + tm0.tm_mon, tm0.tm_mday, tm0.tm_hour, tm0.tm_min,
   tm0.tm_sec, tm0.tm_isdst);
printf("mktime(): retval %ld (expected -1), "
   "errno %d (expected EOVERFLOW=%d)\n", (long) t, eno, EOVERFLOW);
return 0;
}


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.3.0-18

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.61
pn  glibc-doc  
ii  libc-l10n  2.24-11+deb9u1
ii  locales2.24-11+deb9u1

-- debconf information excluded
--- End Message ---
--- Begin Message ---
Version: 2.29-1

Hi,

On 2017-09-09 19:29, g1 wrote:
> Package: libc6
> Version: 2.24-11+deb9u1
> Severity: normal
> Tags: upstream
> 
> When mktime() fails to convert a struct tm to a time_t, it returns -1.
> It should also set errno to EOVERFLOW in order to distinguish the failure
> from the legitimate case of converting "1 second before the epoch".
> 
> The following program, when run on a 32-bit system, shows that mktime
> does not comply to the standard.  On recent amd64 systems, time_t is 64
> bit long, therefore failure doesn't occur for the same broken down times.
> 

This bug has been fixed in glibc 2.29-1. Closing the bug accordingly.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net--- End Message ---