This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: ["Khimenko Victor" <khim@sch57.msk.ru>] libc/1496: fmemopen is gone in glibc 2.x
- To: aj at suse dot de, libc-alpha at sourceware dot cygnus dot com
- Subject: Re: ["Khimenko Victor" <khim@sch57.msk.ru>] libc/1496: fmemopen is gone in glibc 2.x
- From: "Khimenko Victor" <khim at sch57 dot msk dot ru>
- Date: Tue, 28 Dec 1999 16:14:55 +0300 (MSK)
- Cc: khim at sch57 dot msk dot ru
- Organization: MCCME
- References: <u8g0wn6ysf.fsf@gromit.rhein-neckar.de>
In <u8g0wn6ysf.fsf@gromit.rhein-neckar.de> Andreas Jaeger (aj@suse.de) wrote:
AJ> We've received the appended bug report. fmemopen is a function only
AJ> available in libio but not in stdio.
No. Other way around. It's available in stdio but not in libio :-)
AJ> Is anybody interested in writing fmemopen for stdio? Or is this an
AJ> obsolete function?
If it's obsoleted it should be at least marked as such in documentation.
IMNSHO. But it can be usefull sometimes. open_memstream implementation has
some "memory stream" but AFAIK not all functions needed for fmemopen() are
implemented. And I'm not know enough about libio internals to write
implementation itself :-(
AJ> P.S. Khimenko: Using stdio instead of libio is no option on Linux.
Hmm ? Why not ? It'll be not binary compatible with normal "glibc", but
it should work, doesn't it ?
AJ> X-From-Line: aj Wed Dec 22 15:34:12 1999
AJ> Return-path: <jaeger@mescaline.gnu.org>
AJ> Envelope-to: aj@localhost
AJ> Delivery-date: Wed, 22 Dec 1999 15:34:12 +0100
AJ> Received: from [127.0.0.1] (helo=ssh-wotan.suse.de ident=root)
AJ> by arthur.rhein-neckar.de with esmtp (Exim 3.11 #1)
AJ> id 120mnZ-0000WE-01
AJ> for aj@localhost; Wed, 22 Dec 1999 15:31:29 +0100
AJ> Received: from Galois.suse.de (Galois.suse.de [10.0.0.1])
AJ> by Wotan.suse.de (Postfix) with ESMTP id 2379F7F9D
AJ> for <aj@wotan.suse.de>; Wed, 22 Dec 1999 09:12:55 +0100 (MET)
AJ> Received: from Cantor.suse.de (Cantor.suse.de [194.112.123.193])
AJ> by Galois.suse.de (Postfix) with ESMTP id EBCF66C96
AJ> for <aj@wotan.suse.de>; Wed, 22 Dec 1999 09:03:26 +0100 (MET)
AJ> Received: from Galois.suse.de (Galois.suse.de [194.112.123.130])
AJ> by Cantor.suse.de (Postfix) with ESMTP id BC2641E093
AJ> for <aj@wotan.suse.de>; Wed, 22 Dec 1999 09:03:26 +0100 (MET)
AJ> Received: from Cantor.suse.de (Cantor.suse.de [194.112.123.193])
AJ> by Galois.suse.de (Postfix) with ESMTP id 3F15F6C96
AJ> for <aj@wotan.suse.de>; Wed, 22 Dec 1999 08:18:46 +0100 (MET)
AJ> Received: from Galois.suse.de (Galois.suse.de [194.112.123.130])
AJ> by Cantor.suse.de (Postfix) with ESMTP id 997A11E099
AJ> for <aj@wotan.suse.de>; Wed, 22 Dec 1999 08:18:45 +0100 (MET)
AJ> Received: by Galois.suse.de (Postfix)
AJ> id 42CCC6FF5; Wed, 22 Dec 1999 07:30:55 +0100 (MET)
AJ> Received: from Cantor.suse.de (Cantor.suse.de [194.112.123.193])
AJ> by Galois.suse.de (Postfix) with ESMTP id 89E1072F0
AJ> for <aj@suse.de>; Wed, 22 Dec 1999 07:10:30 +0100 (MET)
AJ> Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
AJ> by Cantor.suse.de (Postfix) with ESMTP id 910911E0C2
AJ> for <aj@suse.de>; Wed, 22 Dec 1999 07:10:09 +0100 (MET)
AJ> Received: (from gnats@localhost)
AJ> by mescaline.gnu.org (8.9.1a/8.9.1) id BAA19487;
AJ> Wed, 22 Dec 1999 01:10:02 -0500
AJ> Resent-Date: Wed, 22 Dec 1999 01:10:02 -0500
AJ> Resent-Message-Id: <199912220610.BAA19487@mescaline.gnu.org>
AJ> Resent-From: gnats@gnu.org (GNATS Management)
AJ> Resent-To: libc-gnats@gnu.org
AJ> Resent-Cc: gnats-admin@gnu.org
AJ> Resent-Reply-To: bugs@gnu.org, "Khimenko Victor" <khim@sch57.msk.ru>
AJ> Received: from dell.sch57.msk.ru (IDENT:root@firewall-in.sch57.msk.ru [195.178.195.6])
AJ> by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id BAA19378
AJ> for <bugs@gnu.org>; Wed, 22 Dec 1999 01:04:27 -0500
AJ> Received: from khim.UUCP (uucp@localhost)
AJ> by dell.sch57.msk.ru (8.8.8/8.8.8) with UUCP id IAA03118
AJ> for bugs@gnu.org; Wed, 22 Dec 1999 08:57:21 +0300
AJ> Received: by khim.sch57.msk.ru (dMail for DOS v2.07a2, 12Jun98);
AJ> Wed, 22 Dec 1999 09:00:40 +0300
AJ> X-Gnus-Mail-Source: directory:/mail-aj/Mail/procmail-work/
AJ> Message-Id: <AB7a6Ou4lM@khim.sch57.msk.ru>
AJ> Date: Wed, 22 Dec 1999 09:00:39 +0300 (MSK)
AJ> From: "Khimenko Victor" <khim@sch57.msk.ru>
AJ> To: bugs@gnu.org
AJ> Subject: libc/1496: fmemopen is gone in glibc 2.x
AJ> Resent-Sender: jaeger@mescaline.gnu.org
AJ> X-UIDL: e7bf25b73f1d2918e9d3d33edec8748f
AJ> Status: O
AJ> Lines: 57
AJ> Xref: gromit.rhein-neckar.de mail.gnats-libc-bugs:4359
AJ> Note: There was a bad value `sw-bug|doc-bug' for the field `>Class:'.
AJ> It was set to the default value of `sw-bug'.
>>Number: 1496
>>Category: libc
>>Synopsis: fmemopen.c exist in stdio subdirectory but not in libio
>>Confidential: no
>>Severity: non-critical
>>Priority: low
>>Responsible: libc-gnats
>>State: open
>>Class: sw-bug
>>Submitter-Id: unknown
>>Arrival-Date: Wed Dec 22 01:10:01 EST 1999
>>Last-Modified:
>>Originator: root
>>Organization:
AJ> The Moscow State 57th school
>>Release: libc-2.1.2
>>Environment:
AJ> Host type: i586-ksi-linux-gnu
AJ> System: Linux localhost.localdomain 2.2.10-ac10 #1 SMP Mon Jul 12 14:10:36 EEST 1999 i586 unknown
AJ> Architecture: i586
AJ> Addons: crypt glibc-compat linuxthreads
AJ> Build CFLAGS: -mcpu=pentium -march=pentium -pipe -bi586-ksi-linux -D__USE_STRING_INLINES -fstrict-aliasing -g -O2
AJ> Build CC: gcc
AJ> Compiler version: 2.95.2 19991024 (release)
AJ> Kernel headers: 2.2.10-ac10
AJ> Symbol versioning: yes
AJ> Build static: yes
AJ> Build shared: yes
AJ> Build pic-default: no
AJ> Build profile: yes
AJ> Build omitfp: no
AJ> Build bounded: no
AJ> Build static-nss: no
AJ> Stdio: libio
>>Description:
AJ> Function fmemopen is described in libc.info but not actually available
AJ> It's available with stdio library but not with libio library :-((
AJ> open_memstream() exists in libio but it's not always enough :-/
>>How-To-Repeat:
AJ> Grab sample program from glibc's info documentation about fmemopen
AJ> and try to compile it :-)
>>Fix:
AJ> Use of GNU stdio instead of GNU libio ... Perhaps change in
AJ> documentation can be called "fix" as well but it does not look like a
AJ> good fix to me ...
>>Audit-Trail:
>>Unformatted: