public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/15736] New: mismatch between strcasecmp and toupper/tolower in tr_TR.iso88599 locale
@ 2013-07-12 17:52 vincent-srcware at vinc17 dot net
  2013-07-15  6:38 ` [Bug libc/15736] " jrnieder at gmail dot com
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: vincent-srcware at vinc17 dot net @ 2013-07-12 17:52 UTC (permalink / raw)
  To: glibc-bugs

http://sourceware.org/bugzilla/show_bug.cgi?id=15736

            Bug ID: 15736
           Summary: mismatch between strcasecmp and toupper/tolower in
                    tr_TR.iso88599 locale
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: vincent-srcware at vinc17 dot net
                CC: drepper.fsp at gmail dot com

There is a mismatch between strcasecmp and toupper/tolower in the
tr_TR.iso88599 locale:

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <ctype.h>
#include <strings.h>

int main (void)
{
  int i, j, k;
  char *infs[] = { "INF", "inf" };

  if (setlocale (LC_ALL, "") == NULL)
    {
      fprintf (stderr, "locale-test: can't set locales\n");
      exit (EXIT_FAILURE);
    }

  for (i = 0; i < 2; i++)
    for (j = 0; j < 4; j++)
      {
        char s[4];
        for (k = 0; k < 3; k++)
          {
            s[k] = infs[i][k];
            if (j > k)
              s[k] = (i ? toupper : tolower)(s[k]);
          }
        s[3] = '\0';
        printf ("%d%d %s\n",
                !strcasecmp (s, "INF"), !strcasecmp (s, "inf"), s);
      }

  return 0;
}

gives:

11 INF
00 ıNF
00 ınF
00 ınf
11 inf
00 İnf
00 İNf
00 İNF

Since the modifications of the string have been done with toupper and tolower,
I would have expected 11 everywhere.

Tested on Debian/unstable (amd64). Corresponding bug report:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716775

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19128-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Jul 13 12:25:26 2013
Return-Path: <glibc-bugs-return-19128-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 13042 invoked by alias); 13 Jul 2013 12:25:26 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 10798 invoked by uid 48); 13 Jul 2013 12:23:23 -0000
From: "kurt at roeckx dot be" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/15726] getaddrinfo() returns incorrect status
Date: Sat, 13 Jul 2013 12:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.17
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kurt at roeckx dot be
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15726-131-tF8271L3a2@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15726-131@http.sourceware.org/bugzilla/>
References: <bug-15726-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00069.txt.bz2
Content-length: 2141

http://sourceware.org/bugzilla/show_bug.cgi?id=15726

--- Comment #10 from Kurt Roeckx <kurt at roeckx dot be> ---
(In reply to Thomas Hood from comment #9)
> In general I think we should try to follow the RFC — preferably, if
> reasonable, as it has already been interpreted by other significant unixes.

If the rfc is open for interpretation, I think we should try and get it (or
posix) fixed.

> The most important distinction is that between (1) not receiving an answer
> (whether this be because the function is not called properly, the network is
> down, there are no more file descriptors, whatever); and (2) receiving an
> answer (whether it be an answer containing the requested information or an
> answer containing the information that the name in question does not exist
> in the available sources).
> 
> 1. No answer received: AGAIN, BADFLAGS, FAIL, FAMILY, MEMORY, SERVICE,
> SOCKTYPE, SYSTEM
> 2. Answer was received: 0

I'm not sure I understand what you're trying to say here.  do both 1's and 2's
match?  Note that if it returns 0 it should have at least 1 address as result.

I also think the return value can be AGAIN in case the server does reply, but
for instance returns a temporary failure.  Or we only had the A reply and not
the AAAA reply.

> RFC3493 says very clearly that it must be returned at least in the case when
> neither nodename nor servname were supplied.

For some cases it's very explicit when which error code should be returned. 
For the the rest it just lists possible error code, not saying when which
should be returned.

> Zack Weinberg wrote:
> > I read that as specifying that EAI_NONAME is the appropriate error
> > return *both* when the name does not resolve (== NXDOMAIN at the
> > DNS level), *and* when "neither nodename nor servname were supplied".
> >
> > I think it's kind of unfortunate that EAI_NONAME is overloaded this way

I first thought it wasn't overloaded this way and was only for cases where you
supplied bad parameters.  Now I'm not sure anymore.


Kurt

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19129-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Jul 14 09:46:13 2013
Return-Path: <glibc-bugs-return-19129-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 21873 invoked by alias); 14 Jul 2013 09:46:13 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 19701 invoked by uid 48); 14 Jul 2013 09:44:10 -0000
From: "jdthood at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/15726] getaddrinfo() returns incorrect status
Date: Sun, 14 Jul 2013 09:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.17
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jdthood at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15726-131-Z4YLiEsNrZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15726-131@http.sourceware.org/bugzilla/>
References: <bug-15726-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00070.txt.bz2
Content-length: 2210

http://sourceware.org/bugzilla/show_bug.cgi?id\x15726

--- Comment #11 from Thomas Hood <jdthood at gmail dot com> ---
> > 1. No answer received: AGAIN, BADFLAGS, FAIL, FAMILY, MEMORY, SERVICE,
> > SOCKTYPE, SYSTEM
> > 2. Answer was received: 0
>
> I'm not sure I understand what you're trying to say here.  do both 1's and
> 2's match?  Note that if it returns 0 it should have at least 1 address
> as result.

When status 0 is received it means that an answer has been received to the
question (simplifying a bit) "What are the addresses corresponding to this
nodename + servname?"

"There is no address corresponding to the given nodename + servname" is also an
answer.

But "Sorry, we couldn't find out what addresses correspond to this nodename +
servname because we ran out of file descriptors" is not what I am calling an
answer.

Put another way, when a client receives an answer, the client has the
information that was stored in the name services; when the client receives no
answer, the client does not have the information that was stored in the name
services. The client may want to react differently to these two outcomes.

When AGAIN, BADFLAGS, FAIL, FAMILY, MEMORY, SERVICE, SOCKTYPE, SYSTEM are
returned, it means that no answer was received.

When status 0 is returned, it means that an answer was received.

Q1. Now, what does it mean when NONAME is returned? If both nodename and
servname were null then it means just that. And if nodename and servname were
not null? Is NONAME ever returned in that case, and if so, under what
circumstances?

Q2. What is returned when the answer is "There is no address corresponding to
the given nodename + servname", i.e., in the case of DNS, NXDOMAIN?

I would be inclined to come out and say that NONAME should be returned under
exactly the following circumstances

    Either nodename and servname are null
    or there is no address corresponding to the given nodename+servname

if it weren't for the fact that the RFC doesn't clearly say that this is what
NONAME means, and the fact that I haven't yet looked closely enough at how
other unices have interpreted the RFC.

--
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-08-19 15:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-12 17:52 [Bug libc/15736] New: mismatch between strcasecmp and toupper/tolower in tr_TR.iso88599 locale vincent-srcware at vinc17 dot net
2013-07-15  6:38 ` [Bug libc/15736] " jrnieder at gmail dot com
2013-07-15 15:36 ` vincent-srcware at vinc17 dot net
2013-07-16 19:16 ` schwab@linux-m68k.org
2013-08-27 10:27 ` schwab@linux-m68k.org
2014-06-13  9:24 ` fweimer at redhat dot com
2021-08-19 15:34 ` fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).