From drepper@cygnus.com Tue Jun 1 10:38:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 01 Jun 1999 10:38:00 -0000 Subject: GPL (not LGPL) in libio and restrictions References: <19990531164603.AAC3457BA@ocean.lucon.org> Message-ID: Andreas Jaeger writes: > Glad to hear. If this is agreed on, we should implement it directly. > I'm appending a patch which should be applied to both glibc 2.1 and > 2.2 trees. I haven't applied any patch because RMS is currently changing the LGPL. There is a revision 2.1 which he thinks is finished. I don't agree and so we are still stuck. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Tue Jun 1 11:33:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 01 Jun 1999 11:33:00 -0000 Subject: getloadavg in libc References: <199905302114.RAA12164@frob.com> Message-ID: Roland McGrath writes: > Current BSD systems have getloadavg in libc, and I think they used to put > it in libutil. In GNU so far, every package has the canonical GNU > getloadavg.c and has to use that. Well, I don't have any general objections. It is not yet in because I don't see any program beside make and Emacs using it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Tue Jun 1 11:41:00 1999 From: roland@frob.com (Roland McGrath) Date: Tue, 01 Jun 1999 11:41:00 -0000 Subject: getloadavg in libc References: Message-ID: <199906011841.OAA04954@frob.com> > Well, I don't have any general objections. It is not yet in because I > don't see any program beside make and Emacs using it. The issue came up because I am encountering non-GNU free software that needs some way to get load averages. Rather than fixing its OS-specific code, I'd rather have it use getloadavg from libc when available. From hjl@lucon.org Tue Jun 1 21:44:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Tue, 01 Jun 1999 21:44:00 -0000 Subject: An Elm bug or a glibc bug? Message-ID: <19990602044449.77A9557B9@ocean.lucon.org> Something is wrong with elm in RedHat 6.0. For some reason, elm is messing up 8-bit code. I am enclosing a testcase here. Please do # tar xfz t.tar.gz # elm -f t # diff -upa t.orig t You need to read the email first. Elm will rewrite the folder. As you will see, it adds '^@' at each line with 8bit code. I am not sure if the bug is in Elm or glibc although elm in RedHat 5.2 is ok. I will see what I can find out. Thanks. -- H.J. Lu (hjl@gnu.org) ---- begin 644 t.tar.gz M'XL(`+2T5#<``^V4ST\3013'N3I_Q3NV"5MWVVYK%R1@NT`)Q<8V:C0>EG9: MEM1=LCMKX,]IU@/41$@$$H.16!8D$"LA4!/B%4F()P_^.A!G6K`!0>/!FNA\ M)CNS>?-FYCMO9AX)F)9>[/BC2*(8$47H`)"BV_)R9D&O0Q% M@*R#8<@QZ#E`4%)"HD+/1(K%8N@&)HYE"&F-C"G0?6I4#TK@DOX`6S@O9$WE M])1T8`[3SKP"HU-@YK!F!%KK^=*F30KZ9"<4F!C'QI:>IW=`%/WH$OT+]X?5 M?CEZ+=;%E'4R64P=4]32)XA1>L5\Z436CS+.Z#C.$06RV";H!S7@&PP,!6#8 M\:.$1K#2G/57D]X64II>PI8"ZG`*[M*=VKII0#`@0WI8G+#PE7LHE4RIPLUF MCP)20$1QTR#8($)V:H(N1/`DN3Q1TG2C"W)CFF5CXAZSP2W![$#OC@` M&:(1QU;@.D+E"UFJL/JUQ^I:H]ZM(`1GB`\F1_I@1+V5@41R0,UD06C8U(P* MJ;Z!OCOT%WSQD8003_D17>]AN=+\UA^]_+#QYMEV?:OF+1QX.VM[R[/EM:FV565Y]KAZXT^Z*6W,]=Z;^:>Y]:_2Q\@HMY86]36_QZ,67M;T3RSDT M["O+];>U_2\ MPTUOIUK;7]^=GU^>=6>0(``ZCB[X6-2+AL-B3G?\MY_ZN9`VK/$[^3\8EJ@I M&HI&>/YO!SS_\_S/\___F_\Y'`Z'P^%P.!P.A\/A<#@<#H?#X7`X',Z_PS>( ': Hello, I think this should fix the small remaining Emacs-20.3 problem when MALLOC_CHECK_ is set. Regards, Wolfram. 1999-06-05 Wolfram Gloger * malloc/malloc.c (check_action): Change into bitmap so that both diagnostic and abort can be requested by setting it to 3. (mALLOC_SET_STATe): Disable malloc checking if necessary. --- /home/wg/src/malloc/glibc-malloc/malloc.c Sun May 16 23:21:43 1999 +++ malloc.c Sat Jun 5 12:40:45 1999 @@ -1780,7 +1780,7 @@ __free_hook = free_check; __realloc_hook = realloc_check; __memalign_hook = memalign_check; - if(check_action == 1) + if(check_action & 1) fprintf(stderr, "malloc: using debugging hooks\n"); } @@ -4068,7 +4068,11 @@ the heap contents are saved/restored via some other method. The primary example for this is GNU Emacs with its `dumping' procedure. `Hook' function pointers are never saved or restored by these - functions. */ + functions, with two exceptions: If malloc checking was in use when + malloc_get_state() was called, then malloc_set_state() calls + __malloc_check_init() if possible; if malloc checking was not in + use in the recorded state but the user requested malloc checking, + then the hooks are reset to 0. */ #define MALLOC_STATE_MAGIC 0x444c4541l #define MALLOC_STATE_VERSION (0*0x100l + 1l) /* major*0x100 + minor */ @@ -4196,10 +4200,18 @@ /* add version-dependent code here */ if (ms->version >= 1) { #if defined _LIBC || defined MALLOC_HOOKS - /* Check whether it is safe to enable malloc checking. */ + /* Check whether it is safe to enable malloc checking, or whether + it is necessary to disable it. */ if (ms->using_malloc_checking && !using_malloc_checking && !disallow_malloc_check) __malloc_check_init (); + else if (!ms->using_malloc_checking && using_malloc_checking) { + __malloc_hook = 0; + __free_hook = 0; + __realloc_hook = 0; + __memalign_hook = 0; + using_malloc_checking = 0; + } #endif } @@ -4319,13 +4331,11 @@ if((char*)t + chunksize(t) == sbrk_base + sbrked_mem || t == initial_top(&main_arena)) return 0; - switch(check_action) { - case 1: + if(check_action & 1) fprintf(stderr, "malloc: top chunk is corrupt\n"); - break; - case 2: + if(check_action & 2) abort(); - } + /* Try to set up a new top chunk. */ brk = MORECORE(0); front_misalign = (unsigned long)chunk2mem(brk) & MALLOC_ALIGN_MASK; @@ -4374,13 +4384,10 @@ p = mem2chunk_check(mem); if(!p) { (void)mutex_unlock(&main_arena.mutex); - switch(check_action) { - case 1: + if(check_action & 1) fprintf(stderr, "free(): invalid pointer %p!\n", mem); - break; - case 2: + if(check_action & 2) abort(); - } return; } #if HAVE_MMAP @@ -4413,13 +4420,10 @@ oldp = mem2chunk_check(oldmem); if(!oldp) { (void)mutex_unlock(&main_arena.mutex); - switch(check_action) { - case 1: + if(check_action & 1) fprintf(stderr, "realloc(): invalid pointer %p!\n", oldmem); - break; - case 2: + if(check_action & 2) abort(); - } return malloc_check(bytes, NULL); } oldsize = chunksize(oldp); From hjl@lucon.org Sat Jun 5 21:26:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 05 Jun 1999 21:26:00 -0000 Subject: Binutils 2.9.4.0.1 is released. Message-ID: <19990606042647.BF4CD57B9@ocean.lucon.org> Please try this on Linux. Thanks. -- H.J. Lu (hjl@gnu.org) -- This is the beta release of binutils 2.9.4.0.1 for Linux, which is based on binutils 1999 0605 plus various changes. Please report any bugs related to binutils 2.9.4.0.1 to hjl@lucon.org. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. The file list: 1. binutils-2.9.4.0.1.tar.gz. Source code. 2. binutils-2.9.4.0.1-1.src.rpm. Source RPM. 3. binutils-2.9.4.0.1-1.i386.rpm. Binary RPM for RedHat 6.0. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/05/99 From hjl@lucon.org Sun Jun 6 09:09:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 06 Jun 1999 09:09:00 -0000 Subject: binutils 2.9.4.0.1 and Linux/ARM Message-ID: <19990606160909.0F9C957B7@ocean.lucon.org> Hi, I forgot including some important Linux/ARM note on binutils 2.9.4.0.1. If you use Linux/ARM, please make sure you read it first. Sorry for that. -- H.J. Lu (hjl@gnu.org) --- This is the beta release of binutils 2.9.4.0.1 for Linux, which is based on binutils 1999 0605 plus various changes. Please report any bugs related to binutils 2.9.4.0.1 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.1.tar.gz. Source code. 2. binutils-2.9.4.0.1-1.src.rpm. Source RPM. 3. binutils-2.9.4.0.1-1.i386.rpm. Binary RPM for RedHat 6.0. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/05/99 From hjl@lucon.org Sun Jun 6 12:30:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 06 Jun 1999 12:30:00 -0000 Subject: binutils 2.9.4.0.1 is withdrawn. Message-ID: <19990606193042.0BC4E57B7@ocean.lucon.org> Hi, binutils 2.9.4.0.1 has been withdrawn due to the i386 bug which prevents me from building the Linux kernel. I got error messages: ld -m elf_i386 -T /work/linux/src/kernel/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a drivers/pnp/pnp.a drivers/video/video.a \ /work/linux/src/kernel/linux/arch/i386/lib/lib.a /work/linux/src/kernel/linux/lib/lib.a /work/linux/src/kernel/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux arch/i386/kernel/head.o: In function `_stext': arch/i386/kernel/head.o(.text+0x18): relocation truncated to fit: R_386_32 boot_cpu_data arch/i386/kernel/init_task.o(.data.init_task+0x2fc): relocation truncated to fit: R_386_32 swapper_pg_dir arch/i386/kernel/kernel.o: In function `machine_restart': arch/i386/kernel/kernel.o(.text+0x178a): relocation truncated to fit: R_386_32 swapper_pg_dir arch/i386/kernel/kernel.o: In function `trap_init_f00f_bug': arch/i386/kernel/kernel.o(.text.init+0x844): relocation truncated to fit: R_386_32 idt_table arch/i386/kernel/kernel.o: In function `gdt_48': arch/i386/kernel/kernel.o(.data+0x1e13): relocation truncated to fit: R_386_32 gdt_table arch/i386/mm/mm.o: In function `__bad_page': arch/i386/mm/mm.o(.text+0x285): relocation truncated to fit: R_386_32 empty_bad_page kernel/kernel.o: In function `exit_mm': kernel/kernel.o(.text+0x8b07): relocation truncated to fit: R_386_32 swapper_pg_dir kernel/kernel.o: In function `do_exit': kernel/kernel.o(.text+0x8e79): relocation truncated to fit: R_386_32 swapper_pg_dir mm/mm.o: In function `zeromap_page_range': mm/mm.o(.text+0x609): relocation truncated to fit: R_386_32 empty_zero_page mm/mm.o: In function `do_anonymous_page': mm/mm.o(.text+0x1187): relocation truncated to fit: R_386_32 empty_zero_page I am invesigating it now. There is no time table for the next release. -- H.J. Lu (hjl@gnu.org) From hjl@lucon.org Sun Jun 6 17:57:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 06 Jun 1999 17:57:00 -0000 Subject: Binutils 2.9.4.0.2 is released. Message-ID: <19990607005742.BCA7357B7@ocean.lucon.org> Hi, binutils 2.9.4.0.2 seems ok. I can build Linux kernel and gcc with it now. -- H.J. Lu (hjl@gnu.org) --- This is the beta release of binutils 2.9.4.0.2 for Linux, which is based on binutils 1999 0606 plus various changes. Please report any bugs related to binutils 2.9.4.0.2 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.2.tar.gz. Source code. 2. binutils-2.9.4.0.1-2.9.4.0.2.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.1.0.25-2.9.4.0.2.diff.gz. Patch against binutils 2.9.1.0.25. 4. binutils-2.9.4.0.2-1.src.rpm. Source RPM. 5. binutils-2.9.4.0.2-1.i386.rpm. Binary RPM for RedHat 6.0. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/06/99 From aj@arthur.rhein-neckar.de Mon Jun 7 11:41:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 07 Jun 1999 11:41:00 -0000 Subject: fgetgrent broken with large groups Message-ID: The appended test program allocates all memory with large groups - and fails. One problem seems to be (debug just fgetgrent) that fgetgrent tries to read again from the stream and doesn't move the stream back. Andreas P.S.: Test program #include #include int main (void) { struct group *g; FILE *f; f = fopen("large-group","r"); while(1) { g = fgetgrent(f); if (!g) break; printf("%s: %d\n",g->gr_name,g->gr_gid); } return 0; } File large-group: root:x:0:root large:x:999:us000,us001,us002,us003,us004,us005,us006,us007,us008,us009,us010,us011,us012,us013,us014,us015,us016,us017,us018,us019,us020,us021,us022,us023,us024,us025,us026,us027,us028,us029,us030,us031,us032,us033,us034,us035,us036,us037,us038,us039,us040,us041,us042,us043,us044,us045,us046,us047,us048,us049,us050,us051,us052,us053,us054,us055,us056,us057,us058,us059,us060,us061,us062,us063,us064,us065,us066,us067,us068,us069,us070,us071,us072,us073,us074,us075,us076,us077,us078,us079,us080,us081,us082,us083,us084,us085,us086,us087,us088,us089,us090,us091,us092,us093,us094,us095,us096,us097,us098,us099,us100,us101,us102,us103,us104,us105,us106,us107,us108,us109,us110,us111,us112,us113,us114,us115,us116,us117,us118,us119,us120,us121,us122,us123,us124,us125,us126,us127,us128,us129,us130,us131,us132,us133,us134,us135,us136,us137,us138,us139,us140,us141,us142,us143,us144,us145,us146,us147,us148,us149,us150,us151,us152,us153,us154,us155,us156,us157,us158,us159,us160,us161,us162,u! s163,us164,us165,us166,us167,us168,us169,us170,us171,us172,us173,us174,us175,us176,us177,us178,us179,us180,us181,us182,us183,us184,us185,us186,us187,us188,us189,us190,us191,us192,us193,us194,us195,us196,us197,us198,us199,us200,us201,us202,us203,us204,us205,us206,us207,us208,us209,us210,us211,us212,us213,us214,us215,us216,us217,us218,us219,us220,us221,us222,us223,us224,us225,us226,us227,us228,us229,us230,us231,us232,us233,us234,us235,us236,us237,us238,us239,us240,us241,us242,us243,us244,us245,us246,us247,us248,us249,us250,us251,us252,us253,us254,us255,us256,us257,us258,us259,us260,us261,us262,us263,us264,us265,us266,us267,us268,us269,us270,us271,us272,us273,us274,us275,us276,us277,us278,us279,us280,us281,us282,us283,us284,us285,us286,us287,us288,us289,us290,us291,us292,us293,us294,us295,us296,us297,us298,us299,us300,us301,us302,us303,us304,us305,us306,us307,us308,us309,us310,us311,us312,us313,us314,us315,us316,us317,us318,us319,us320,us321,us322,us323,us324,us325,us326,us327,us! 328,us329,us330,us331,us332,us333,us334,us335,us336,us337,us338,us339,us340,us341,us342,us343,us344,us345,us346,us347,us348,us349,us350,us351,us352,us353,us354,us355,us356,us357,us358,us359,us360,us361,us362,us363,us364,us365,us366,us367,us368,us369,us370,us371,us372,us373,us374,us375,us376,us377,us378,us379,us380,us381,us382,us383,us384,us385,us386,us387,us388,us389,us390,us391,us392,us393,us394,us395,us396,us397,us398,us399,us400,us401,us402,us403,us404,us405,us406,us407,us408,us409,us410,us411,us412,us413,us414,us415,us416,us417,us418,us419,us420,us421,us422,us423,us424,us425,us426,us427,us428,us429,us430,us431,us432,us433,us434,us435,us436,us437,us438,us439,us440,us441,us442,us443,us444,us445,us446,us447,us448,us449,us450,us451,us452,us453,us454,us455,us456,us457,us458,us459,us460,us461,us462,us463,us464,us465,us466,us467,us468,us469,us470,us471,us472,us473,us474,us475,us476,us477,us478,us479,us480,us481,us482,us483,us484,us485,us486,us487,us488,us489,us490,us491,us492,us4! 93,us494,us495,us496,us497,us498,us499 test:x:1000 -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@lucon.org Mon Jun 7 15:31:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Mon, 07 Jun 1999 15:31:00 -0000 Subject: Binutils 2.9.4.0.3 is released. References: <99060614541000.00503@ns1102.munich.netsurf.de> Message-ID: <19990607223108.EBBD757B7@ocean.lucon.org> > > Hi, > > there are some problems with 2.9.4.0.1 on PPC. First, I can't compile > gcc-2.95pre anymore, cause your version contains the same bug as > current cvs-binutils. This bug is very new, it doesn't happen with a 990601 cvs > eabi > eabi.S: Assembler messages: > eabi.S:45: Internal error, aborting at symbols.c line 1625 in copy_symbol_attributes > Please report this bug. Please try binutils 2.9.4.0.3 and let me know what you get. Thanks. H.J. ---- This is the beta release of binutils 2.9.4.0.3 for Linux, which is based on binutils 1999 0607 plus various changes. Please report any bugs related to binutils 2.9.4.0.3 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.3.tar.gz. Source code. 2. binutils-2.9.4.0.2-2.9.4.0.3.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.3-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.3-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/07/99 From drepper@cygnus.com Mon Jun 7 20:20:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 07 Jun 1999 20:20:00 -0000 Subject: fgetgrent broken with large groups References: Message-ID: Andreas Jaeger writes: > The appended test program allocates all memory with large groups - and > fails. One problem seems to be (debug just fgetgrent) that fgetgrent > tries to read again from the stream and doesn't move the stream back. This is fixed now. Maybe you can make this into a regression test? Thanks, -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Mon Jun 7 23:16:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 07 Jun 1999 23:16:00 -0000 Subject: fgetgrent broken with large groups References: Message-ID: >>>>> Ulrich Drepper writes: Ulrich> Andreas Jaeger writes: >> The appended test program allocates all memory with large groups - and >> fails. One problem seems to be (debug just fgetgrent) that fgetgrent >> tries to read again from the stream and doesn't move the stream back. Ulrich> This is fixed now. Maybe you can make this into a regression test? Thanks! I'll make a test out of it. We should check whether similiar functions like fgetpwent are also broken. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Mon Jun 7 23:17:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 07 Jun 1999 23:17:00 -0000 Subject: fgetgrent broken with large groups References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> The appended test program allocates all memory with large groups - and >> fails. One problem seems to be (debug just fgetgrent) that fgetgrent >> tries to read again from the stream and doesn't move the stream back. Uli> This is fixed now. Maybe you can make this into a regression test? Appended - and it shows one bug in the last iteration. Andreas --- grp/Makefile.~1~ Sun Mar 21 14:05:19 1999 +++ grp/Makefile Tue Jun 8 08:11:08 1999 @@ -26,7 +26,7 @@ getgrent getgrgid getgrnam putgrent \ getgrent_r getgrgid_r getgrnam_r fgetgrent_r -tests := testgrp +tests := testgrp tst_fgetgrent include ../Rules 1999-06-08 Andreas Jaeger * grp/Makefile (tests): Add tst_fgetgrent. * grp/tst_fgetgrent: New test. /* Copyright (C) 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Andreas Jaeger , 1999. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include #include #include #include static int errors; static void write_users (FILE *f, int large_pos, int pos) { int i; if (pos == large_pos) { /* we need more than 2048 bytes for proper testing. */ for (i = 0; i < 500; i++) fprintf (f, ",user%03d", i); } fprintf (f, "\n"); } static void write_group (const char *filename, int pos) { FILE *f; f = fopen (filename, "w"); fprintf (f, "one:x:0:one"); write_users (f, pos, 1); fprintf (f, "two:x:1:two"); write_users (f, pos, 2); fprintf (f, "three:x:2"); write_users (f, pos, 3); fclose (f); } static void test_entry (const char *name, gid_t gid, struct group *g) { if (!g) { printf ("Error: Entry is empty\n"); errors++; return; } if ((g->gr_gid == gid) && (strcmp (g->gr_name, name) == 0)) printf ("Ok: %s: %d\n", g->gr_name, g->gr_gid); else { printf ("Error: %s: %d should be: %s: %d\n", g->gr_name, g->gr_gid, name, gid); errors++; } } static void test_fgetgrent (const char *filename) { struct group *g; FILE *f; f = fopen (filename,"r"); g = fgetgrent (f); test_entry ("one", 0, g); g = fgetgrent (f); test_entry ("two", 1, g); g = fgetgrent (f); test_entry ("three", 2, g); fclose (f); } int main (void) { char *file = tmpnam (NULL); int i; for (i = 0; i < 4; i++) { printf ("Pass %d\n", i); write_group (file, i); test_fgetgrent (file); } remove (file); return (errors != 0); } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Tue Jun 8 21:25:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 08 Jun 1999 21:25:00 -0000 Subject: BSD copyright Message-ID: Hi, Those of you who receive CVS logs have probably already seen that I checked in a whole bunch of changes. The background is the the UCB agreed to drop the advertising clause. RMS told me about this and ask me to remove it from all effected files. And so I did now. At least I hope I caught all files. If one is missing please let me know. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Thu Jun 10 10:17:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Thu, 10 Jun 1999 10:17:00 -0000 Subject: test_ifindex, current CVS glibc && Linux 2.3.5 Message-ID: As some probably noticed, ifindex is broken in glibc 2.1.1 with Linux 2.3.5. The recent changes of Ulrich seems to have fixed this - but let's look closer: I compiled the current glibc CVS version on Linux 2.2.10pre3 and inet/test_ifindex.out contains these 5 lines: Idx Name | Idx Name 1 lo | 1 lo okay 1 lo:0 | 1 lo okay 2 isdn1 | 2 isdn1 okay 3 isdn4 | 3 isdn4 okay Booting to Linux 2.3.5, I rerun the tests and got only these two lines: Idx Name | Idx Name 1 lo | 1 lo okay netstat -i shows me that all four interfaces are available: Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg isdn1 1500 0 48 0 0 0 46 0 0 0 OPRU isdn4 1500 0 0 0 0 0 0 0 0 0 OPRU lo 3924 0 543 0 0 0 543 0 0 0 LRU lo:0 3924 0 - no statistics available - LRU But test_ifindex only reports the first one :-(. Is this a kernel bug (Linux 2.3.5 on i486) or a bug in glibc? Is this only a problem on my system or can others running Linux 2.3.5 or newer reproduce it? Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Thu Jun 10 10:25:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 10 Jun 1999 10:25:00 -0000 Subject: test_ifindex, current CVS glibc && Linux 2.3.5 References: Message-ID: Andreas Jaeger writes: > But test_ifindex only reports the first one :-(. Is this a kernel bug > (Linux 2.3.5 on i486) or a bug in glibc? Is this only a problem on my > system or can others running Linux 2.3.5 or newer reproduce it? No, I see the same problem. I'll look into this later today. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Fri Jun 11 00:32:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Fri, 11 Jun 1999 00:32:00 -0000 Subject: test_ifindex, current CVS glibc && Linux 2.3.5 References: <199906101729.KAA10842@pizda.davem.net> Message-ID: >>>>> David S Miller writes: > From: Andreas Jaeger > Date: 10 Jun 1999 19:11:38 +0200 > But test_ifindex only reports the first one :-(. Is this a kernel > bug (Linux 2.3.5 on i486) or a bug in glibc? Is this only a > problem on my system or can others running Linux 2.3.5 or newer > reproduce it? > Technically it's a kernel bug, and since the result seems that I've > changed an API, I'm going to fix it. Hi Dave, you made in net/ipv4/devinet.c the following change: - struct ifreq ifr; + struct ifreq *ifr = (struct ifreq *) buf; Looking at the code you've got to change the sizeof calculations also: --- net/ipv4/devinet.c.~1~ Thu Jun 10 07:54:44 1999 +++ net/ipv4/devinet.c Fri Jun 11 09:17:34 1999 @@ -615,10 +615,10 @@ for ( ; ifa; ifa = ifa->ifa_next) { if (!ifr) { - done += sizeof(ifr); + done += sizeof(struct ifreq); continue; } - if (len < (int) sizeof(ifr)) + if (len < (int) sizeof(struct ifreq)) return done; memset(ifr, 0, sizeof(struct ifreq)); if (ifa->ifa_label) This should fix the if_index bug I've reported. ifc_len is set to 16 for my four interfaces - and sizeof (ifr) is 4 on my i486. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@lucon.org Fri Jun 11 07:53:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 11 Jun 1999 07:53:00 -0000 Subject: binutils 2.9.4.0.4 is released. Message-ID: <19990611145312.988D657B7@ocean.lucon.org> Sparc32 bug should be fixed in this release. -- H.J. Lu (hjl@gnu.org) --- This is the beta release of binutils 2.9.4.0.4 for Linux, which is based on binutils 1999 0611 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.4.0.4 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.4.tar.gz. Source code. 2. binutils-2.9.4.0.3-2.9.4.0.4.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.4-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.4-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/11/99 From hjl@lucon.org Sat Jun 12 12:28:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 12 Jun 1999 12:28:00 -0000 Subject: binutils 2.9.4.0.5 is released. Message-ID: <19990612192820.8520C57B9@ocean.lucon.org> This is the beta release of binutils 2.9.4.0.5 for Linux, which is based on binutils 1999 0612 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.4.0.5 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.5.tar.gz. Source code. 2. binutils-2.9.4.0.4-2.9.4.0.5.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.5-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.5-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/12/99 From drepper@cygnus.com Sun Jun 13 00:47:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 13 Jun 1999 00:47:00 -0000 Subject: what's new Message-ID: I just want to share this with you drepper@myware glibc-devel-19990607$ libio/tst_wprintf Hello world! I.e., I have wide character streams (at least output) working now. I hope to check all the code in next week but want to merge all needed changes since 2.1. into the release branch first. If somebody has the time to produce this patch I'd appreciate this. I'll probably not have the time since wide char stream input is waiting for me to debug it. Let me know when you have time (shouldn't take long). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Sun Jun 13 07:32:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 13 Jun 1999 07:32:00 -0000 Subject: what's new References: Message-ID: >>>>> Ulrich Drepper writes: > I just want to share this with you > drepper@myware glibc-devel-19990607$ libio/tst_wprintf > Hello world! Congratulations! > I.e., I have wide character streams (at least output) working now. I > hope to check all the code in next week but want to merge all needed > changes since 2.1. into the release branch first. If somebody has the > time to produce this patch I'd appreciate this. I'll probably not > have the time since wide char stream input is waiting for me to debug > it. Let me know when you have time (shouldn't take long). I'm appending a patch. I ask the port maintainers to check that I didn't miss one of their important patches since I've only added everything that's looked important to me;-). Please note that I did not check the patches (i.e. if they compile). I ask others with faster machines to do so. Andreas 1999-06-12 Ulrich Drepper * locale/lc-time.c: Add free_mem function to free if necessary statically allocated memory. 1999-06-10 Jakub Jelinek * sysdeps/libm-ieee754/s_truncl.c: Subtract exponent bias from the raw exponent. 1999-06-11 Ulrich Drepper * inet/arpa/tftp.h: Move attribute declaration in right position. 1999-06-11 Ulrich Drepper * resolv/nss_dns/dns-host.c (getanswer_r): Correctly track usage of user-provided buffer. 1999-06-10 Ulrich Drepper * stdio-common/printf-parse.h (parse_one_spec): Add support for a and A format. * shadow/fgetspent_r.c (__fgetspent_r): Set errno to ENOENT for returning after last entry. * pwd/fgetpwent_r.c (__fgetpwent_r): Likewise. 1999-06-09 Ulrich Drepper * pwd/fgetpwent_r.c: Set errno in the correct way. * shadow/fgetspent_r.c: Likewise. * pwd/fgetpwent.c: Handle long lines correctly. Little optimizations. Free static buffer when debugging memory handling. * shadow/fgetspent.c: Likewise. * grp/fgetgrent.c: Little optimization in loop. 1999-06-09 Jakub Jelinek * stdlib/longlong.h: gas changed sethi handling when without %hi(). Fix assembly. 1999-06-08 Ulrich Drepper * misc/daemon.c: Call fork. * grp/fgetgrent.c (buffer): Make file local variable. (free_mem): New function. Call for malloc debugging. 1999-06-08 Ulrich Drepper * ctype/ctype.h: Protect __tobody code by __extension__. 1999-06-13 Andreas Jaeger * sysdeps/unix/sysv/linux/if_index.c: Replace SIOG* with SIOCG*. 1999-06-07 Ulrich Drepper * sysdeps/unix/sysv/linux/sys/sysmacros.h (makedev): Handle signed parameters. 1999-06-06 Ulrich Drepper * sysdeps/unix/sysv/linux/i386/sigaction.c: Correct restorer function handling. * sysdeps/unix/sysv/linux/i386/sigaction.c (SA_RESTORER): New #define. 1999-06-06 Andi Kleen * sysdeps/unix/sysv/linux/i386/sigaction.c (__sigaction): Set SA_RESTORER flag. 1999-06-05 Philip Blundell * sysdeps/arm/dl-machine.h (elf_machine_load_address): Fix problems with GOT addressing. 1999-06-02 Jakub Jelinek * stdlib/longlong.h: Define UDIV_TIME on sparc64. 1999-06-01 Andreas Jaeger * sysdeps/unix/sysv/linux/net/if_arp.h (ARPHRD_DDCMP): Add it (from Linux 2.3.4). 1999-05-30 Andreas Jaeger * manual/stdio.texi: Fix some typos. 1999-05-29 Andreas Jaeger * manual/stdio.texi (Formatted Output Functions): Mention semantics of snprintf in glibc 2.0. Reported by Ben Pfaff . 1999-05-27 Andreas Schwab * malloc/malloc.h: Properly handle future GCC versions. 1999-05-25 Ulrich Drepper * sysdeps/posix/getcwd.c (__getcwd): Fix potential memory leaks. ============================================================ Index: locale/lc-time.c --- locale/lc-time.c 1997/06/21 01:23:14 1.4 +++ locale/lc-time.c 1999/06/13 14:22:13 @@ -1,5 +1,5 @@ /* Define current locale data for LC_TIME category. - Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc. + Copyright (C) 1995, 1996, 1997, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -174,3 +174,16 @@ return result; } + + +/* Free all resources if necessary. */ +static void __attribute__ ((unused)) +free_mem (void) +{ + if (eras != NULL) + free (eras); + if (alt_digits != NULL) + free (alt_digits); +} + +text_set_element (__libc_subfreeres, free_mem); ============================================================ Index: sysdeps/libm-ieee754/s_truncl.c --- sysdeps/libm-ieee754/s_truncl.c 1997/03/22 15:58:30 1.1 +++ sysdeps/libm-ieee754/s_truncl.c 1999/06/13 14:22:13 @@ -1,5 +1,5 @@ /* Truncate argument to nearest integral value not larger than the argument. - Copyright (C) 1997 Free Software Foundation, Inc. + Copyright (C) 1997, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Ulrich Drepper , 1997. @@ -32,7 +32,7 @@ GET_LDOUBLE_WORDS (se, i0, i1, x); sx = se & 0x8000; - j0 = se & 0x7fff; + j0 = (se & 0x7fff) - 0x3fff; if (j0 < 31) { if (j0 < 0) ============================================================ Index: inet/arpa/tftp.h --- inet/arpa/tftp.h 1999/05/17 16:47:48 1.6 +++ inet/arpa/tftp.h 1999/06/13 14:22:14 @@ -56,7 +52,7 @@ unsigned short tu_block; /* block # */ short tu_code; /* error code */ char tu_stuff[1]; /* request packet stuff */ - } th_u __attribute__ ((__packed__)); + } __attribute__ ((__packed__)) th_u; char th_data[1]; /* data or error string */ } __attribute__ ((__packed__)); ============================================================ Index: resolv/nss_dns/dns-host.c --- resolv/nss_dns/dns-host.c 1999/02/06 23:57:37 1.14 +++ resolv/nss_dns/dns-host.c 1999/06/13 14:22:16 @@ -323,6 +323,15 @@ int (*name_ok) __P ((const char *)); u_char packtmp[NS_MAXCDNAME]; + if (linebuflen < 0) + { + /* The buffer is too small. */ + too_small: + *errnop = ERANGE; + *h_errnop = NETDB_INTERNAL; + return NSS_STATUS_TRYAGAIN; + } + tname = qname; result->h_name = NULL; end_of_message = answer->buf + anslen; @@ -358,11 +367,7 @@ if (n != -1 && __ns_name_ntop (packtmp, bp, linebuflen) == -1) { if (errno == EMSGSIZE) - { - *errnop = ERANGE; - *h_errnop = NETDB_INTERNAL; - return NSS_STATUS_TRYAGAIN; - } + goto too_small; n = -1; } @@ -393,6 +398,8 @@ result->h_name = bp; bp += n; linebuflen -= n; + if (linebuflen < 0) + goto too_small; /* The qname can be abbreviated, but h_name is now absolute. */ qname = result->h_name; } @@ -606,6 +613,7 @@ linebuflen -= nn; } + linebuflen -= sizeof (align) - ((u_long) bp % sizeof (align)); bp += sizeof (align) - ((u_long) bp % sizeof (align)); if (n >= linebuflen) ============================================================ Index: stdio-common/printf-parse.h --- stdio-common/printf-parse.h 1998/07/31 11:12:46 1.12 +++ stdio-common/printf-parse.h 1999/06/13 14:22:17 @@ -1,5 +1,5 @@ /* Internal header for parsing printf format strings. - Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc. + Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of th GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -358,6 +358,8 @@ case L'f': case L'g': case L'G': + case L'a': + case L'A': if (spec->info.is_long_double) spec->data_arg_type = PA_DOUBLE|PA_FLAG_LONG_DOUBLE; else ============================================================ Index: shadow/fgetspent_r.c --- shadow/fgetspent_r.c 1998/08/08 19:45:56 1.10 +++ shadow/fgetspent_r.c 1999/06/13 14:22:17 @@ -1,4 +1,4 @@ -/* Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc. +/* Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -53,13 +53,15 @@ { funlockfile (stream); *result = NULL; + __set_errno (ENOENT); return errno; } if (p == NULL || buffer[buflen - 1] != '\xff') { funlockfile (stream); *result = NULL; - return errno = ERANGE; + __set_errno (ERANGE); + return errno; } /* Skip leading blanks. */ ============================================================ Index: shadow/fgetspent.c --- shadow/fgetspent.c 1997/06/21 01:28:10 1.5 +++ shadow/fgetspent.c 1999/06/13 14:22:17 @@ -1,4 +1,4 @@ -/* Copyright (C) 1996, 1997 Free Software Foundation, Inc. +/* Copyright (C) 1996, 1997, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -28,16 +29,21 @@ /* We need to protect the dynamic buffer handling. */ __libc_lock_define_initialized (static, lock); +static char *buffer; + /* Read one shadow entry from the given stream. */ struct spwd * fgetspent (FILE *stream) { - static char *buffer; static size_t buffer_size; static struct spwd resbuf; + fpos_t pos; struct spwd *result; int save; + if (fgetpos (stream, &pos) != 0) + return NULL; + /* Get lock. */ __libc_lock_lock (lock); @@ -49,8 +55,8 @@ } while (buffer != NULL - && __fgetspent_r (stream, &resbuf, buffer, buffer_size, &result) != 0 - && errno == ERANGE) + && (__fgetspent_r (stream, &resbuf, buffer, buffer_size, &result) + == ERANGE)) { char *new_buf; buffer_size += BUFLEN_SPWD; @@ -64,6 +70,10 @@ __set_errno (save); } buffer = new_buf; + + /* Reset the stream. */ + if (fsetpos (stream, &pos) != 0) + buffer = NULL; } if (buffer == NULL) @@ -76,3 +86,14 @@ return result; } + + +/* Free all resources if necessary. */ +static void __attribute__ ((unused)) +free_mem (void) +{ + if (buffer != NULL) + free (buffer); +} + +text_set_element (__libc_subfreeres, free_mem); ============================================================ Index: pwd/fgetpwent_r.c --- pwd/fgetpwent_r.c 1998/08/08 19:44:22 1.10 +++ pwd/fgetpwent_r.c 1999/06/13 14:22:17 @@ -1,4 +1,4 @@ -/* Copyright (C) 1991, 1996, 1997, 1998 Free Software Foundation, Inc. +/* Copyright (C) 1991, 1996, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -86,13 +86,15 @@ { funlockfile (stream); *result = NULL; + __set_errno (ENOENT); return errno; } if (p == NULL || buffer[buflen - 1] != '\xff') { funlockfile (stream); *result = NULL; - return errno = ERANGE; + __set_errno (ERANGE); + return errno; } /* Skip leading blanks. */ ============================================================ Index: grp/fgetgrent.c --- grp/fgetgrent.c 1999/06/07 20:18:31 1.10.2.1 +++ grp/fgetgrent.c 1999/06/13 14:22:17 @@ -26,11 +26,12 @@ /* We need to protect the dynamic buffer handling. */ __libc_lock_define_initialized (static, lock); +static char *buffer; + /* Read one entry from the given stream. */ struct group * fgetgrent (FILE *stream) { - static char *buffer; static size_t buffer_size; static struct group resbuf; fpos_t pos; @@ -85,3 +86,14 @@ return result; } + + +/* Free all resources if necessary. */ +static void __attribute__ ((unused)) +free_mem (void) +{ + if (buffer != NULL) + free (buffer); +} + +text_set_element (__libc_subfreeres, free_mem); ============================================================ Index: stdlib/longlong.h --- stdlib/longlong.h 1999/05/25 16:50:26 1.11.2.1 +++ stdlib/longlong.h 1999/06/13 14:22:18 @@ -1220,7 +1220,7 @@ srlx %7,32,%5 mulx %3,%5,%3 mulx %2,%5,%5 - sethi 0x80000000,%2 + sethi %%hi(0x80000000),%2 addcc %4,%3,%4 srlx %4,32,%4 add %2,%2,%2 @@ -1237,6 +1237,7 @@ : "cc"); \ } while (0) #define UMUL_TIME 96 +#define UDIV_TIME 230 #endif /* __sparc_v9__ */ #if defined (__vax__) && W_TYPE_SIZE == 32 ============================================================ Index: misc/daemon.c --- misc/daemon.c 1998/07/16 10:57:08 1.2 +++ misc/daemon.c 1999/06/13 14:22:18 @@ -45,7 +45,7 @@ { int fd; - switch (__fork()) { + switch (fork()) { case -1: return (-1); case 0: ============================================================ Index: ctype/ctype.h --- ctype/ctype.h 1999/05/24 16:20:49 1.28 +++ ctype/ctype.h 1999/06/13 14:22:19 @@ -165,20 +165,21 @@ #if __GNUC__ >= 2 && defined __OPTIMIZE__ && !defined __cplusplus # define __tobody(c, f, a) \ - ({ int __res; \ - if (sizeof (c) > 1) \ - { \ - if (__builtin_constant_p (c)) \ - { \ - int __c = (c); \ - __res = __c < -128 || __c > 255 ? __c : a[__c]; \ - } \ - else \ - __res = f (c); \ - } \ - else \ - __res = a[(int) (c)]; \ - __res; }) + (__extension__ \ + ({ int __res; \ + if (sizeof (c) > 1) \ + { \ + if (__builtin_constant_p (c)) \ + { \ + int __c = (c); \ + __res = __c < -128 || __c > 255 ? __c : a[__c]; \ + } \ + else \ + __res = f (c); \ + } \ + else \ + __res = a[(int) (c)]; \ + __res; })) # define tolower(c) __tobody (c, tolower, __ctype_tolower) # define toupper(c) __tobody (c, toupper, __ctype_toupper) ============================================================ Index: sysdeps/unix/sysv/linux/if_index.c --- sysdeps/unix/sysv/linux/if_index.c 1999/04/28 23:04:24 1.14 +++ sysdeps/unix/sysv/linux/if_index.c 1999/06/13 14:22:19 @@ -27,7 +27,7 @@ #include /* Try to get a socket to talk to the kernel. */ -#if defined SIOGIFINDEX || defined SIOGIFNAME +#if defined SIOCGIFINDEX || defined SIOCGIFNAME static int internal_function opensock (void) @@ -71,7 +71,7 @@ unsigned int if_nametoindex (const char *ifname) { -#ifndef SIOGIFINDEX +#ifndef SIOCGIFINDEX __set_errno (ENOSYS); return 0; #else @@ -82,7 +82,7 @@ return 0; strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name)); - if (__ioctl (fd, SIOGIFINDEX, &ifr) < 0) + if (__ioctl (fd, SIOCGIFINDEX, &ifr) < 0) { int saved_errno = errno; __close (fd); @@ -111,7 +111,7 @@ struct if_nameindex * if_nameindex (void) { -#ifndef SIOGIFINDEX +#ifndef SIOCGIFINDEX __set_errno (ENOSYS); return NULL; #else @@ -172,7 +172,7 @@ struct ifreq *ifr = &ifc.ifc_req[i]; idx[i].if_name = __strdup (ifr->ifr_name); if (idx[i].if_name == NULL - || __ioctl (fd, SIOGIFINDEX, ifr) < 0) + || __ioctl (fd, SIOCGIFINDEX, ifr) < 0) { int saved_errno = errno; unsigned int j; @@ -199,7 +199,7 @@ char * if_indextoname (unsigned int ifindex, char *ifname) { -#ifndef SIOGIFINDEX +#ifndef SIOCGIFINDEX __set_errno (ENOSYS); return NULL; #else @@ -207,14 +207,14 @@ struct if_nameindex *p; char *result = NULL; -#ifdef SIOGIFNAME +#ifdef SIOCGIFNAME /* We may be able to do the conversion directly, rather than searching a list. This ioctl is not present in kernels before version 2.1.50. */ struct ifreq ifr; int fd; - static int siogifname_works_not; + static int siocgifname_works_not; - if (!siogifname_works_not) + if (!siocgifname_works_not) { int serrno = errno; @@ -224,10 +224,10 @@ return NULL; ifr.ifr_ifindex = ifindex; - if (__ioctl (fd, SIOGIFNAME, &ifr) < 0) + if (__ioctl (fd, SIOCGIFNAME, &ifr) < 0) { if (errno == EINVAL) - siogifname_works_not = 1; /* Don't make the same mistake twice. */ + siocgifname_works_not = 1; /* Don't make the same mistake twice. */ } else { ============================================================ Index: sysdeps/unix/sysv/linux/sys/sysmacros.h --- sysdeps/unix/sysv/linux/sys/sysmacros.h 1999/01/21 14:28:43 1.7 +++ sysdeps/unix/sysv/linux/sys/sysmacros.h 1999/06/13 14:22:19 @@ -27,11 +27,13 @@ #if defined __GNUC__ && __GNUC__ >= 2 # define major(dev) ((int)(((dev) >> 8) & 0xff)) # define minor(dev) ((int)((dev) & 0xff)) -# define makedev(major, minor) (((major) << 8) | (minor)) +# define makedev(major, minor) ((((unsigned int) (major)) << 8) \ + | ((unsigned int) (minor))) #else # define major(dev) (((dev).__val[0] >> 8) & 0xff) # define minor(dev) ((dev).__val[0] & 0xff) -# define makedev(major, minor) { (((major) << 8) | (minor)), 0 } +# define makedev(major, minor) { ((((unsigned int) (major)) << 8) \ + | ((unsigned int) (minor))), 0 } #endif #endif /* sys/sysmacros.h */ ============================================================ Index: sysdeps/unix/sysv/linux/i386/sigaction.c --- sysdeps/unix/sysv/linux/i386/sigaction.c 1998/10/31 10:28:07 1.15 +++ sysdeps/unix/sysv/linux/i386/sigaction.c 1999/06/13 14:22:19 @@ -1,5 +1,5 @@ /* POSIX.1 `sigaction' call for Linux/i386. - Copyright (C) 1991, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. + Copyright (C) 1991, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -30,6 +30,8 @@ translate it here. */ #include +/* We do not globally define the SA_RESTORER flag so do it here. */ +#define SA_RESTORER 0x04000000 extern int __syscall_rt_sigaction (int, const struct kernel_sigaction *, struct kernel_sigaction *, size_t); @@ -38,6 +40,8 @@ functions which have RT equivalents. */ int __libc_missing_rt_sigs; +static void restore_rt (void) asm ("__restore_rt"); +static void restore (void) asm ("__restore"); /* If ACT is not NULL, change the action for SIG to *ACT. If OACT is not NULL, put the old action for SIG in *OACT. */ @@ -58,10 +62,10 @@ { kact.k_sa_handler = act->sa_handler; memcpy (&kact.sa_mask, &act->sa_mask, sizeof (sigset_t)); - kact.sa_flags = act->sa_flags; + kact.sa_flags = act->sa_flags | SA_RESTORER; - kact.sa_restorer = ((act->sa_flags & SA_NOMASK) - ? &&restore_nomask : &&restore); + kact.sa_restorer = ((act->sa_flags & SA_SIGINFO) + ? &restore_rt : &restore); } /* XXX The size argument hopefully will have to be changed to the @@ -90,10 +94,9 @@ { k_newact.k_sa_handler = act->sa_handler; k_newact.sa_mask = act->sa_mask.__val[0]; - k_newact.sa_flags = act->sa_flags; + k_newact.sa_flags = act->sa_flags | SA_RESTORER; - k_newact.sa_restorer = ((act->sa_flags & SA_NOMASK) - ? &&restore_nomask : &&restore); + k_newact.sa_restorer = &restore; } asm volatile ("pushl %%ebx\n" @@ -119,41 +122,33 @@ } return 0; - - restore: - asm ( -#ifdef PIC - " pushl %%ebx\n" - " call 0f\n" - "0: popl %%ebx\n" - " addl $_GLOBAL_OFFSET_TABLE_+[.-0b], %%ebx\n" - " addl $8, %%esp\n" - " call __sigsetmask@PLT\n" - " addl $8, %%esp\n" - " popl %%ebx\n" -#else - " addl $4, %%esp\n" - " call __sigsetmask\n" - " addl $4, %%esp\n" -#endif - " popl %%eax\n" - " popl %%ecx\n" - " popl %%edx\n" - " popf\n" - " ret" - : : ); - - restore_nomask: - asm (" addl $4, %%esp\n" - " popl %%eax\n" - " popl %%ecx\n" - " popl %%edx\n" - " popf\n" - " ret" - : : ); - - /* NOTREACHED */ - return -1; } weak_alias (__sigaction, sigaction) + +#define RESTORE(name, syscall) RESTORE2 (name, syscall) +#define RESTORE2(name, syscall) \ +asm \ + ( \ + ".align 16\n" \ + "__" #name ":\n" \ + " movl $" #syscall ", %eax\n" \ + " int $0x80" \ + ); + +/* The return code for realtime-signals. */ +RESTORE (restore_rt, __NR_rt_sigreturn) + +/* For the boring old signals. */ +# undef RESTORE2 +# define RESTORE2(name, syscall) \ +asm \ + ( \ + ".align 8\n" \ + "__" #name ":\n" \ + " popl %eax\n" \ + " movl $" #syscall ", %eax\n" \ + " int $0x80" \ + ); + +RESTORE (restore, __NR_sigreturn) ============================================================ Index: sysdeps/arm/dl-machine.h --- sysdeps/arm/dl-machine.h 1999/03/02 08:06:57 1.12 +++ sysdeps/arm/dl-machine.h 1999/06/13 14:22:20 @@ -52,22 +52,14 @@ /* Return the run-time load address of the shared object. */ -// patb static inline Elf32_Addr __attribute__ ((unused)) elf_machine_load_address (void) { - Elf32_Addr addr; - asm (" ldr ip,.L1 - ldr r3,.L3 - add r3, r3, sl - ldr ip,[sl, ip] - sub ip, r3, ip - b .L2 - .L1: .word _dl_start(GOT) - .L3: .word _dl_start(GOTOFF) - .L2: mov %0, ip" - : "=r" (addr) : : "ip", "r3"); - return addr; + extern void __dl_start asm ("_dl_start"); + Elf32_Addr got_addr = (Elf32_Addr) &__dl_start; + Elf32_Addr pcrel_addr; + asm ("adr %0, _dl_start" : "=r" (pcrel_addr)); + return pcrel_addr - got_addr; } ============================================================ Index: manual/stdio.texi --- manual/stdio.texi 1999/03/10 16:04:31 1.97 +++ manual/stdio.texi 1999/06/13 14:22:27 @@ -1616,6 +1616,12 @@ @end smallexample In practice, it is often easier just to use @code{asprintf}, below. + +@strong{Attention:} In the GNU C library version 2.0 the return value +is the number of characters stored, not including the terminating null. +If this value equals @code{@var{size} - 1}, then there was not enough +space in @var{s} for all the output. This change was necessary with +the adoption of snprintf by ISO C9x. @end deftypefun @node Dynamic Output @@ -2205,7 +2211,7 @@ Now let's look at how to define the handler and arginfo functions which are passed as arguments to @code{register_printf_function}. -@strong{Compatibility Note:} The interface change in the GNU libc +@strong{Compatibility Note:} The interface changed in the GNU libc version 2.0. Previously the third argument was of type @code{va_list *}. @@ -4347,7 +4353,7 @@ produced no output since the class with the numeric value @code{6} is not defined. Although a class with numeric value @code{5} is also not defined by default, the call the @code{addseverity} introduces it and -the second call to @code{fmtmsg} produces the above outout. +the second call to @code{fmtmsg} produces the above output. When we change the environment of the program to contain @code{SEV_LEVEL=XXX,6,NOTE} when running it we get a different result: ============================================================ Index: sysdeps/unix/sysv/linux/net/if_arp.h --- sysdeps/unix/sysv/linux/net/if_arp.h 1999/03/29 00:54:14 1.9 +++ sysdeps/unix/sysv/linux/net/if_arp.h 1999/06/13 14:22:27 @@ -92,6 +92,7 @@ #define ARPHRD_PPP 512 #define ARPHRD_HDLC 513 /* (Cisco) HDLC. */ #define ARPHRD_LAPB 516 /* LAPB. */ +#define ARPHRD_DDCMP 517 /* Digital's DDCMP. */ #define ARPHRD_TUNNEL 768 /* IPIP tunnel. */ #define ARPHRD_TUNNEL6 769 /* IPIP6 tunnel. */ ============================================================ Index: malloc/malloc.h --- malloc/malloc.h 1999/05/23 13:01:33 1.11 +++ malloc/malloc.h 1999/06/13 14:22:28 @@ -60,7 +60,7 @@ /* GCC can always grok prototypes. For C++ programs we add throw() to help it optimize the function calls. But this works only with gcc 2.8.x and egcs. */ -# if defined __cplusplus && __GNUC_MINOR__ >= 8 +# if defined __cplusplus && (__GNUC__ >= 3 || __GNUC_MINOR__ >= 8) # define __THROW throw () # else # define __THROW ============================================================ Index: sysdeps/posix/getcwd.c --- sysdeps/posix/getcwd.c 1998/10/18 15:34:15 1.34 +++ sysdeps/posix/getcwd.c 1999/06/13 14:22:28 @@ -1,4 +1,4 @@ -/* Copyright (C) 1991,92,93,94,95,96,97,98 Free Software Foundation, Inc. +/* Copyright (C) 1991,92,93,94,95,96,97,98,99 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -211,8 +211,9 @@ = "../../../../../../../../../../../../../../../../../../../../../../../\ ../../../../../../../../../../../../../../../../../../../../../../../../../../\ ../../../../../../../../../../../../../../../../../../../../../../../../../.."; - const char *dotp, *dotlist; - size_t dotsize; + const char *dotp = &dots[sizeof (dots)]; + const char *dotlist = dots; + size_t dotsize = sizeof (dots) - 1; dev_t rootdev, thisdev; ino_t rootino, thisino; char *path; @@ -244,18 +245,15 @@ *--pathp = '\0'; if (__lstat (".", &st) < 0) - return NULL; + goto lose2; thisdev = st.st_dev; thisino = st.st_ino; if (__lstat ("/", &st) < 0) - return NULL; + goto lose2; rootdev = st.st_dev; rootino = st.st_ino; - dotsize = sizeof (dots) - 1; - dotp = &dots[sizeof (dots)]; - dotlist = dots; while (!(thisdev == rootdev && thisino == rootino)) { register DIR *dirstream; @@ -273,7 +271,7 @@ { new = malloc (dotsize * 2 + 1); if (new == NULL) - return NULL; + goto lose; #ifdef HAVE_MEMPCPY dotp = mempcpy (new, dots, dotsize); #else @@ -375,7 +373,6 @@ if (tmp == NULL) { (void) __closedir (dirstream); - free (path); __set_errno (ENOMEM);/* closedir might have changed it.*/ goto lose; } @@ -412,6 +409,9 @@ lose: if (dotlist != dots) free ((__ptr_t) dotlist); + lose2: + if (buf == NULL) + free (path); return NULL; } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Sun Jun 13 09:25:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 13 Jun 1999 09:25:00 -0000 Subject: what's new References: Message-ID: Andreas Jaeger writes: > I'm appending a patch. I ask the port maintainers to check that I > didn't miss one of their important patches since I've only added > everything that's looked important to me;-). Thanks, I've checked the changes in. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Sun Jun 13 10:15:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 13 Jun 1999 10:15:00 -0000 Subject: [Itai Nahshon ] RedHat-6.0 fails to compile with -ansi -pedantic References: <199905260659.CAA20856@frob.com> Message-ID: >>>>> Roland McGrath writes: Roland> I'm not positive, but I think that using __extension__ here (after the =) Roland> would silence the warnings. But it's no real loss to just use plain C Roland> syntax there as the patch you forwarded does. I tried to add __extension__ and didn't succeed - instead I got a bunch of errors. Can you check this yourself, please? Here's again the problematic definition - and a patch to silent -ansi -pedantic -O2 (but gcc produces worse code with this): __MATH_INLINE int __signbitf (float __x) { - union { float __f; int __i; } __u = { __f: __x }; return __u.__i < 0; + union { float __f; int __i; } __u; __u.__f = __x; return __u.__i < 0; } Thanks, Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Sun Jun 13 10:46:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 13 Jun 1999 10:46:00 -0000 Subject: [Itai Nahshon ] RedHat-6.0 fails to compile with -ansi -pedantic References: <199905260659.CAA20856@frob.com> Message-ID: Andreas Jaeger writes: > Here's again the problematic definition - and a patch to silent > -ansi -pedantic -O2 (but gcc produces worse code with this): > __MATH_INLINE int > __signbitf (float __x) > { > - union { float __f; int __i; } __u = { __f: __x }; return __u.__i < 0; > + union { float __f; int __i; } __u; __u.__f = __x; return __u.__i < 0; > } __extension__ works for me. Maybe it's a gcc version thing. But then I don't care. If people want to use pedantic they have to use the right gcc version. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Sun Jun 13 10:57:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 13 Jun 1999 10:57:00 -0000 Subject: more on wide char streams Message-ID: I forgot to mention one thing: the wide char streams are only available in libio. I.e., Hurd won't get them until they switch over. I think the same is already true for LFS. Maybe somebody should think about doing this at some point. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Sun Jun 13 10:59:00 1999 From: roland@frob.com (Roland McGrath) Date: Sun, 13 Jun 1999 10:59:00 -0000 Subject: more on wide char streams References: Message-ID: <199906131759.NAA01112@frob.com> > I forgot to mention one thing: the wide char streams are only > available in libio. I.e., Hurd won't get them until they switch over. > I think the same is already true for LFS. Maybe somebody should think > about doing this at some point. It is already our plan to switch the Hurd to libio eventually. This is just one more reason among many. From aj@arthur.rhein-neckar.de Sun Jun 13 12:29:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 13 Jun 1999 12:29:00 -0000 Subject: [Itai Nahshon ] RedHat-6.0 fails to compile with -ansi -pedantic References: <199905260659.CAA20856@frob.com> Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> Here's again the problematic definition - and a patch to silent >> -ansi -pedantic -O2 (but gcc produces worse code with this): >> __MATH_INLINE int >> __signbitf (float __x) >> { >> - union { float __f; int __i; } __u = { __f: __x }; return __u.__i < 0; >> + union { float __f; int __i; } __u; __u.__f = __x; return __u.__i < 0; >> } Uli> __extension__ works for me. Maybe it's a gcc version thing. But then Uli> I don't care. If people want to use pedantic they have to use the Uli> right gcc version. I thought I've tried the patch you've made - but it works now for me with egcs 1.1.2 and gcc-2.95 current. The only problem is with gcc 2.7.2.3 - it complains about the extension and gives an internal compiler error :-(. We should add the appended patch to disable the macros. Please add this to both branches. Thanks, Andreas 1999-06-13 Andreas Jaeger * sysdeps/i386/fpu/bits/mathinline.h: Disable signbit* inline functions for gcc <= 2.7.x. --- sysdeps/i386/fpu/bits/mathinline.h.~1~ Sun Jun 13 20:44:34 1999 +++ sysdeps/i386/fpu/bits/mathinline.h Sun Jun 13 20:55:41 1999 @@ -110,6 +110,10 @@ __result; }) # endif /* __i686__ */ +/* The gcc, version 2.7 or below, has problems with all this inlining + code. So disable it for this version of the compiler. */ +# if defined __GNUC__ && (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ > 7)) + /* Test for negative number. Used in the signbit() macro. */ __MATH_INLINE int __signbitf (float __x) @@ -129,6 +133,7 @@ __extension__ union { long double __l; int __i[3]; } __u = { __l: __x }; return (__u.__i[2] & 0x8000) != 0; } +# endif #endif -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Mon Jun 14 01:09:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 14 Jun 1999 01:09:00 -0000 Subject: signbit in both libm and libc Message-ID: glibc 2.1 has __signbit* in both libm and libc. I guess we can remove signbit from libm - or would this break anything? Andreas 1999-06-14 Andreas Jaeger * math/Versions: Removed __signbit, __signbitf and __signbitl from libm since they're part of libc. * math/Makefile (libm-calls): Remove s_signbit since it's already in libc. --- math/Versions.~1~ Tue Jan 19 21:11:41 1999 +++ math/Versions Mon Jun 14 08:06:15 1999 @@ -151,6 +151,5 @@ # functions used in inline functions or macros __finite; __finitef; __finitel; __fpclassify; __fpclassifyf; __fpclassifyl; - __signbit; __signbitf; __signbitl; } } --- math/Makefile.~1~ Fri Mar 26 10:33:46 1999 +++ math/Makefile Mon Jun 14 08:05:11 1999 @@ -51,7 +51,7 @@ w_atan2 w_atanh w_cosh w_drem w_exp w_exp2 w_exp10 w_fmod \ w_tgamma w_hypot w_j0 w_j1 w_jn w_lgamma w_lgamma_r \ w_log w_log10 w_pow w_remainder w_scalb w_sinh w_sqrt \ - s_signbit s_fpclassify s_fmax s_fmin s_fdim s_nan s_trunc \ + s_fpclassify s_fmax s_fmin s_fdim s_nan s_trunc \ s_remquo s_log2 s_exp2 s_round s_nearbyint s_sincos \ conj cimag creal cabs carg s_cexp s_csinh s_ccosh s_clog \ s_catan s_casin s_ccos s_csin s_ctan s_ctanh s_cacos \ -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kettenis@wins.uva.nl Mon Jun 14 07:01:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Mon, 14 Jun 1999 07:01:00 -0000 Subject: DB 2.7.5 Message-ID: <199906141238.OAA00206@delius.kettenis.nl> I believe that I read on http:///www.sleepycat.com that a release with a different minor version number is not entirely compatible with previous versions. Therefore there may be compatibility problems caused by the update for 2.4.14 to 2.7.5. These incompatibilities range from changes to the format of the files on disk, via incompatibilities in the programming interface (which might break source compatibility), to true interface changes (which might break binary compatibility). There is a list of all these changes on the web-pages. Is this something we should worry about? Investigate? Or solve when actual problems come up? Mark From drepper@cygnus.com Mon Jun 14 08:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 14 Jun 1999 08:05:00 -0000 Subject: DB 2.7.5 References: <199906141238.OAA00206@delius.kettenis.nl> Message-ID: Mark Kettenis writes: > Is this something we should worry about? Investigate? Or solve when > actual problems come up? All I know is that older versions really had bugs. I'll talk to Keith what he suggests. They probably have to have a plan anyway. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gafton@redhat.com Tue Jun 15 16:15:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Tue, 15 Jun 1999 16:15:00 -0000 Subject: egcs 2.91.66 ix86 problems... Message-ID: I am going nuts over this issue, maybe someone can help me see the light here: In the info page for egcs it is documented: --- quote --- These `-m' options are defined for the i386 family of computers: `-mcpu=CPU TYPE' Assume the defaults for the machine type CPU TYPE when scheduling instructions. The choices for CPU TYPE are: `i386', `i486', `i586' (`pentium'), `pentium', `i686' (`pentiumpro') and `pentiumpro'. While picking a specific CPU TYPE will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the `-march=CPU TYPE' option being used. `-march=CPU TYPE' Generate instructions for the machine type CPU TYPE. The choices for CPU TYPE are: `i386', `i486', `pentium', and `pentiumpro'. Specifying `-march=CPU TYPE' implies `-mcpu=CPU TYPE'. `-m386' `-m486' `-mpentium' `-mpentiumpro' Synonyms for -mcpu=i386, -mcpu=i486, -mcpu=pentium, and -mcpu=pentiumpro respectively. --- endquote --- So after reading this thing one clearly gets the impression the saying -mcpu=i486 will affect the scheduler only, while egcs will still generate code that will run on i386, and -march=i486 will actually enable i486-specific instructions. Well, the cpp does not concur to this idea and because of this the glibc headers that are testing for __i486__ (like the ones that define bswap32 and bswap16) are getting confused. A common sense rule says that using -mcpu=i486 should *not* define __i486__, because we don't want to use i486 specific code, we are only interested in the scheduler modifications. but this is not true: shefu (gafton):~>gcc -dM -E -mcpu=i486 - < /dev/null #define __linux__ 1 #define linux 1 #define __i386__ 1 #define __i386 1 #define __i486 1 #define __GNUC_MINOR__ 91 #define __i486__ 1 #define i386 1 #define i486 1 #define __unix 1 #define __unix__ 1 #define __GNUC__ 2 #define __linux 1 #define __ELF__ 1 #define unix 1 The same rule, after reading the info page, says that __i486__ should get defined if we use -march=i486. But again, it does not get defined: shefu (gafton):~>gcc -dM -E -march=i486 - < /dev/null #define __linux__ 1 #define linux 1 #define __i386__ 1 #define __i386 1 #define __GNUC_MINOR__ 91 #define i386 1 #define __unix 1 #define __unix__ 1 #define __GNUC__ 2 #define __linux 1 #define __ELF__ 1 #define unix 1 As a result, ./sysdeps/i386/bits/byteswap.h is testing for __i486__ and because the cpp from egcs defines it when using -m486 it will pick the variant that is using bswap calls, which are not available on i386. So the claim that the code should continue to run i386 without problems is not true. Bottom line: people used to belive that compiling programs against glibc headers using -mcpu=i486 will generate code that will run on i386 or higher, but it will run fastest on pentium because of the optimized scheduler. Now this proves to be exactly the opposite: -mcpu=i486 will break things badly. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From drepper@cygnus.com Tue Jun 15 23:44:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 15 Jun 1999 23:44:00 -0000 Subject: stability and so Message-ID: Dudes, I plan to check in the wide character stream stuff soon. It works for the test cases I have so far and there should be no regressions in the single byte character streams. But nevertheless the library will not be fully functional for some time since I had to break the locale code to avoid ugly temporary hacks. All will work soon again as soon as I'm also able to check in the locale changes I have here. This might take one or two weeks (hopefully not longer). The consequence is that the mainline CVS version will not be usable for real life for some time. I don't think this is a problem but if somebody is of a different opinion speak up now. It's far too long that I had the changes only locally available here. I now need help with the testing and with documenting the new functions. This is where I hope you can help. We still have the 2.1 branch from which there will be a release as soon as I find the time so instability for some time shouldn't be a problem. OK? -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From schwab@issan.cs.uni-dortmund.de Wed Jun 16 04:43:00 1999 From: schwab@issan.cs.uni-dortmund.de (Andreas Schwab) Date: Wed, 16 Jun 1999 04:43:00 -0000 Subject: stability and so References: Message-ID: Ulrich Drepper writes: |> I plan to check in the wide character stream stuff soon. It works for |> the test cases I have so far and there should be no regressions in the |> single byte character streams. But nevertheless the library will not |> be fully functional for some time since I had to break the locale code |> to avoid ugly temporary hacks. IMHO go ahead and check in the wide character stuff. The sooner we can get hold of your changes the sooner we can find and fix the remaining bugs. That's what the developer's branch is for. Andreas. From drepper@cygnus.com Wed Jun 16 23:09:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 16 Jun 1999 23:09:00 -0000 Subject: wide char stream stuff is in Message-ID: I've checked in the few changes. Last time I compiled it (last night) it passed all tests. Please note that I have disabled the test for localedata. I've also added a warning printed at configure time. About the code: you will find a few new test cases. This is almost everything I've tested so far. At least as far as wide character streams are concerned. Byte streams are already tested quite well and all tests still pass. But be prepared for lots of bugs in the wide char stuff, especially since the tests passed the first time I ran them. This is always suspecious. There are also some parts which are not yet implemented or known to be broken. *Please* write lots of tests and maybe even fix the problems. It's not hard. The concept of wide char streams is easy: you have two levels of buffers. For wide char streams there is an additional level. The first level buffers are filled just like before. The second level is filled from the first by conversion functions. These functions are kept in a codecvt structure. This one comes directly from ISO C++. The reason is simple: the same implementation will be used in libstdc++. For output the opposite work is done, of course. Untested or with known problems is especially seeking and syncing of wide character streams. Also things like linebuffering must be tested. I really would like the testing work for the first time up to you since I have the locale stuff to finish. It's critical to get this also in place so that we can start testing it all together. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From geoffk@ozemail.com.au Thu Jun 17 00:58:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Thu, 17 Jun 1999 00:58:00 -0000 Subject: egcs 2.91.66 ix86 problems... References: Message-ID: <199906170315.NAA00566@geoffk.wattle.id.au> > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > Date: Tue, 15 Jun 1999 19:09:26 -0400 (EDT) > From: Cristian Gafton > > > I am going nuts over this issue, maybe someone can help me see the light > here: ... > So after reading this thing one clearly gets the impression the saying > -mcpu=i486 will affect the scheduler only, while egcs will still generate > code that will run on i386, and -march=i486 will actually enable > i486-specific instructions. > > Well, the cpp does not concur to this idea and because of this the glibc > headers that are testing for __i486__ (like the ones that define bswap32 > and bswap16) are getting confused. It would be easy for it to be confused; on powerpc, `-mcpu=601' means produce code that runs only on 601, and `-mtune=601' means write code that runs on any architecture but is scheduled (and so on) for the 601. This is in fact how it works for cpp, too; _ARCH_PWR is defined with -mcpu=601, but not defined with -mtune=601. -- Geoffrey Keating From gafton@redhat.com Fri Jun 18 14:39:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Fri, 18 Jun 1999 14:39:00 -0000 Subject: egcs 2.91.66 ix86 problems... References: <199906170315.NAA00566@geoffk.wattle.id.au> Message-ID: On Thu, 17 Jun 1999, Geoff Keating wrote: > > So after reading this thing one clearly gets the impression the saying > > -mcpu=i486 will affect the scheduler only, while egcs will still generate > > code that will run on i386, and -march=i486 will actually enable > > i486-specific instructions. > > > > Well, the cpp does not concur to this idea and because of this the glibc > > headers that are testing for __i486__ (like the ones that define bswap32 > > and bswap16) are getting confused. > > It would be easy for it to be confused; on powerpc, `-mcpu=601' means > produce code that runs only on 601, and `-mtune=601' means write code > that runs on any architecture but is scheduled (and so on) for the 601. > > This is in fact how it works for cpp, too; _ARCH_PWR is defined with > -mcpu=601, but not defined with -mtune=601. On the Intel -m486 is documented to do what -mtune=i486 would do, but it doesn't only that, at least the cpp gets badly confised. Anybody thinks that this is a problem? The fact that compiling against glibc headers with -m486 (which is almost everywhere in the Makefiles, btw) can result in a binary that will not run on i386, while the gcc/egcs documentation stated for years that this would not happen? Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From aj@arthur.rhein-neckar.de Sun Jun 20 12:45:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 20 Jun 1999 12:45:00 -0000 Subject: The -imacros change Message-ID: Hi all, Zack's change: 1999-06-18 Zack Weinberg * include/libintl.h: Declare _libc_intl_domainname here. Define _ and N_ here. * include/libc-symbols.h: Don't include . Don't define _ and N_. Don't declare _libc_intl_domainname. * Makeconfig (CPPFLAGS): Use -imacros to read libc-symbols.h. ... breaks the compilation of some files since now and is not anymore included in each and every file. On alpha the compilation of sysdeps/generic/divmod_1.c breaks with this message: In file included from ../sysdeps/generic/divmod_1.c:30: longlong.h:169: parse error before `__P' ../sysdeps/generic/divmod_1.c: In function `__mpn_divmod_1': ../sysdeps/generic/divmod_1.c:91: warning: implicit declaration of function `__udiv_qrnnd' The problem is a missing #define __P ... The only question is how to define it. I suggested to add a #include to stdlib/longlong.h Another problem I encountered on ix86 with posix/getopt1.c: In file included from getopt1.c:25: getopt.h:136: warning: function declaration isn't a prototype [...getopt_init compile command] In file included from ../include/getopt.h:1, from getopt_init.c:25: ../posix/getopt.h:136: warning: function declaration isn't a prototype Here's the relevant context: #if defined __STDC__ && __STDC__ # ifdef __GNU_LIBRARY__ /* Many other libraries have conflicting prototypes for getopt, with differences in the consts, in stdlib.h. To avoid compilation errors, only prototype getopt for the GNU C library. */ extern int getopt (int __argc, char *const *__argv, const char *__shortopts); # else /* not __GNU_LIBRARY__ */ extern int getopt (); <-------- this is line 136 # endif /* __GNU_LIBRARY__ */ The problem here is that __GNU_LIBRARY__ isn't defined anymore since is included indirectly after the inclusion of "getopt.h". Should we just move the inclusion further down for getopt_init.c and getop1.c? Fixing these small problems isn't a problem per se - but I fear that we might miss some places that need fixes due to these changes. Is there a way to check that everything was adjusted? Zack, could you please explain what the advantage of this change is? Cheers Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@lucon.org Sun Jun 20 17:43:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 20 Jun 1999 17:43:00 -0000 Subject: binutils 2.9.4.0.6 is released. Message-ID: <19990621004300.9D3D057B9@ocean.lucon.org> Thanks to Ian, more and more changes in binutils 2.9.1.0.25 are finding their ways into the official binutils. Thanks. -- H.J. Lu (hjl@gnu.org) --- This is the beta release of binutils 2.9.4.0.6 for Linux, which is based on binutils 1999 0620 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.4.0.6 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of ""--extract-section=section" for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.6.tar.gz. Source code. 2. binutils-2.9.4.0.5-2.9.4.0.6.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.6-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.6-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/20/99 From kukuk@suse.de Mon Jun 21 10:32:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 21 Jun 1999 10:32:00 -0000 Subject: ecvt rounding problem Message-ID: <19990621193149.A16277@Wotan.suse.de> Hello, I have got an bug report to ecvt(). If the ndigit parameter is greater then the DBL_DIG constant in float.h, you will get rounding errors. (run the attached example with parameters from 14-17 and you will see it. My question: is it Ok to set the ndigit variable to DBL_DIG if it is greater in ecvt or snprintf, where the error happens ? Or to fix it in another way ? I don't think this is a real error. But on all other UNIX systems except glibc based ones the output of the example is always the same for ndigits in 14-17. Thorsten #include main(argc, argv) int argc; char ** argv; { int i; double dbl; char * p; int decpt, sign; for( i=0; i < 300; i++ ) { dbl = i; p = ecvt( dbl, atoi(argv[1]), &decpt, &sign ); printf( "%03d: %e -> %s, %d, %d\n", i, dbl, p, decpt, sign ); } } -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@cygnus.com Mon Jun 21 15:08:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 21 Jun 1999 15:08:00 -0000 Subject: small project Message-ID: Related to the wide character streams there is a small project somebody could tackle. Currently, the only way to determine the character set associated with a wide char stream is to set a locate. This might not be possible all the time, e.g., in multi-threaded applications. Therefore there should be another possiblity. What I have in mind is an extension to fopen. The second parameter is designed with extensions in might. ISO C allows this. Therefore I'd like to see something like this: fp = fopen ("somefile", "r,ccs=XYZ"); This would open the file as usual, but also orient the string to be wide and instead of using the conversion functions from the current locale, load the functions and create the data structures so that charset XYZ is used. Any volunteers? The needed code should all be there already, you simply would have to take it from the different places. Please let me know before starting on this. Thanks, -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Mon Jun 21 15:21:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 21 Jun 1999 15:21:00 -0000 Subject: imacros Message-ID: I've reverted the imacro change introduced by one of Zack's patches. It simply has too many weird effects. E.g., while compiling rpcinfo.c the macro __GNU_LIBRARY__ was not defined. This should not happen. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Mon Jun 21 15:44:00 1999 From: roland@frob.com (Roland McGrath) Date: Mon, 21 Jun 1999 15:44:00 -0000 Subject: small project References: Message-ID: <199906212244.SAA18541@frob.com> Not that I don't like this idea, but another, more general solution also comes to mind. We could move the locale data structures out of global variables and provide a way for a thread to change its per-thread current locale without changing the global one used for other threads. This seems like it could be useful in general, e.g. for a network server that reports results to different clients in different languages/formats. From drepper@cygnus.com Mon Jun 21 15:54:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 21 Jun 1999 15:54:00 -0000 Subject: small project References: <199906212244.SAA18541@frob.com> Message-ID: Roland McGrath writes: > Not that I don't like this idea, but another, more general solution also > comes to mind. We could move the locale data structures out of global > variables and provide a way for a thread to change its per-thread current > locale without changing the global one used for other threads. This seems > like it could be useful in general, e.g. for a network server that reports > results to different clients in different languages/formats. This is, I think, the next step. You certainly have seen that many things are already prepared for this. Locales are objects. From there it is not such a big step creating a function `setthreadlocale' or so. I don't want to introduce this before the locale implementation is complete and the selection in the fopen() parameters is still useful since i won't require you to change the locale. E.g., in situations like this: fd = socket (...); read (fd, &header, sizeof (header)); <... determine charset from header ...> snprintf (buf, sizeof (buf), "r,ccs=%s", charset); fp = fdopen (fd, buf); ... -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gniibe@chroot.org Mon Jun 21 21:27:00 1999 From: gniibe@chroot.org (NIIBE Yutaka) Date: Mon, 21 Jun 1999 21:27:00 -0000 Subject: small project References: Message-ID: <199906220425.NAA30801@pwd.chroot.org> Hi there, Ulrich Drepper writes: > What I have in mind is an extension to fopen. The second parameter is > designed with extensions in might. ISO C allows this. Therefore I'd > like to see something like this: > > fp = fopen ("somefile", "r,ccs=XYZ"); > > This would open the file as usual, but also orient the string to be > wide and instead of using the conversion functions from the current > locale, load the functions and create the data structures so that > charset XYZ is used. Interesting. I think that it's good idea to relate buffer-oriented function and conversion function. > Any volunteers? The needed code should all be there already, you > simply would have to take it from the different places. Please let me > know before starting on this. I'd like to take this one, as it's small and interesting for me very much. However I don't have enough time untill August. So if someone can do this, I don't mind. Regards, -- Niibe Yutaka From drepper@cygnus.com Mon Jun 21 21:35:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 21 Jun 1999 21:35:00 -0000 Subject: small project References: <199906220425.NAA30801@pwd.chroot.org> Message-ID: Niibe-san, > I'd like to take this one, as it's small and interesting for me very > much. However I don't have enough time untill August. So if someone > can do this, I don't mind. Well, we'll see if anybody shows interest or I have some time available. Otherwise just drop a note before starting the work. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From rth@twiddle.net Mon Jun 21 22:20:00 1999 From: rth@twiddle.net (Richard Henderson) Date: Mon, 21 Jun 1999 22:20:00 -0000 Subject: egcs 2.91.66 ix86 problems... References: Message-ID: <19990621222013.D30898@twiddle.net> On Tue, Jun 15, 1999 at 07:09:26PM -0400, Cristian Gafton wrote: > A common sense rule says that using -mcpu=i486 should *not* define > __i486__, because we don't want to use i486 specific code, we are only > interested in the scheduler modifications. but this is not true: You are absolutely right. This is a bug in gcc. r~ From aj@arthur.rhein-neckar.de Mon Jun 21 22:29:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 21 Jun 1999 22:29:00 -0000 Subject: imacros References: Message-ID: >>>>> Ulrich Drepper writes: > I've reverted the imacro change introduced by one of Zack's patches. > It simply has too many weird effects. E.g., while compiling rpcinfo.c > the macro __GNU_LIBRARY__ was not defined. This should not happen. You only reverted part of it. As far as I understand the issues, the problem of not defining __GNU_LIBRARY__ is the missing inclusion of in libc-symbols.h. was indirectly included via libintl.h and you only reverted the Makeconfig part: 1999-06-18 Zack Weinberg * include/libintl.h: Declare _libc_intl_domainname here. Define _ and N_ here. * include/libc-symbols.h: Don't include . Don't define _ and N_. Don't declare _libc_intl_domainname. * Makeconfig (CPPFLAGS): Use -imacros to read libc-symbols.h. I just looked at rpcinfo and it still has __GNU_LIBRARY__ not defined when including getopt.h. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Mon Jun 21 23:30:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 21 Jun 1999 23:30:00 -0000 Subject: imacros References: Message-ID: >>>>> Andreas Jaeger writes: >>>>> Ulrich Drepper writes: >> I've reverted the imacro change introduced by one of Zack's patches. >> It simply has too many weird effects. E.g., while compiling rpcinfo.c >> the macro __GNU_LIBRARY__ was not defined. This should not happen. Andreas> You only reverted part of it. As far as I understand the issues, the Andreas> problem of not defining __GNU_LIBRARY__ is the missing inclusion of Andreas> in libc-symbols.h. was indirectly included Andreas> via libintl.h and you only reverted the Makeconfig part: Andreas> 1999-06-18 Zack Weinberg Andreas> * include/libintl.h: Declare _libc_intl_domainname here. Andreas> Define _ and N_ here. Andreas> * include/libc-symbols.h: Don't include . Don't Andreas> define _ and N_. Don't declare _libc_intl_domainname. Andreas> * Makeconfig (CPPFLAGS): Use -imacros to read libc-symbols.h. Andreas> I just looked at rpcinfo and it still has __GNU_LIBRARY__ not defined Andreas> when including getopt.h. Here's a patch to implement my suggestions. 1999-06-22 Andreas Jaeger * include/libc-symbols.h: Include to fix some problems with the 1999-06-18 change (undefined __GNU_LIBRARY__). --- include/libc-symbols.h.~1~ Sun Jun 20 08:52:01 1999 +++ include/libc-symbols.h Tue Jun 22 08:26:45 1999 @@ -1,6 +1,6 @@ /* Support macros for making weak and strong aliases for symbols, and for using symbol sets and linker warnings with GNU ld. - Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc. + Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -321,4 +321,9 @@ strong_alias(real, name) #endif +/* A lot of files in the GNU C library check for example + __GNU_LIBRARY__. Include to define it and the other + macros. */ +#include + #endif /* libc-symbols.h */ -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kettenis@wins.uva.nl Tue Jun 22 04:03:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Tue, 22 Jun 1999 04:03:00 -0000 Subject: imacros References: Message-ID: <199906221102.NAA04167@delius.kettenis.nl> From: Andreas Jaeger Date: 22 Jun 1999 08:29:22 +0200 >>>>> Andreas Jaeger writes: >>>>> Ulrich Drepper writes: >> I've reverted the imacro change introduced by one of Zack's patches. >> It simply has too many weird effects. E.g., while compiling rpcinfo.c >> the macro __GNU_LIBRARY__ was not defined. This should not happen. Andreas> You only reverted part of it. As far as I understand the Andreas> issues, the problem of not defining __GNU_LIBRARY__ is the Andreas> missing inclusion of in libc-symbols.h. Andreas> was indirectly included via libintl.h and you Andreas> only reverted the Makeconfig part: Andreas> 1999-06-18 Zack Weinberg Andreas> * include/libintl.h: Declare _libc_intl_domainname here. Andreas> Define _ and N_ here. Andreas> * include/libc-symbols.h: Don't include . Don't Andreas> define _ and N_. Don't declare _libc_intl_domainname. Andreas> * Makeconfig (CPPFLAGS): Use -imacros to read libc-symbols.h. Andreas> I just looked at rpcinfo and it still has __GNU_LIBRARY__ Andreas> not defined when including getopt.h. Here's a patch to implement my suggestions. 1999-06-22 Andreas Jaeger * include/libc-symbols.h: Include to fix some problems with the 1999-06-18 change (undefined __GNU_LIBRARY__). The real problem is that makes use of the feature test macro's but does not include itself. We cannot include since is shared with other GNU programs. We could include from . I don't think that would cause any problems, since both getopt.c and getpt1.c already include . If there are serious objections against including , we could also move the inclusion of from rpcinfo.c further down or remove it altogether. Alternativey (if we want to keep the differences with the origional Sun RPC sources as minimal as possible) we could also create libc/include/getopt.h which does: #include #include I don't think including from include/libc-symbols.h is such a good idea, since it hides the cases where we forget to include . Mark From jaeger@informatik.uni-kl.de Tue Jun 22 04:33:00 1999 From: jaeger@informatik.uni-kl.de (jaeger@informatik.uni-kl.de) Date: Tue, 22 Jun 1999 04:33:00 -0000 Subject: imacros Message-ID: <199906221326.aa05999@okarina.informatik.uni-kl.de> >>>>> Mark Kettenis writes: Mark> The real problem is that makes use of the feature test Mark> macro's but does not include itself. We cannot include Mark> since is shared with other GNU programs. We Mark> could include from . I don't think that would Mark> cause any problems, since both getopt.c and getpt1.c already include Mark> . Mark> Mark> If there are serious objections against including , we could Mark> also move the inclusion of from rpcinfo.c further down or Mark> remove it altogether. getopt.h is so far the only include file that gives trouble. But it's not only used in rpcinfo.c, the problems might exist in other files also (cf. my email with subject "-imacros"). Mark> Alternativey (if we want to keep the differences with the origional Mark> Sun RPC sources as minimal as possible) we could also create Mark> libc/include/getopt.h which does: Mark> Mark> #include Mark> #include If we don't want to change getopt.h and don't want to apply my patch, I guess this is the right thing to do. Mark> I don't think including from include/libc-symbols.h is Mark> such a good idea, since it hides the cases where we forget to include Mark> . We included indirectly before Zack's patch got applied and we include it in each file. If there's an advantage with not including it via libc-symbols.h that's ok with me. IMHO the non inclusion of break some files in a subtle way - I haven't seen either a good way to recognise those "cases where we forget to include " nor heard any argument whether there's any advantage with this scheme. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From geoffk@ozemail.com.au Tue Jun 22 05:40:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Tue, 22 Jun 1999 05:40:00 -0000 Subject: imacros References: <199906221326.aa05999@okarina.informatik.uni-kl.de> <199906221326.aa05999@okarina.informatik.uni-kl.de> Message-ID: <199906221234.WAA00631@geoffk.wattle.id.au> > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > From: jaeger@informatik.uni-kl.de > Date: Tue, 22 Jun 1999 13:26:01 MET DST > Source-Info: From (or Sender) name not authenticated. > > >>>>> Mark Kettenis writes: > > Mark> The real problem is that makes use of the feature test > Mark> macro's but does not include itself. We cannot include > Mark> since is shared with other GNU programs. We > Mark> could include from . I don't think that would > Mark> cause any problems, since both getopt.c and getpt1.c already include > Mark> . > Mark> > Mark> If there are serious objections against including , we could > Mark> also move the inclusion of from rpcinfo.c further down or > Mark> remove it altogether. > > getopt.h is so far the only include file that gives trouble. But it's > not only used in rpcinfo.c, the problems might exist in other files > also (cf. my email with subject "-imacros"). include/fpu_control.h also uses __P but doesn't include , which causes sysdeps/generic/fpu_control.c to fail to compile with the current CVS. -- Geoffrey Keating From kettenis@wins.uva.nl Tue Jun 22 06:34:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Tue, 22 Jun 1999 06:34:00 -0000 Subject: imacros References: <199906221326.aa05999@okarina.informatik.uni-kl.de> <199906221234.WAA00631@geoffk.wattle.id.au> <199906221234.WAA00631@geoffk.wattle.id.au> Message-ID: <199906221333.PAA27720@landau.wins.uva.nl> Date: Tue, 22 Jun 1999 22:34:48 +1000 From: Geoff Keating > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > From: jaeger@informatik.uni-kl.de > Date: Tue, 22 Jun 1999 13:26:01 MET DST > Source-Info: From (or Sender) name not authenticated. > > >>>>> Mark Kettenis writes: > > Mark> The real problem is that makes use of the feature test > Mark> macro's but does not include itself. We cannot include > Mark> since is shared with other GNU programs. We > Mark> could include from . I don't think that would > Mark> cause any problems, since both getopt.c and getpt1.c already include > Mark> . > Mark> > Mark> If there are serious objections against including , we could > Mark> also move the inclusion of from rpcinfo.c further down or > Mark> remove it altogether. > > getopt.h is so far the only include file that gives trouble. But it's > not only used in rpcinfo.c, the problems might exist in other files > also (cf. my email with subject "-imacros"). include/fpu_control.h also uses __P but doesn't include , which causes sysdeps/generic/fpu_control.c to fail to compile with the current CVS. Well, include/fpu_control.h does a "#include_next " and the system dependent is supposed to include . The i386 version does this. Nevertheless the usage of __P in include/fpu_control.h is unecessary, since this header isn't installed. Mark From aj@arthur.rhein-neckar.de Tue Jun 22 12:32:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Tue, 22 Jun 1999 12:32:00 -0000 Subject: crypt add-on for 2.1.x on gnu server is missing Message-ID: On ftp.gnu.org and its mirrors is no crypt addon for glibc 2.1.x. Could somebody upload one, please? Thanks, Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Tue Jun 22 12:41:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 22 Jun 1999 12:41:00 -0000 Subject: crypt add-on for 2.1.x on gnu server is missing References: Message-ID: Andreas Jaeger writes: > On ftp.gnu.org and its mirrors is no crypt addon for glibc 2.1.x. > Could somebody upload one, please? I would like to avoid this. We've done this in the past but ideally ftp.gnu.org should not contain crypt code. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Tue Jun 22 13:50:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Tue, 22 Jun 1999 13:50:00 -0000 Subject: crypt add-on for 2.1.x on gnu server is missing References: Message-ID: >>>>> Ulrich Drepper writes: Ulrich> Andreas Jaeger writes: >> On ftp.gnu.org and its mirrors is no crypt addon for glibc 2.1.x. >> Could somebody upload one, please? Ulrich> I would like to avoid this. We've done this in the past but ideally Ulrich> ftp.gnu.org should not contain crypt code. The documentation (README, FAQ, INSTALL files - all three of them) document that it's available from ftp.gnu.org and its mirrors. If you don't want this, you should update those documents and put a README-crypt on ftp.gnu.org. People are asking for the crypt add-on and since they don't find a 2.1.x one, use the 2.0.6 one which doesn't work with 2.1.x. Cheers Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From schwab@issan.cs.uni-dortmund.de Wed Jun 23 00:57:00 1999 From: schwab@issan.cs.uni-dortmund.de (Andreas Schwab) Date: Wed, 23 Jun 1999 00:57:00 -0000 Subject: imacros References: <199906221102.NAA04167@delius.kettenis.nl> Message-ID: Mark Kettenis writes: |> Alternativey (if we want to keep the differences with the origional |> Sun RPC sources as minimal as possible) we could also create |> libc/include/getopt.h which does: |> |> #include |> #include I don't think that is the right thing to do. This will only be effective inside libc, but if a user program includes as the first thing this won't help. The manual does not document any prerequisites for it. I would vote for including in getopt.h. Andreas. From kukuk@suse.de Wed Jun 23 03:32:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Wed, 23 Jun 1999 03:32:00 -0000 Subject: ecvt is completly broken Message-ID: <19990623123130.A23002@Wotan.suse.de> Hello, ecvt/ecvt_r and I think the similar functions are completly broken if the ndigits parameter is greater then DBL_DIG (15). - We give only back an string with the max. length of 16. This is to short if ndigits is 17 or greater. - There is a buffer overrun. for ndigits > 19 I get an coredump - ecvt doesn't round correct. I think this are 2 bugs, the buffer bug is a problem of ecvt, the other seems to me a problem of sprintf. Since I doesn't understand sprintf in the moment, I have no patch for it. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@cygnus.com Wed Jun 23 08:09:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 23 Jun 1999 08:09:00 -0000 Subject: ecvt is completly broken References: <19990623123130.A23002@Wotan.suse.de> Message-ID: Thorsten Kukuk writes: > ecvt/ecvt_r and I think the similar functions are completly broken > if the ndigits parameter is greater then DBL_DIG (15). It's not completely broken. The standard say Converts value to a null-terminated string of ndigit digits (where ndigit is reduced to an unspecified limit determined by the precision of a double) So, if anything is broken than that we currently do not reset ndigits to a reasonable value. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jun 23 12:59:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 23 Jun 1999 12:59:00 -0000 Subject: imacros References: <199906221102.NAA04167@delius.kettenis.nl> Message-ID: Andreas Schwab writes: > I don't think that is the right thing to do. This will only be effective > inside libc, but if a user program includes as the first thing > this won't help. The manual does not document any prerequisites for it. > I would vote for including in getopt.h. Makes sense. getopt.h is a GNU header and therefore we are free to define what we want. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jun 23 13:04:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 23 Jun 1999 13:04:00 -0000 Subject: imacros References: <199906221326.aa05999@okarina.informatik.uni-kl.de> <199906221234.WAA00631@geoffk.wattle.id.au> Message-ID: Geoff Keating writes: > include/fpu_control.h also uses __P but doesn't include , > which causes sysdeps/generic/fpu_control.c to fail to compile with the > current CVS. I already fixed that on one of my branches but forgot to bring this to commit it on the main branch. This happened now. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Thu Jun 24 14:15:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 24 Jun 1999 14:15:00 -0000 Subject: mailpath bug References: Message-ID: <19990624211457.01B1657B9@ocean.lucon.org> > > On Wed, 23 Jun 1999, H.J. Lu wrote: > > > In RedHat 6.0, some problems, like finger, use /var/mail as the mail > > spool dir. But the mail is in /var/spool/mail. I though /var/mail > > was the current Linux standard. Is that true? > > /var/mail is in the FHS 2.0, but was withdrawn from 2.1. > > finger is busted in this case. > Ulrich, could you please update _PATH_MAILDIR in libc/sysdeps/unix/sysv/linux/paths.h in glibc to reflect this change? Thanks. -- H.J. Lu (hjl@gnu.org) From kukuk@suse.de Thu Jun 24 14:28:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Thu, 24 Jun 1999 14:28:00 -0000 Subject: mailpath bug References: <19990624211457.01B1657B9@ocean.lucon.org> <19990624211457.01B1657B9@ocean.lucon.org> Message-ID: <19990624232744.A5187@Wotan.suse.de> On Thu, Jun 24, H.J. Lu wrote: > > > > On Wed, 23 Jun 1999, H.J. Lu wrote: > > > > > In RedHat 6.0, some problems, like finger, use /var/mail as the mail > > > spool dir. But the mail is in /var/spool/mail. I though /var/mail > > > was the current Linux standard. Is that true? > > > > /var/mail is in the FHS 2.0, but was withdrawn from 2.1. This was FHS 2.1pre1, FHS 2.1pre2 has changed it again: The mails must be reachable through /var/mail, but it is now allowed to be a link to /var/spool/mail > > > > finger is busted in this case. The finger SuSE uses had /var/mail hardcoded in the sources and doesn't use paths.h. So changing it in the glibc sources doesn't solve it in every case. > > Ulrich, could you please update _PATH_MAILDIR in > > libc/sysdeps/unix/sysv/linux/paths.h > > in glibc to reflect this change? I'm not sure that it is correct. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From gafton@redhat.com Thu Jun 24 14:33:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Thu, 24 Jun 1999 14:33:00 -0000 Subject: mailpath bug References: <19990624232744.A5187@Wotan.suse.de> Message-ID: On Thu, 24 Jun 1999, Thorsten Kukuk wrote: > This was FHS 2.1pre1, FHS 2.1pre2 has changed it again: > The mails must be reachable through /var/mail, but it is now > allowed to be a link to /var/spool/mail Damn, another one that barely stands a chance... I am always puzzled by this standardization things that in essence are saying "well, everybody is using /var/spool/mail; let's make /var/mail the standard then!" > The finger SuSE uses had /var/mail hardcoded in the sources Probably the same thing happend to Red Hat too. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From aj@arthur.rhein-neckar.de Thu Jun 24 14:42:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Thu, 24 Jun 1999 14:42:00 -0000 Subject: mailpath bug References: <19990624211457.01B1657B9@ocean.lucon.org> Message-ID: >>>>> H J Lu writes: >> >> On Wed, 23 Jun 1999, H.J. Lu wrote: >> >> > In RedHat 6.0, some problems, like finger, use /var/mail as the mail >> > spool dir. But the mail is in /var/spool/mail. I though /var/mail >> > was the current Linux standard. Is that true? >> >> /var/mail is in the FHS 2.0, but was withdrawn from 2.1. >> >> finger is busted in this case. >> HJ> Ulrich, could you please update _PATH_MAILDIR in HJ> libc/sysdeps/unix/sysv/linux/paths.h HJ> in glibc to reflect this change? According to my information that's not right. It was withdrawn in the first draft of 2.1 but it's in the current draft. I'm appending an email from Dan who's the current FHS editor. Ulrich, please don't change it. I ask instead the distributions to follow the FHS! Andreas ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: lsb-spec@lists.linuxbase.org Subject: [forwarded] FHS pre-2.1 draft #2 on web site From: Daniel Quinlan Date: Thu Jun 17 06:48:30 1999 +0200 This draft uses the revised wording for /var/mail as discussed here after the release of draft #1. In addition, the /var/lib text was moved so that it appears in the expected alphabetical order in the /var section. You might want to download and read the entire text if you haven't yet read the first FHS 2.1 pre-draft, especially if you haven't read FHS 2.0 in a while. ------------------------------------------------------------------------ 5.8 /var/mail : User mailbox files The mail spool must be accessible through /var/mail and the mail spool files must take the form . /var/mail may be a symbolic link to another directory. User mailbox files in this location should be stored in the standard UNIX mailbox format. BEGIN RATIONALE The logical location for this directory was changed from /var/spool/mail in order to bring FHS in-line with nearly every UNIX implementation. This change is important for inter-operability since a single /var/mail is often shared between multiple hosts and multiple UNIX implementations (despite NFS locking issues). It is important to note that there is no requirement to physically move the mail spool to this location. However, programs and header files should be changed to use /var/mail. END RATIONALE ------------------------------------------------------------------------ Get it at: http://www.pathname.com/fhs/fhs-2.1-pre-02.tar.gz Dan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From gafton@redhat.com Thu Jun 24 14:48:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Thu, 24 Jun 1999 14:48:00 -0000 Subject: mailpath bug References: Message-ID: On 24 Jun 1999, Andreas Jaeger wrote: > Ulrich, please don't change it. I ask instead the distributions to > follow the FHS! It is easier said than done. I am sure that if we would have the chance to start all over this whole deal there will be a lot of things that will be handled difefrently. But this is not quite possible, so we are pretty much stuck with whatever decisions we have made in the past. We want to be more in line with other unices but we are counting every Linux distribution out of the standard. It is not a trivial move, and we have now a *Linux* file system standard that is trying to walk away from the long established *Linux* standards. Kind of odd... Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From gafton@redhat.com Thu Jun 24 19:33:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Thu, 24 Jun 1999 19:33:00 -0000 Subject: egcs 2.91.66 ix86 problems... References: <5963.930271873@upchuck.cygnus.com> Message-ID: On Thu, 24 Jun 1999, Jeffrey A Law wrote: > > You are saying here about machine code differences, and this is not what > > -mcpu=i486 is documented to do. > True, but I know people are using it the other way. That might be, but those people are wrong then. They are relaying on a undocumented feature - no, wait - the documentation says exactly the opposite of what they are using. So it is not even an undocumented feature. And it is a whole lot simpler to add -march=i486 where different machine code needs to be generated than to dig out the consequences of making that the default on a genuine i386. > > That would be great as well. Any chance of getting some of this fixed? > I can't do it right now. Maybe someone else can. Well, it should be a slighly modified version of rth's patch. But we have to agree on some sort of schema. I suggest to have the __i486 and __i486__ defines reserved for the -march=i486. For the -mcpu=i486 we could use something like __sched_i486__ or something like that. Other suggestions? Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From hjl@lucon.org Sat Jun 26 20:16:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 26 Jun 1999 20:16:00 -0000 Subject: Binutils 2.9.4.0.7 is released Message-ID: <19990627031641.A401557B9@ocean.lucon.org> This is the beta release of binutils 2.9.4.0.7 for Linux, which is based on binutils 1999 0626 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.4.0.7 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.7.tar.gz. Source code. 2. binutils-2.9.4.0.6-2.9.4.0.7.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.7-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.7-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 06/26/99 From wmglo@dent.med.uni-muenchen.de Sun Jun 27 15:29:00 1999 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Sun, 27 Jun 1999 15:29:00 -0000 Subject: egcs-1.1.2 miscompiles Linux (only) with glibc-2.1.1?! Message-ID: <19990627222915.29736.qmail@md.dent.med.uni-muenchen.de> I have now verified and am able to reproduce a pretty weird problem: Unmodified egcs-1.1.2 when bootstrapped on i586-pc-linux against glibc-2.1.1 miscompiles the ncr53c8xx driver in Linux-2.0.37, or at least it compiles it in such a way that it doesn't work (kernel hangs on boot when detecting SCSI devices). Unmodified egcs-1.1.2 when bootstrapped on i586-pc-linux against glibc-2.0.6 seems to compile Linux-2.0.37 just fine, at least ncr53c8xx works. Both of these compilers are _run_ with the same glibc-2.1.1 libc.so, which suggests that the different include files (eg. 2.1.1 has inline string functions) may be the cause for the differing behaviour. Since the Linux kernel uses nothing from libc, it may be that egcs-1.1.2 is miscompiled when using the glibc-2.1.1 headers. This is on a single system (with the same kernel configuration, of course), I only need to change a couple of symlinks to flip between glibc-2.0.6 and glibc-2.1.1. What can I do now to track this down ? Appended is the only noticable difference between the assembler generated for ncr53c8xx.c from both of these egcs-1.1.2 compilers. (/usr/src/linux-egcs-1.1.2/drivers/scsi/ncr53c8xx.s is the `correct'/working version). Regards, Wolfram. --- /usr/src/linux-egcs-1.1.2/drivers/scsi/ncr53c8xx.s Tue Jun 22 23:57:44 1999 +++ ncr53c8xx.s Sun Jun 27 23:35:49 1999 @@ -4107,71 +4107,86 @@ .align 4 .type ncr_wakeup_done,@function ncr_wakeup_done: - subl $4,%esp + subl $12,%esp pushl %ebp pushl %edi pushl %esi pushl %ebx - movl 24(%esp),%edi - leal 2464(%edi),%ebp - movl 2560(%edi),%ecx - movl %ecx,16(%esp) + movl 32(%esp),%ebx + movl 32(%esp),%edi + addl $2464,%edi + movl 2560(%ebx),%ebx + movl %ebx,16(%esp) + movl %edi,24(%esp) .p2align 2 .L1411: - movl 16(%esp),%esi - incl %esi - cmpl $23,%esi + movl 16(%esp),%ebp + incl %ebp + cmpl $23,%ebp jle .L1412 - xorl %esi,%esi + xorl %ebp,%ebp .L1412: - leal 0(,%esi,4),%eax - movl (%eax,%ebp),%ebx - cmpl $-1,%ebx + leal 0(,%ebp,4),%ebx + movl 24(%esp),%edi + movl %ebx,20(%esp) + movl (%ebx,%edi),%esi + movl %esi,%eax + xorl %edx,%edx + andl $0,%eax + andl $-1,%edx + movl %eax,%ecx + orl %edx,%ecx je .L1410 - movl $-1,(%eax,%ebp) - leal 4(%esi,%eax),%edx - movl 2256(%edi),%eax + cmpl $-1,%esi + je .L1410 + movl $-1,(%ebx,%edi) + leal 4(%ebp,%ebx),%edx + movl 32(%esp),%ebx + movl 2256(%ebx),%eax addl $1832,%eax - movl 2260(%edi),%ecx - addl $708,%ecx - movl %ecx,(%eax,%edx,4) + movl 2260(%ebx),%edi + addl $708,%edi + movl %edi,(%eax,%edx,4) #APP #NO_APP - movl 16(%esp),%ecx - leal 4(%ecx,%ecx,4),%edx + movl 16(%esp),%ebx + movl 32(%esp),%edi + leal 4(%ebx,%ebx,4),%edx movl 2256(%edi),%eax addl $1832,%eax - movl 2260(%edi),%ecx - addl $716,%ecx - movl %ecx,(%eax,%edx,4) - movb 29(%ebx),%al + movl 2260(%edi),%ebx + addl $716,%ebx + movl %ebx,(%eax,%edx,4) + movb 29(%esi),%al testb %al,%al - jge .L1414 - pushl %ebx + jge .L1415 + pushl %esi pushl %edi call ncr_complete - jmp .L1418 + jmp .L1419 .p2align 2 -.L1414: +.L1415: testb $32,%al - je .L1415 - pushl %ebx + je .L1416 + pushl %esi + movl 36(%esp),%edi pushl %edi call ncr_ccb_skipped -.L1418: +.L1419: addl $8,%esp -.L1415: - movl %esi,16(%esp) +.L1416: + movl %ebp,16(%esp) jmp .L1411 .p2align 2 .L1410: - movl 16(%esp),%ecx - movl %ecx,2560(%edi) + movl 32(%esp),%edi + movl 16(%esp),%ebx + movl %ebx,2560(%edi) popl %ebx popl %esi popl %edi popl %ebp - popl %ecx + addl $12,%esp ret -- `Surf the sea, not double-u three...' wmglo@dent.med.uni-muenchen.de From hjl@lucon.org Sun Jun 27 18:06:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 18:06:00 -0000 Subject: A new glibc bug Message-ID: <19990628010642.A5E0857BA@ocean.lucon.org> With the current glibc 2.1.2 in CVS today, I got # rlogin foo zsh: 1746 segmentation fault rlogin foo where "foo" is an unknown host. With glibc 2.1.1, I got # rlogin foo foo: Unknown host Any ideas? -- H.J. Lu (hjl@gnu.org) From hjl@lucon.org Sun Jun 27 21:55:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 21:55:00 -0000 Subject: Why this strange change? Message-ID: <19990628045533.10ADB57BB@ocean.lucon.org> Hi, Ulrich, Your change 1999-06-17 Ulrich Drepper * nss/getXXbyYY_r.c: Return error code not -1. * nss/getXXent_r.c: Likewise. breaks glibc and Linux very badly. Any codes like if (getXXbyYY_r (......) < 0) now don't work anymore since now getXXbyYY_r () returns errno which is a positive number. Did you mean to return NAGATIVE of the error code? Could you please double check all of your similar changes and fix them? BTW, even if you can change all of if (getXXbyYY_r (......) < 0) in glibc, how do you change all the user codes? I am not sure it is a good idea to make a change like that. You changed ABI in fact. Thanks. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sun Jun 27 22:11:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 27 Jun 1999 22:11:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > Your change > > 1999-06-17 Ulrich Drepper > > * nss/getXXbyYY_r.c: Return error code not -1. > * nss/getXXent_r.c: Likewise. > > breaks glibc and Linux very badly. Any codes like > > if (getXXbyYY_r (......) < 0) > > now don't work anymore since now getXXbyYY_r () returns errno which is > a positive number. Did you mean to return NAGATIVE of the error code? Because this is the correct behaviour. See POSIX. User code must only test for != 0. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sun Jun 27 22:25:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 22:25:00 -0000 Subject: Why this strange change? References: Message-ID: <19990628052501.27EF657BB@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > Your change > > > > 1999-06-17 Ulrich Drepper > > > > * nss/getXXbyYY_r.c: Return error code not -1. > > * nss/getXXent_r.c: Likewise. > > > > breaks glibc and Linux very badly. Any codes like > > > > if (getXXbyYY_r (......) < 0) > > > > now don't work anymore since now getXXbyYY_r () returns errno which is > > a positive number. Did you mean to return NAGATIVE of the error code? > > Because this is the correct behaviour. See POSIX. > Where can I find it on-line? If it is true, I have to say POSIX is dumb on it. Under Unix, usually the negative int return values indicate error. I tried to think of any positive int error return values. Are there any? H.J. From drepper@cygnus.com Sun Jun 27 22:29:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 27 Jun 1999 22:29:00 -0000 Subject: Why this strange change? References: <19990628052501.27EF657BB@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > Where can I find it on-line? Nowhere. But the X/Open standard might also mention it. Beside, you can believe me. > If it is true, I have to say POSIX is dumb on it. Under Unix, > usually the negative int return values indicate error. I tried to > think of any positive int error return values. Are there any? All functions introduced by POSIX behave this way. It saves an errno access which might, as in glibc's case, be a hidden function call. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sun Jun 27 22:34:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 22:34:00 -0000 Subject: Why this strange change? References: Message-ID: <19990628053410.2F19F57BB@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > Where can I find it on-line? > > Nowhere. But the X/Open standard might also mention it. Beside, you > can believe me. > > > If it is true, I have to say POSIX is dumb on it. Under Unix, > > usually the negative int return values indicate error. I tried to > > think of any positive int error return values. Are there any? > > All functions introduced by POSIX behave this way. It saves an errno > access which might, as in glibc's case, be a hidden function call. > I don't like this new behavior in return values at all. Why not return -errno? Is that because some functions may return unsigned int? H.J. From drepper@cygnus.com Sun Jun 27 22:36:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 27 Jun 1999 22:36:00 -0000 Subject: Why this strange change? References: <19990628053410.2F19F57BB@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > I don't like this new behavior in return values at all. Why not return > -errno? Is that because some functions may return unsigned int? Again, read the standard. It has to be the error value. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sun Jun 27 22:44:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 22:44:00 -0000 Subject: Why this strange change? References: Message-ID: <19990628054422.D9DD557BB@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > I don't like this new behavior in return values at all. Why not return > > -errno? Is that because some functions may return unsigned int? > > Again, read the standard. It has to be the error value. > Where is the standard? Is that final? The standard is made up by people. As I said, I don't like it as what you said it was. I don't believe I am the only one who finds it confusing. -- H.J. Lu (hjl@gnu.org) From aj@arthur.rhein-neckar.de Sun Jun 27 22:47:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 27 Jun 1999 22:47:00 -0000 Subject: A new glibc bug References: <19990628010642.A5E0857BA@ocean.lucon.org> Message-ID: >>>>> H J Lu writes: HJ> With the current glibc 2.1.2 in CVS today, I got HJ> # rlogin foo HJ> zsh: 1746 segmentation fault rlogin foo HJ> where "foo" is an unknown host. With glibc 2.1.1, I got HJ> # rlogin foo HJ> foo: Unknown host HJ> Any ideas? It breaks in rcmd: (gdb) r foo Starting program: /usr/bin/rlogin foo Program received signal SIGSEGV, Segmentation fault. 0x400e4910 in rcmd (ahost=0xbffff7cc, rport=258, locuser=0x804d6b0 "root", remuser=0x804d6b0 "root", cmd=0xbffff7d4 "xterm/38400", fd2p=0x0) at rcmd.c:103 103 *ahost = hp->h_name; (gdb) bt #0 0x400e4910 in rcmd (ahost=0xbffff7cc, rport=258, locuser=0x804d6b0 "root", remuser=0x804d6b0 "root", cmd=0xbffff7d4 "xterm/38400", fd2p=0x0) at rcmd.c:103 #1 0x80492e9 in _start () while (__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, &hp, &herr) < 0) __gethostbyname_r returned 0 and hp was set to null. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Sun Jun 27 22:54:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 27 Jun 1999 22:54:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> Message-ID: >>>>> Ulrich Drepper writes: Ulrich> hjl@lucon.org (H.J. Lu) writes: >> Your change >> >> 1999-06-17 Ulrich Drepper >> >> * nss/getXXbyYY_r.c: Return error code not -1. >> * nss/getXXent_r.c: Likewise. >> >> breaks glibc and Linux very badly. Any codes like >> >> if (getXXbyYY_r (......) < 0) >> >> now don't work anymore since now getXXbyYY_r () returns errno which is >> a positive number. Did you mean to return NAGATIVE of the error code? Ulrich> Because this is the correct behaviour. See POSIX. Ulrich> User code must only test for != 0. This might break X11 since /usr/include/X11/Xos_r.h has: # define _XGethostbyname(h,hp) \ (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ ((gethostbyname_r((h),&(hp).hent,&(hp).hdata) == -1) ? NULL : &(hp).hent)) Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@lucon.org Sun Jun 27 22:55:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 22:55:00 -0000 Subject: A new glibc bug References: Message-ID: <19990628055543.CD3B757BB@ocean.lucon.org> > > >>>>> H J Lu writes: > > HJ> With the current glibc 2.1.2 in CVS today, I got > HJ> # rlogin foo > HJ> zsh: 1746 segmentation fault rlogin foo > > HJ> where "foo" is an unknown host. With glibc 2.1.1, I got > > HJ> # rlogin foo > HJ> foo: Unknown host > > HJ> Any ideas? > > It breaks in rcmd: > (gdb) r foo > Starting program: /usr/bin/rlogin foo > > Program received signal SIGSEGV, Segmentation fault. > 0x400e4910 in rcmd (ahost=0xbffff7cc, rport=258, locuser=0x804d6b0 "root", > remuser=0x804d6b0 "root", cmd=0xbffff7d4 "xterm/38400", fd2p=0x0) > at rcmd.c:103 > 103 *ahost = hp->h_name; > (gdb) bt > #0 0x400e4910 in rcmd (ahost=0xbffff7cc, rport=258, locuser=0x804d6b0 "root", > remuser=0x804d6b0 "root", cmd=0xbffff7d4 "xterm/38400", fd2p=0x0) > at rcmd.c:103 > #1 0x80492e9 in _start () > > while (__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, > &hp, &herr) < 0) > __gethostbyname_r returned 0 and hp was set to null. > No. __gethostbyname_r now returns errno for error. I have no ideas how codes like this are in glibc and in the user programs. I don't like this change from POSIX. H.J. From hjl@lucon.org Sun Jun 27 23:00:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 23:00:00 -0000 Subject: Why this strange change? References: Message-ID: <19990628060032.1B92557BB@ocean.lucon.org> > > Ulrich> User code must only test for != 0. > > This might break X11 since /usr/include/X11/Xos_r.h has: > # define _XGethostbyname(h,hp) \ > (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ > ((gethostbyname_r((h),&(hp).hent,&(hp).hdata) == -1) ? NULL : &(hp).hent)) > That means we may have to recompile every X program. It is an ABI change. If we have to go for it, which I don't like, we should use a new version for every getxxxbyxxx_r (). If I have my way, I will change or ignore POSIX on this one. H.J. From hjl@lucon.org Sun Jun 27 23:08:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 27 Jun 1999 23:08:00 -0000 Subject: The broken POSIX Message-ID: <19990628060853.84B1057BB@ocean.lucon.org> If we have to support the "broken" POSIX, it should be turned off by default. The default one should have the old behavior. And users will get the new "broken" POSIX behavior only if they define something like #define _BROKEN_POSIX_SOURCE I really hate user-visible changes like this. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sun Jun 27 23:21:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 27 Jun 1999 23:21:00 -0000 Subject: Why this strange change? References: <19990628054422.D9DD557BB@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > Where is the standard? Is that final? Yes. This is POSIX.1b. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Sun Jun 27 23:22:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 27 Jun 1999 23:22:00 -0000 Subject: Why this strange change? References: <19990628054422.D9DD557BB@ocean.lucon.org> <199906280603.XAA00787@pizda.davem.net> Message-ID: "David S. Miller" writes: > I agree that this is completely broken too, broken in the fact that so > many applications will now break, so at the very least increment the > version number of these symbols for backwards compatability sake if > silly nonsense changes like this are going to be made. Only broken applications will break. On the other hand, applications which work correctly on other platforms wouldn't work. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Sun Jun 27 23:25:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 27 Jun 1999 23:25:00 -0000 Subject: A new glibc bug References: <19990628010642.A5E0857BA@ocean.lucon.org> Message-ID: Appended is a small test program that shows the problem. The output is (with current glibc cvs 2.1.2): $ ./gethst_r-test gethostbyname_r returned: 0 herr: 1 hp is null But shouldn't gethostbyname_r return a nonzero value? Andreas #include #include #include int main (void) { struct hostent hostbuf, *hp; size_t hstbuflen; char *tmphstbuf; int res; int herr; hstbuflen = 1024; tmphstbuf = alloca (hstbuflen); res = gethostbyname_r ("unknownhost", &hostbuf, tmphstbuf, hstbuflen, &hp, &herr); printf ("gethostbyname_r returned: %d\n", res); printf ("herr: %d\n", herr); printf ("hp is %s\n", hp == NULL ? "null" : "set"); return res; } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Sun Jun 27 23:48:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 27 Jun 1999 23:48:00 -0000 Subject: Why this strange change? References: <19990628054422.D9DD557BB@ocean.lucon.org> <199906280603.XAA00787@pizda.davem.net> Message-ID: >>>>> Ulrich Drepper writes: Uli> "David S. Miller" writes: >> I agree that this is completely broken too, broken in the fact that so >> many applications will now break, so at the very least increment the >> version number of these symbols for backwards compatability sake if >> silly nonsense changes like this are going to be made. Uli> Only broken applications will break. On the other hand, applications Uli> which work correctly on other platforms wouldn't work. In that case glibc is a broken "application". Check the usage of the different get{hst,pwnam,...}_r functions in (I just did a quick grep, I'm sure I've missed some): - sysdeps/generic/glob.c - inet/rcmd.c - inet/rexec.c - pwd/getpw.c - the sunrpc code (clnt_gen.c, clnt_simp.c, getrpcport.c) - sysdeps/unix/sysv/linux/gethostid.c Sorry, no patches this time. Even if this change confirms to POSIX which shouldn't make this change in a minor release. I ask to revert the patches from the glibc 2.1 branch and document this bug fix in glibc 2.2 prominently, at least in the NEWS section. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kukuk@suse.de Mon Jun 28 00:10:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 28 Jun 1999 00:10:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> <19990628045533.10ADB57BB@ocean.lucon.org> Message-ID: <19990628090959.A7746@Wotan.suse.de> Hello, On Sun, Jun 27, H.J. Lu wrote: > Hi, Ulrich, > > Your change > > 1999-06-17 Ulrich Drepper > > * nss/getXXbyYY_r.c: Return error code not -1. > * nss/getXXent_r.c: Likewise. > > breaks glibc and Linux very badly. Any codes like > > if (getXXbyYY_r (......) < 0) > > now don't work anymore since now getXXbyYY_r () returns errno which is > a positive number. Did you mean to return NAGATIVE of the error code? > Could you please double check all of your similar changes and fix them? > > BTW, even if you can change all of > > if (getXXbyYY_r (......) < 0) > > in glibc, how do you change all the user codes? I am not sure it is a > good idea to make a change like that. You changed ABI in fact. Any user program, which checks for < 0, is broken. It doesn't matter what glibc does, all other Unix uses the correct POSIX return values. So you have an glibc 2 only source program which is not portable. It's time to fix this source code. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From aj@arthur.rhein-neckar.de Mon Jun 28 00:20:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 28 Jun 1999 00:20:00 -0000 Subject: Why this strange change? References: <19990628054422.D9DD557BB@ocean.lucon.org> <199906280603.XAA00787@pizda.davem.net> Message-ID: >>>>> Andreas Jaeger writes: >>>>> Ulrich Drepper writes: Uli> "David S. Miller" writes: >>> I agree that this is completely broken too, broken in the fact that so >>> many applications will now break, so at the very least increment the >>> version number of these symbols for backwards compatability sake if >>> silly nonsense changes like this are going to be made. Uli> Only broken applications will break. On the other hand, applications Uli> which work correctly on other platforms wouldn't work. Andreas> In that case glibc is a broken "application". Check the usage of the Andreas> different get{hst,pwnam,...}_r functions in (I just did a quick grep, Andreas> I'm sure I've missed some): Andreas> - sysdeps/generic/glob.c Andreas> - inet/rcmd.c Andreas> - inet/rexec.c Andreas> - pwd/getpw.c Andreas> - the sunrpc code (clnt_gen.c, clnt_simp.c, getrpcport.c) Andreas> - sysdeps/unix/sysv/linux/gethostid.c And I've added some that are ok - glob.c and getpw.c are ok. Andreas> Sorry, no patches this time. Just a question for clarification: gethostid has the following loop: while (__gethostbyname_r (hostname, &hostbuf, buffer, buflen, &hp, &herr) < 0) if (herr != NETDB_INTERNAL || errno != ERANGE) which isn't correct - but does __gethostbyname_r really set errno? The manual doesn't indicate so. Shouldn't this be rewritten to: int res; while ( (res = __gethostbyname_r (hostname, &hostbuf, buffer, buflen, &hp, &herr)) != 0) if (herr != NETDB_INTERNAL || res != ERANGE) Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kukuk@suse.de Mon Jun 28 01:07:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 28 Jun 1999 01:07:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> <19990628090959.A7746@Wotan.suse.de> <199906280744.AAA01960@pizda.davem.net> <199906280744.AAA01960@pizda.davem.net> Message-ID: <19990628100631.D9564@Wotan.suse.de> Hello, On Mon, Jun 28, David S. Miller wrote: > Date: Mon, 28 Jun 1999 09:09:59 +0200 > From: Thorsten Kukuk > > So you have an glibc 2 only source program which is not portable. > It's time to fix this source code. > > So the X Window System is not portable and it should be made broken by > this GLIBC change? If I read the docu for other Unix versions like Solaris 7 correct, yes, it is broken. I haven't looked at the X Sources, it could be that this header file will only be used with Linux/glibc and not on other Unix. But from Solaris7 (man getpwnam): The POSIX functions getpwnam_r() and getpwuid_r() return 0 upon success, or the error number in case of failure. And I have tested it: getpwnam_r gives back the positive errno code. The only difference to glibc is that Solaris doesn't set errno. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From kettenis@wins.uva.nl Mon Jun 28 05:23:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Mon, 28 Jun 1999 05:23:00 -0000 Subject: The broken POSIX References: <19990628060853.84B1057BB@ocean.lucon.org> <19990628060853.84B1057BB@ocean.lucon.org> Message-ID: <199906281148.NAA00239@delius.kettenis.nl> Date: Sun, 27 Jun 1999 23:08:53 -0700 (PDT) From: hjl@lucon.org (H.J. Lu) If we have to support the "broken" POSIX, it should be turned off by default. The default one should have the old behavior. And users will get the new "broken" POSIX behavior only if they define something like #define _BROKEN_POSIX_SOURCE The POSIX behaviour is actually quite consistent. Keep in mind that the *_r interfaces are intended to make thread-safe programming possible. Returning an error value is exactly what the pthread_* interfaces do. I really hate user-visible changes like this. Too bad! Some of the interfaces provided by libc are taken from draft standards. There is always a (small) possibility that such an interface will be changed in the final standard. If this happens, we should modify glibc as quick as possible to reflect those changes. If the interface is documented in the glibc documentation and the change breaks the ABI as specified by that documentation, we should take appropriate measures. But if the function was not documented yet, the user will be ``punished'' for using undocumented non-standard functions. Mark From kettenis@wins.uva.nl Mon Jun 28 05:23:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Mon, 28 Jun 1999 05:23:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> <19990628045533.10ADB57BB@ocean.lucon.org> Message-ID: <199906281224.OAA00253@delius.kettenis.nl> Date: Sun, 27 Jun 1999 21:55:32 -0700 (PDT) From: hjl@lucon.org (H.J. Lu) Hi, Ulrich, Your change 1999-06-17 Ulrich Drepper * nss/getXXbyYY_r.c: Return error code not -1. * nss/getXXent_r.c: Likewise. breaks glibc and Linux very badly. Any codes like if (getXXbyYY_r (......) < 0) now don't work anymore since now getXXbyYY_r () returns errno which is a positive number. Did you mean to return NAGATIVE of the error code? Could you please double check all of your similar changes and fix them? BTW, even if you can change all of if (getXXbyYY_r (......) < 0) in glibc, how do you change all the user codes? I am not sure it is a good idea to make a change like that. You changed ABI in fact. Not for getpw*_r and getgr*_r. The documentation (for getpwuid_r) says: If the return value is `0' the pointer returned in RESULT points to the record which contains the wanted data (i.e., RESULT contains the value RESULT_BUF). If it is nonzero, there is no user in the data base with user ID UID, or the buffer BUFFER is too small to contain all the needed information. In the latter case, ERRNO is set to `ERANGE'. While this doesn't say that getpwuid_r will return an error value, doing so is perfectly OK since any nonzero return value indicates an error of some sorts. All we have to do to maintain binary compatibility with previous glibc versions, is keep setting ERRNO to `ERANGE' for buffer overflow (and of course use ERANGE as the return value as well), and not touching it at all in all other cases. Of course we should adapt the documentation to indicate that these functions now return an error value. The other getXXbyYY_r functions (for example gethostbyname_r) not documented at all, and I haven't seen any standards that mention these yet (Ulrich, does POSIX.1b really define these other functions?). IMHO this means they're not part of any ABI, so we can't be breaking the ABI. One could argue that these function are analogous to the getpw*_r functions and therefore that they should behave in the same way. But that would not be a problem for the reasons given above. Mark From hjl@lucon.org Mon Jun 28 07:50:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Mon, 28 Jun 1999 07:50:00 -0000 Subject: Why this strange change? References: Message-ID: <19990628145025.1E10B57BB@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > Where is the standard? Is that final? > > Yes. This is POSIX.1b. > That is pretty dumb on POSIX. I have checked HP-UX and DIGITAL UNIX. They all have gethostbyname_r which takes different parameters than glibc 2. But they do return -1 on error and set errno. I really don't think we should follow POSIX.1b blindly on this. Can we define extern int __posix_1b_1999_gethostbyname_r (....); extern int __gethostbyname_r (....); #ifdef __USE_POSIX_1b_1999xx #define gethostbyname_r __posix_1b_1999_gethostbyname_r #else #define gethostbyname_r __gethostbyname_r #endif We turn __USE_POSIX_1b_1999xx off by default for glibc 2.1 and issuse a warning to all glibc users. In glibc 2.2, we turn it on by default. BTW, we still need the symbol versioning to make sure all the old binaries still work. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Mon Jun 28 08:28:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 28 Jun 1999 08:28:00 -0000 Subject: Why this strange change? References: <19990628045533.10ADB57BB@ocean.lucon.org> <19990628090959.A7746@Wotan.suse.de> <199906280744.AAA01960@pizda.davem.net> Message-ID: "David S. Miller" writes: > So the X Window System is not portable and it should be made broken by > this GLIBC change? You know very well that the X source code is a big accumulation of #ifdefs. It can easily be fixed. And for backward compatibility one can add a symbol version returning -1. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From rth@twiddle.net Mon Jun 28 13:01:00 1999 From: rth@twiddle.net (Richard Henderson) Date: Mon, 28 Jun 1999 13:01:00 -0000 Subject: egcs-1.1.2 miscompiles Linux (only) with glibc-2.1.1?! References: <19990627222915.29736.qmail@md.dent.med.uni-muenchen.de> <19990627222915.29736.qmail@md.dent.med.uni-muenchen.de> Message-ID: <19990628124746.C18768@twiddle.net> On Sun, Jun 27, 1999 at 10:29:15PM -0000, Wolfram Gloger wrote: > Unmodified egcs-1.1.2 when bootstrapped on i586-pc-linux against > glibc-2.1.1 miscompiles the ncr53c8xx driver in Linux-2.0.37, or at > least it compiles it in such a way that it doesn't work (kernel hangs > on boot when detecting SCSI devices). > > Unmodified egcs-1.1.2 when bootstrapped on i586-pc-linux against > glibc-2.0.6 seems to compile Linux-2.0.37 just fine, at least > ncr53c8xx works. [...] > What can I do now to track this down ? Start by debugging gcc. This > - leal 2464(%edi),%ebp to this > + movl 32(%esp),%edi > + addl $2464,%edi would at first blush appear to be a change in how the combiner is working. I can't think of anything directly in there that would be affected by a library change, but perhaps there is a difference in the generated insn-recog.c file. Make sure all the insn-* files are identical between the two builds. > - leal 0(,%esi,4),%eax > - movl (%eax,%ebp),%ebx > - cmpl $-1,%ebx > + leal 0(,%ebp,4),%ebx > + movl 24(%esp),%edi > + movl %ebx,20(%esp) > + movl (%ebx,%edi),%esi > + movl %esi,%eax > + xorl %edx,%edx > + andl $0,%eax > + andl $-1,%edx > + movl %eax,%ecx > + orl %edx,%ecx > je .L1410 This bit's very bad. The andl 0/-1 thing is particularly disconserting. We wind up with the je always true. r~ From drepper@cygnus.com Mon Jun 28 13:26:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 28 Jun 1999 13:26:00 -0000 Subject: [daemon@cygnus.com] Re: Bug in dl-open()... Message-ID: The mail had an old address in the header. Therefore resent here. Since you might have not seen the original mail either a short explanation. Scott is seeing crashes in the elf/ subdir tests of glibc since during dlopen the search for the call in dl_open_worker fails. My guess is that the __builtin_return_address function for ARM fails or some other errors lead to an incorrect `caller' value. From rth@twiddle.net Mon Jun 28 21:49:00 1999 From: rth@twiddle.net (Richard Henderson) Date: Mon, 28 Jun 1999 21:49:00 -0000 Subject: alpha ev4 and floor Message-ID: <19990628214903.C29673@twiddle.net> It's a kernel bug. r~ --- /owl/wolery/rth/linux/2.2.10/arch/alpha/math-emu/ieee-math.h Tue Jun 22 09:45:23 1999 +++ ieee-math.h Mon Jun 28 21:44:31 1999 @@ -20,7 +20,7 @@ extern unsigned long ieee_CVTST (int rm, unsigned long a, unsigned long *b); extern unsigned long ieee_CVTTS (int rm, unsigned long a, unsigned long *b); extern unsigned long ieee_CVTQS (int rm, unsigned long a, unsigned long *b); -extern unsigned long ieee_CVTQT (int rm, unsigned long a, unsigned long *b); +extern unsigned long ieee_CVTQT (int rm, long a, unsigned long *b); extern unsigned long ieee_CVTTQ (int rm, unsigned long a, unsigned long *b); extern unsigned long ieee_CMPTEQ (unsigned long a, unsigned long b, --- /owl/wolery/rth/linux/2.2.10/arch/alpha/math-emu/ieee-math.c Sat Jun 12 06:40:53 1999 +++ ieee-math.c Mon Jun 28 21:44:16 1999 @@ -704,20 +703,21 @@ ieee_CVTQS (int f, unsigned long a, unsi * FPCR_INV if invalid operation occurred, etc. */ unsigned long -ieee_CVTQT (int f, unsigned long a, unsigned long *b) +ieee_CVTQT (int f, long a, unsigned long *b) { EXTENDED op_b; - op_b.s = 0; - op_b.f[0] = a; - op_b.f[1] = 0; - if (sign(a) < 0) { - op_b.s = 1; - op_b.f[0] = -a; + if (a != 0) { + op_b.s = (a < 0 ? 1 : 0); + op_b.f[0] = (a < 0 ? -a : a); + op_b.f[1] = 0; + op_b.e = 55; + normalize(&op_b); + return round_t_ieee(f, &op_b, b); + } else { + *b = 0; + return 0; } - op_b.e = 55; - normalize(&op_b); - return round_t_ieee(f, &op_b, b); } From aj@arthur.rhein-neckar.de Mon Jun 28 23:25:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 28 Jun 1999 23:25:00 -0000 Subject: gethostbyname_r broken Message-ID: The program below tests gethostbyname_r with an unknown host. The function returns with 0 (instead of != 0) but doesn't set the host pointer: $ ./gethst_r-test gethostbyname_r returned: 0 herr: 1 hp is null nss/getXXbyYY_r.c now has: return status == NSS_STATUS_SUCCESS ? 0 : errno; But what happens if errno is 0 and status != NSS_STATUS_SUCCESS (this happens with host not found in my test program)? Before Ulrich's change we always returned -1 and could easily check for it. The glibc manual isn't clear on this - do I have to check also the return pointer for NULL if the result is 0? The POSIX documentation seems to imply this. Let's look at an example from glibc (inet/rcmd.c): while (__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, &hp, &herr) != 0) if (herr != NETDB_INTERNAL || errno != ERANGE) { __set_h_errno (herr); herror(*ahost); return -1; } else { /* Enlarge the buffer. */ hstbuflen *= 2; tmphstbuf = __alloca (hstbuflen); } pfd[0].events = POLLIN; pfd[1].events = POLLIN; *ahost = hp->h_name; This code segfaults accessing hp->h_name iff the host doesn't exist. We need to add at least the following code after the loop: if (hp == NULL) { __set_h_errno (herr); herror(*ahost); return -1; } I'm appending a patch for inet/rcmd.c which fixes one of the three gethostbyname_r calls and like to get your comments on it before I fix the rest. Andreas #include #include #include int main (void) { struct hostent hostbuf, *hp; size_t hstbuflen; char *tmphstbuf; int res; int herr; hstbuflen = 1024; tmphstbuf = alloca (hstbuflen); res = gethostbyname_r ("unknownhost", &hostbuf, tmphstbuf, hstbuflen, &hp, &herr); printf ("gethostbyname_r returned: %d\n", res); printf ("herr: %d\n", herr); printf ("hp is %s\n", hp == NULL ? "null" : "set"); return res; } --- inet/rcmd.c.~2~ Mon Jun 28 22:36:37 1999 +++ inet/rcmd.c Tue Jun 29 08:21:23 1999 @@ -79,21 +79,22 @@ hstbuflen = 1024; tmphstbuf = __alloca (hstbuflen); - while (__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, - &hp, &herr) != 0) - if (herr != NETDB_INTERNAL || errno != ERANGE) - { - __set_h_errno (herr); - herror(*ahost); - return -1; - } - else - { - /* Enlarge the buffer. */ - hstbuflen *= 2; - tmphstbuf = __alloca (hstbuflen); - } - + + while ((__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, + &hp, &herr) != 0) && + (herr == NETDB_INTERNAL) && (errno == ERANGE)) + { + /* Enlarge the buffer. */ + hstbuflen *= 2; + tmphstbuf = __alloca (hstbuflen); + } + if (herr != 0 || hp == NULL) + { + __set_h_errno (herr); + herror(*ahost); + return -1; + } + pfd[0].events = POLLIN; pfd[1].events = POLLIN; -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kukuk@suse.de Mon Jun 28 23:57:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 28 Jun 1999 23:57:00 -0000 Subject: gethostbyname_r broken References: Message-ID: <19990629085630.A28626@Wotan.suse.de> On Tue, Jun 29, Andreas Jaeger wrote: > > The program below tests gethostbyname_r with an unknown host. The > function returns with 0 (instead of != 0) but doesn't set the host > pointer: > > $ ./gethst_r-test > gethostbyname_r returned: 0 > herr: 1 > hp is null This is what Solaris does with all _r functions. If the entrie doesn't exist, it returns 0, errno = 0 and the pointer is 0. Only if the buffer is to small or another error happens they return the errno code, but errno is always zero. > > nss/getXXbyYY_r.c now has: > return status == NSS_STATUS_SUCCESS ? 0 : errno; > > But what happens if errno is 0 and status != NSS_STATUS_SUCCESS (this > happens with host not found in my test program)? Before Ulrich's > change we always returned -1 and could easily check for it. The glibc > manual isn't clear on this - do I have to check also the return > pointer for NULL if the result is 0? The POSIX documentation seems to > imply this. Yes, it seems this the way POSIX handle it. > > Let's look at an example from glibc (inet/rcmd.c): > while (__gethostbyname_r (*ahost, &hostbuf, tmphstbuf, hstbuflen, > &hp, &herr) != 0) > if (herr != NETDB_INTERNAL || errno != ERANGE) > { > __set_h_errno (herr); > herror(*ahost); > return -1; > } > else > { > /* Enlarge the buffer. */ > hstbuflen *= 2; > tmphstbuf = __alloca (hstbuflen); > } > pfd[0].events = POLLIN; > pfd[1].events = POLLIN; > > *ahost = hp->h_name; > > This code segfaults accessing hp->h_name iff the host doesn't exist. > > We need to add at least the following code after the loop: > if (hp == NULL) > { > __set_h_errno (herr); > herror(*ahost); > return -1; > } > > I'm appending a patch for inet/rcmd.c which fixes one of the three > gethostbyname_r calls and like to get your comments on it before I fix > the rest. > If we use the POSIX behavior for getXXbyYY_r functions, we shouldn't use errno. Instead we should use the return value from the function. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From aj@arthur.rhein-neckar.de Tue Jun 29 08:57:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Tue, 29 Jun 1999 08:57:00 -0000 Subject: Manual update for get.*_r functions Message-ID: Hi, I'm appending a patch for the manual to document the POSIX behaviour to summarize my understanding of the issue. Andreas 1999-06-29 Andreas Jaeger * manual/users.texi (Lookup User): Document POSIX return semantics for getpwuid_r and getgrgid_r. * manual/socket.texi (Host Names): Document that the result pointer is null in case of error or host not found and fix a typo. Give a small example. --- manual/socket.texi.~2~ Thu Jun 17 21:05:23 1999 +++ manual/socket.texi Tue Jun 29 17:53:36 1999 @@ -1284,13 +1284,42 @@ parameters. A pointer to the buffer, in which the result is stored, is available in -@code{*@var{result}} after the function call successfully returned. -Success is signalled by a zero return value. If the function failed the -return value is an error number. In addition to the errors defined for -@code{gethostbyname} it can also be @code{ERANGE}. In this case the -call should be repeated with a larger buffer. Additional error -information is not stored in the global variable @code{h_errno} but -instead in the object pointed to by @var{h_errnop}. +@code{*@var{result}} after the function call successfully returned. If +an error occurs or if no entry is found, the pointer @code{*var{result} +is a null pointer. Success is signalled by a zero return value. If the +function failed the return value is an error number. In addition to the +errors defined for @code{gethostbyname} it can also be @code{ERANGE}. +In this case the call should be repeated with a larger buffer. +Additional error information is not stored in the global variable +@code{h_errno} but instead in the object pointed to by @var{h_errnop}. + +Here's a small example: +@smallexample +struct hostent * +gethostname (char *host) +@{ + struct hostent hostbuf, *hp; + size_t hstbuflen; + char *tmphstbuf; + int res; + int herr; + + hstbuflen = 1024; + tmphstbuf = malloc (hstbuflen); + + while ((res = gethostbyname_r (host, &hostbuf, tmphstbuf, hstbuflen, + &hp, &herr)) == ERANGE) + @{ + /* Enlarge the buffer. */ + hstbuflen *= 2; + tmphstbuf = realloc (tmphstbuf, hstbuflen); + @} + /* Check for errors. */ + if (res || hp == NULL) + return NULL; + return hp->h_name; +@} +@end smallexample @end deftypefun @comment netdb.h @@ -1314,7 +1343,7 @@ Similar to the @code{gethostbyname_r} function, the caller must provide buffers for the result and memory used internally. In case of success -the funciton returns zero. Otherwise the value is an error number where +the function returns zero. Otherwise the value is an error number where @code{ERANGE} has the special meaning that the caller-provided buffer is too small. @end deftypefun --- manual/users.texi.~1~ Fri Nov 20 18:44:39 1998 +++ manual/users.texi Tue Jun 29 17:41:47 1999 @@ -1479,12 +1479,14 @@ are used to contain additional information, normally strings which are pointed to by the elements of the result structure. -If the return value is @code{0} the pointer returned in @var{result} -points to the record which contains the wanted data (i.e., @var{result} -contains the value @var{result_buf}). If it is nonzero, there is no -user in the data base with user ID @var{uid}, or the buffer @var{buffer} -is too small to contain all the needed information. In the latter case, -@var{errno} is set to @code{ERANGE}. +If a user with ID @var{uid} is found, the pointer returned in +@var{result} points to the record which contains the wanted data (i.e., +@var{result} contains the value @var{result_buf}). If no user is found +or if an error occured, the pointer returned in @var{result} is a null +pointer. The function returns zero or an error code. If the buffer +@var{buffer} is too small to contain all the needed information, the +error code @code{ERANGE} is returned and @var{errno} is set to +@code{ERANGE}. @end deftypefun @@ -1690,12 +1692,14 @@ are used to contain additional information, normally strings which are pointed to by the elements of the result structure. -If the return value is @code{0} the pointer returned in @var{result} -points to the requested data (i.e., @var{result} contains the value -@var{result_buf}). If it is nonzero, there is no group in the data base -with group ID @var{gid}, or the buffer @var{buffer} is too small to -contain all the needed information. In the latter case, @var{errno} is -set to @code{ERANGE}. +If a group with ID @var{gid} is found, the pointer returned in +@var{result} points to the record which contains the wanted data (i.e., +@var{result} contains the value @var{result_buf}). If no group is found +or if an error occured, the pointer returned in @var{result} is a null +pointer. The function returns zero or an error code. If the buffer +@var{buffer} is too small to contain all the needed information, the +error code @code{ERANGE} is returned and @var{errno} is set to +@code{ERANGE}. @end deftypefun @comment grp.h -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From Philip.Blundell@pobox.com Tue Jun 29 14:46:00 1999 From: Philip.Blundell@pobox.com (Philip Blundell) Date: Tue, 29 Jun 1999 14:46:00 -0000 Subject: [daemon@cygnus.com] Re: Bug in dl-open()... References: Message-ID: >My guess is that the __builtin_return_address function for ARM fails >or some other errors lead to an incorrect `caller' value. __builtin_return_address will fail with -fomit-frame-pointer but I think it should be OK otherwise. It's been a while since I tried building on my ARM system but I'll see if I can find the time to have a go tomorrow. p. From aj@arthur.rhein-neckar.de Tue Jun 29 22:28:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Tue, 29 Jun 1999 22:28:00 -0000 Subject: Where is getpw declared? Message-ID: The linux manual page states that getpw is declared via including - but I can't find the prototype in any header at all. I guess getpw is a GNU extension, since I couldn't find any documentation on it besides the man page. Andreas 1999-06-30 Andreas Jaeger * pwd/pwd.h: Add getpw prototype declaration. --- pwd/pwd.h.~1~ Wed Jun 23 21:04:30 1999 +++ pwd/pwd.h Wed Jun 30 07:24:12 1999 @@ -1,4 +1,4 @@ -/* Copyright (C) 1991, 92, 95, 96, 97, 98 Free Software Foundation, Inc. +/* Copyright (C) 1991, 92, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -135,6 +135,12 @@ #endif /* POSIX or reentrant */ +#ifdef __USE_GNU +/* Re-construct the password-file line for the given uid + in the given buffer. This knows the format that the caller + will expect, but this need not be the format of the password file. */ +extern int getpw __P ((__uid_t __uid, char *__buffer)); +#endif __END_DECLS -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From roland@frob.com Tue Jun 29 22:31:00 1999 From: roland@frob.com (Roland McGrath) Date: Tue, 29 Jun 1999 22:31:00 -0000 Subject: Where is getpw declared? References: Message-ID: <199906300531.BAA02601@frob.com> > > The linux manual page states that getpw is declared via including > - but I can't find the prototype in any header at all. > > I guess getpw is a GNU extension, since I couldn't find any > documentation on it besides the man page. It is an ancient (BSD maybe?) function. I put it in GNU libc in the first place for compatibility, probably with 4.3BSD and/or SysVr3 at the time. I don't know if anybody uses it now. From wmglo@dent.med.uni-muenchen.de Wed Jun 30 08:13:00 1999 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Wed, 30 Jun 1999 08:13:00 -0000 Subject: egcs-1.1.2 miscompiles Linux (only) with glibc-2.1.1?! References: <19990627222915.29736.qmail@md.dent.med.uni-muenchen.de> <19990628124746.C18768@twiddle.net> <19990628124746.C18768@twiddle.net> Message-ID: <19990630151310.25158.qmail@md.dent.med.uni-muenchen.de> Arghh ! It's the _preprocessor_ that behaves differently under glibc2.0 and glibc2.1 bootstraps of egcs-1.1.2! I was really going crazy over this, but here is a nice simple testcase: cpp-bpl.c ====================================================================== #if (~0UL) == 0xffffffffUL #error "32 Bit platform" #else #error "64 Bit platform" #endif ====================================================================== md:/home/wmglo/src/egcs-bugs% /pkg/egcs-1.1.2/bin/gcc cpp-bpl.c cpp-bpl.c:2: #error "32 Bit platform" md:/home/wmglo/src/egcs-bugs% gcc cpp-bpl.c cpp-bpl.c:4: #error "64 Bit platform" (the only difference between /pkg/egcs-1.1.2/bin/gcc and gcc is that the former has been bootstrapped against glibc2.0, the latter against glibc2.1). This is on 32bit Intel, of course. The Linux ncr53c8xx driver contains this test, but only for Linux versions before 2.2.0, which is why H.J. didn't see this bug. This compile-time test for 32bit vs. 64bit is probably broken, and the glibc-2.1-bootstrapped version of egcs-1.1.2 is actually more correct than the glibc-2.0-bootstrapped version (were the test worked), right? Regards, Wolfram. -- `Surf the sea, not double-u three...' wmglo@dent.med.uni-muenchen.de From drepper@cygnus.com Wed Jun 30 09:16:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 09:16:00 -0000 Subject: egcs-1.1.2 miscompiles Linux (only) with glibc-2.1.1?! References: <19990627222915.29736.qmail@md.dent.med.uni-muenchen.de> <19990628124746.C18768@twiddle.net> <19990630151310.25158.qmail@md.dent.med.uni-muenchen.de> Message-ID: Wolfram Gloger writes: > This compile-time test for 32bit vs. 64bit is probably broken, Yes. The ISO C9x draft standard demands that the preprocessor arithmetic is carried out with at least 64 bits, regardless of the paltform. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jun 30 12:23:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 12:23:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: Andreas Jaeger writes: > I'm appending a patch for the manual to document the POSIX behaviour > to summarize my understanding of the issue. The test for a NULL pointer should not be necessary. Where did you find this necessary? It is then a bug in the NSS backend. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Wed Jun 30 12:42:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 30 Jun 1999 12:42:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I'm appending a patch for the manual to document the POSIX behaviour >> to summarize my understanding of the issue. Uli> The test for a NULL pointer should not be necessary. Where did you Uli> find this necessary? It is then a bug in the NSS backend. I've checked POSIX and my understanding of POSIX is that the check for NULL is necessary. Check the appended test program with the following line in nsswitch.conf: hosts: files dns Andreas #include #include #include int main (void) { struct hostent hostbuf, *hp; size_t hstbuflen; char *tmphstbuf; int res; int herr; hstbuflen = 1024; tmphstbuf = alloca (hstbuflen); res = gethostbyname_r ("unknownhost", &hostbuf, tmphstbuf, hstbuflen, &hp, &herr); printf ("gethostbyname_r returned: %d\n", res); printf ("herr: %d\n", herr); printf ("hp is %s\n", hp == NULL ? "null" : "set"); return res; } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Wed Jun 30 12:47:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 12:47:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: Andreas Jaeger writes: > I've checked POSIX and my understanding of POSIX is that the check for > NULL is necessary. POSIX says: If successful, the getpwuid_r() and getpwnam_r() functions shall return zero. Otherwise, an error number shall be returned to indicate the error. I.e., the return value is != 0 in all error cases and no found entry is an error case. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Wed Jun 30 14:03:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Wed, 30 Jun 1999 14:03:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: <19990630230221.A29146@Wotan.suse.de> On Wed, Jun 30, Ulrich Drepper wrote: > Andreas Jaeger writes: > > > I've checked POSIX and my understanding of POSIX is that the check for > > NULL is necessary. > > POSIX says: > > If successful, the getpwuid_r() and getpwnam_r() functions shall > return zero. Otherwise, an error number shall be returned to > indicate the error. > > > I.e., the return value is != 0 in all error cases and no found entry > is an error case. No, no found entry is not an error case. I don't have a copy of POSIX, but what I have read is, that the pointer is NULL if there is an error or we couldn't find the entry. All texts I have read about this mentions explicitly both cases. And only if there is an error we return the error code. Not if we doesn't found the entry. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From kettenis@wins.uva.nl Wed Jun 30 14:25:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Wed, 30 Jun 1999 14:25:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: <199906302126.XAA00131@delius.kettenis.nl> From: Ulrich Drepper Date: 30 Jun 1999 12:47:26 -0700 Andreas Jaeger writes: > I've checked POSIX and my understanding of POSIX is that the check for > NULL is necessary. POSIX says: If successful, the getpwuid_r() and getpwnam_r() functions shall return zero. Otherwise, an error number shall be returned to indicate the error. I.e., the return value is != 0 in all error cases and no found entry is an error case. Yep, but Andreas is talking about gethostbyname_r(). The case he illustrates with his example is the case where gethostbyname() sets h_errno to HOST_NOT_FOUND, but errno is not set. Therefore, gethostbyname_r() returns 0 and stores HOST_NOT_FOUND in h_errnop. So instead of checking both the return value and the value stored in h_errnop, Andreas suggests to check the result pointer. AFAIK gethostbyname_r() is not standardized by POSIX. If you look at the code in bind 8.2 (src/include/netdb.h) you see that there are two flavours of the various getXXbyYY_r functions. Solaris and BSDI return a pointer to the resul buffer on success (and NULL on some sort of failure, which sets errno or stores something in h_errnop). HPUX and OSF return -1 on error and use a special data structure to guarantee thread-safety. While looking into these things, I came across a message apparently written by one of the people who did the origional implementation of gethostbyname_r on Solaris, where he said that returning a pointer to the struct was a bit silly (since the same pointer is already stored in a location specified by the user) and that returning an error value would be the right thing to do (which is what we do for glibc right now). Mark From aj@arthur.rhein-neckar.de Wed Jun 30 14:54:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 30 Jun 1999 14:54:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I've checked POSIX and my understanding of POSIX is that the check for >> NULL is necessary. Uli> POSIX says: Uli> If successful, the getpwuid_r() and getpwnam_r() functions shall Uli> return zero. Otherwise, an error number shall be returned to Uli> indicate the error. Uli> I.e., the return value is != 0 in all error cases and no found entry Uli> is an error case. Let's read it in context. Please note that I'm citing the draft from the Austin Group: The getpwnam_r() function updates the passwd structure pointed to by pwd and stores a pointer to that structure at the location pointed to by result. The structure contonas an entry from the user database with a matching name. Storage referenced by the structure is allocated from the memory provided with the buffer parameter, which is bufsize characters in size. The maximum size needed for this buffer can be determined with the {_SC_GETPW_R_SIZE_MAX} sysconf() paramter. A NULL pointer is returned at the location pointed to by result on error or if the requested entry is not found. For me the last sentence differentiates between errors and no entry found - which lead me to imply that no entry found is *not* an error and therefore the function should return 0. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From aj@arthur.rhein-neckar.de Wed Jun 30 14:56:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 30 Jun 1999 14:56:00 -0000 Subject: Manual update for get.*_r functions References: <199906302126.XAA00131@delius.kettenis.nl> Message-ID: >>>>> Mark Kettenis writes: Mark> From: Ulrich Drepper Mark> Date: 30 Jun 1999 12:47:26 -0700 Mark> Andreas Jaeger writes: >> I've checked POSIX and my understanding of POSIX is that the check for >> NULL is necessary. Mark> POSIX says: Mark> If successful, the getpwuid_r() and getpwnam_r() functions shall Mark> return zero. Otherwise, an error number shall be returned to Mark> indicate the error. Mark> I.e., the return value is != 0 in all error cases and no found entry Mark> is an error case. Mark> Yep, but Andreas is talking about gethostbyname_r(). The case he Mark> illustrates with his example is the case where gethostbyname() sets Mark> h_errno to HOST_NOT_FOUND, but errno is not set. Therefore, Mark> gethostbyname_r() returns 0 and stores HOST_NOT_FOUND in h_errnop. So Mark> instead of checking both the return value and the value stored in Mark> h_errnop, Andreas suggests to check the result pointer. Please note that this is a real life example - it's from inet/rcmd.c. There we only check the return value of gethostbyname_r and access the result pointer if the return value is 0 without checking h_errnop which leads to a segmentation fault. Mark> AFAIK gethostbyname_r() is not standardized by POSIX. If you look at Mark> the code in bind 8.2 (src/include/netdb.h) you see that there are Mark> two flavours of the various getXXbyYY_r functions. Solaris and BSDI Mark> return a pointer to the resul buffer on success (and NULL on some sort Mark> of failure, which sets errno or stores something in h_errnop). HPUX Mark> and OSF return -1 on error and use a special data structure to Mark> guarantee thread-safety. gethostbyname_r is indeed not standardized but getpwuid_r and getpwnam_r are. IMHO we've got to deal (and document!) the following issues: - what happens if getpwuid_r can't find a user. Is an error number returned or not? Is our behaviour conforming with POSIX? - how should gethostbyname_r work if no host is found? Should it follow the same semantics as getpwuid_r or not? Sorry for the confusion but IMO those issues are closely related. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Wed Jun 30 16:58:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 16:58:00 -0000 Subject: Where is getpw declared? References: Message-ID: Andreas Jaeger writes: > The linux manual page states that getpw is declared via including > - but I can't find the prototype in any header at all. I've added your patch. I've also marked getpw as dangerous since buffer overruns are possible. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jun 30 17:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 17:05:00 -0000 Subject: Manual update for get.*_r functions References: Message-ID: Andreas Jaeger writes: > For me the last sentence differentiates between errors and no entry > found - which lead me to imply that no entry found is *not* an error > and therefore the function should return 0. You can interpret it that way, yes. And at least one implementation does it this way. I'll change the sources. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jun 30 17:10:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 30 Jun 1999 17:10:00 -0000 Subject: Manual update for get.*_r functions References: <199906302126.XAA00131@delius.kettenis.nl> Message-ID: Mark Kettenis writes: > AFAIK gethostbyname_r() is not standardized by POSIX. If you look at > the code in bind 8.2 (src/include/netdb.h) you see that there are > two flavours of the various getXXbyYY_r functions. Solaris and BSDI > return a pointer to the resul buffer on success (and NULL on some sort > of failure, which sets errno or stores something in h_errnop). Solaris also implemented getpwbynam_r etc differently before. But for glibc we have done it after the POSIX specs were out and we modelled all _r interfaces after the POSIX one. Which is better since consistent. Take a look at the mess in the Solaris pwd.h file. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------