Mercurial > hg > octave-nkf > gnulib-hg
changeset 7663:402e5e700db8
autoupdate
author | Karl Berry <karl@freefriends.org> |
---|---|
date | Thu, 16 Nov 2006 14:22:26 +0000 |
parents | 8c905c6c16a0 |
children | 9bffd733a8c3 |
files | build-aux/config.guess doc/standards.texi |
diffstat | 2 files changed, 27 insertions(+), 10 deletions(-) [+] |
line wrap: on
line diff
--- a/build-aux/config.guess +++ b/build-aux/config.guess @@ -4,7 +4,7 @@ # 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, # Inc. -timestamp='2006-11-08' +timestamp='2006-11-15' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -1209,6 +1209,9 @@ SX-6:SUPER-UX:*:*) echo sx6-nec-superux${UNAME_RELEASE} exit ;; + SX-8:SUPER-UX:*:*) + echo sx8-nec-superux${UNAME_RELEASE} + exit ;; Power*:Rhapsody:*:*) echo powerpc-apple-rhapsody${UNAME_RELEASE} exit ;;
--- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @setfilename standards.info @settitle GNU Coding Standards @c This date is automagically updated when you save this file: -@set lastupdate August 19, 2006 +@set lastupdate November 15, 2006 @c %**end of header @dircategory GNU organization @@ -149,7 +149,7 @@ For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very -different. You could keep the entire input file in core and scan it +different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). @@ -2144,7 +2144,7 @@ If a program typically uses just a few meg of memory, don't bother making any effort to reduce memory usage. For example, if it is impractical for other reasons to operate on files more than a few meg long, it is -reasonable to read entire input files into core to operate on them. +reasonable to read entire input files into memory to operate on them. However, for programs such as @code{cat} or @code{tail}, that can usefully operate on very large files, it is important to avoid using a @@ -2152,10 +2152,10 @@ If a program works by lines and could be applied to arbitrary user-supplied input files, it should keep only a line in memory, because this is not very hard and users will want to be able to operate on input -files that are bigger than will fit in core all at once. +files that are bigger than will fit in memory all at once. If your program creates complicated data structures, just make them in -core and give a fatal error if @code{malloc} returns zero. +memory and give a fatal error if @code{malloc} returns zero. @node File Usage @section File Usage @@ -2563,8 +2563,9 @@ same declaration. Instead, declare the structure tag separately and then use it to declare the variables or typedefs. -Try to avoid assignments inside @code{if}-conditions. For example, -don't write this: +Try to avoid assignments inside @code{if}-conditions (assignments +inside @code{while}-conditions are ok). For example, don't write +this: @example if ((foo = (char *) malloc (sizeof *foo)) == 0) @@ -2736,8 +2737,21 @@ @example int c; @dots{} -while ((c = getchar()) != EOF) - write(file_descriptor, &c, 1); +while ((c = getchar ()) != EOF) + write (file_descriptor, &c, 1); +@end example + +@noindent Instead, use @code{unsigned char} as follows. (The @code{unsigned} +is for portability to unusual systems where @code{char} is signed and +where there is integer overflow checking.) + +@example +int c; +while ((c = getchar ()) != EOF) + @{ + unsigned char u = c; + write (file_descriptor, &u, 1); + @} @end example It used to be ok to not worry about the difference between pointers