🚀 go-pugleaf

In article <1992Nov11.012228.23372@access.usask.ca> eric@skatter.usask.ca writes:
| I reported this bug in December 1989, and when NeXTSTEP 2.0 came out,
| and when NeXTSTEP 2.1 arrived, and now that NeXTSTEP 3.0 has arrived ...
| IT STILL ISN'T FIXED!!!!!
| 

	I thought compiler problems were supposed to be reported to the GNU
people.  This one certainly fits that category!  BTW, GCC 2.1 generates the
same output as (NeXT 3.0) GCC 1.93.

--Felix

In article <1992Nov11.033324.9278@cbnewsl.cb.att.com>
	coco@cbnewsl.cb.att.com (felix.lugo) writes:
>	I thought compiler problems were supposed to be reported to the GNU
>people.  This one certainly fits that category!

No it doesn't.  printf isn't part of the C language (C has *no*
builtin I/O)--it's just another external procedure call to the
compiler.  NeXT isn't using a GNU C runtime library, so the
original poster is attributing blame where it's due.

However, if the "problem" really is that ANSI printf and BSD
printf *need* to have different semantics, then NeXT should
extend sprintf's special treatment to the rest of the printf
family.  Breaking compatibility with existing code is *bad*
(something NeXT needs to start taking a lot more seriously).

ANSI C is not "better" C--it's simply "different" C.

					-=EPS=-

In article <1992Nov11.012228.23372@access.usask.ca> eric@skatter.usask.ca writes:
>I reported this bug in December 1989, and when NeXTSTEP 2.0 came out,
>and when NeXTSTEP 2.1 arrived, and now that NeXTSTEP 3.0 has arrived ...
>IT STILL ISN'T FIXED!!!!!
>
>Here's an example program:
>
>#include <stdio.h>
>int
>main (int argc, char **argv)
>{
>	int i, d;
>	double x, y;
>
>	y = 3.141592654;
>	for (i = 0, d = 1 ; i < 5 ; i++, d *= 10) {
>		x = y / d;
>		printf ("%12g %12.1g %12.2g %12.3g %12.4g\n", x, x, x, x, x);
>	}
>	return (0);
>}
>
>Here's what *should* print (according to the ANSI standard).  And it *does*
>print this on our SUN 4.1.2, and HP-UX V8, systems:
>     3.14159            3          3.1         3.14        3.142
>    0.314159          0.3         0.31        0.314       0.3142
>   0.0314159         0.03        0.031       0.0314      0.03142
>  0.00314159        0.003       0.0031      0.00314     0.003142
> 0.000314159       0.0003      0.00031     0.000314    0.0003142
>
>And here's what the NeXT produces:
>    3.141593          3.1         3.14        3.142       3.1416
>    0.314159          0.3         0.31        0.314       0.3142
>    0.031416            0         0.03        0.031       0.0314
>    0.003142            0            0        0.003       0.0031
>    0.000314            0            0            0       0.0003
>
>For the umpteenth time, NeXT:
>1. The precision specifier for %g format is supposed to set the number of
>   significant digits in the printed number.
>
>2. Non-zero digits to the left of the decimal point *do* count towards
>   the number of significant digits (see the first line of the tables).
>
>3. Leading zeroes do not count towards the number of significant digits,
>   even when they are to the right of the decimal point (see the last
>   three lines of the tables).

Well, not to protect NeXT in regards to sleeping over important bug
reports (sometimes I also wonder how they set the priorities, altough
certainly nobody could claim they are otherwise lazy), I still wonder
if they are not right. Maybe there are just two opinions what ANSI-C
is supposed to do.

The C-Bible "The C Programming Language" by K+R, 2nd edition, ANSI-C
states the following on page 244:

f	double; decimal notation of the form [-]mmm.ddd, where the
	d's is specified by the precision. The default precision is 6;
	a precision of ) suppresses the decimal point.

e,E	double; decimal notation of the form [-]m.dddddd e[+-]xx or
	[-]mdddddd E[+-]xx, where the number of d's is specified by
	the precision. The default precision is 6; a precision of 0
	suppresses the decimal point.
g,G	double; %e or %E is used if the exponent is less than -4 or
	greater than or equal to the precision; otherwise %f is used.
	Trailing zeros and a trailing decimal point are not printed.


Now if they got it right, NeXT got it right. If K+R got it wrong,
well, then NeXT should correct the bug and tell Prentice Hall to
correct their bug as well.

Ronald

------------------------------------------------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man."   G.B. Shaw   |  rca@cs.brown.edu or antony@browncog.bitnet

Well, I suspect NeXT to be wrong in this case, since there is at least one
similar thing in fscanf().
Lets have a file with contents "a is:1.0\n" and try to read it with
fscanf(file,"a is:%lg\n",&d) into the double d: you'll get a return
value of 0 from fscanf and it stops at the '.', and I don't think it
is supposed to do so, or is it ? 

--
--------------------------------------------------------------------------------
Sebastian Mix, Eichhornstr.5-6 Apt.222, D-1000 Berlin 30, T: (030) 262 1811 /(a\
charon@cs.tu-berlin.de <-no NeXTmail yo-> charabib@w271zrz.zrz.tu-berlin.de \p)/
--------------------------------------------------------------------------------

rca@cs.brown.edu (Ronald C. Antony) writes:

>Well, not to protect NeXT in regards to sleeping over important bug
>reports (sometimes I also wonder how they set the priorities, altough
>certainly nobody could claim they are otherwise lazy), I still wonder
>if they are not right. Maybe there are just two opinions what ANSI-C
>is supposed to do.

>The C-Bible "The C Programming Language" by K+R, 2nd edition, ANSI-C
>states the following on page 244:

>g,G	double; %e or %E is used if the exponent is less than -4 or
>	greater than or equal to the precision; otherwise %f is used.
>	Trailing zeros and a trailing decimal point are not printed.


>Now if they got it right, NeXT got it right. If K+R got it wrong,
>well, then NeXT should correct the bug and tell Prentice Hall to
>correct their bug as well.

Well, you cannot have two ways of defining standard and The Standard
says explicitely about g, G conversions "... the precision specyfying
the number of significant digits".  K&R/2 chopped 7 lines of a
description from The Standard into 3 lines dropping an essential
piece of an information in the process.

What is more I know of many computers around which got it right.
Look for example at gawk sources and find out how many of them
need -DGFMT_WORKAROUND to alleviate problems of buggy libraries.
Library correctness does not seem to be very high on NeXT list.
BTW - I was also reporting this problem in early days of 2.1.
Everybody can see results. :-)

    Michal Jaegermann
    ntomczak@vega.math.ualberta.ca

In article <1992Nov11.012228.23372@access.usask.ca> eric@skatter.usask.ca writes:
>I reported this bug in December 1989, and when NeXTSTEP 2.0 came out,
>and when NeXTSTEP 2.1 arrived, and now that NeXTSTEP 3.0 has arrived ...
>IT STILL ISN'T FIXED!!!!!
>
>Here's an example program:

    NeXT is not using an ANSI printf() spec.... for example, NeXT's
    printf() does not return the number of characters output and atexit()
    doesn't work if you kill a process with -HUP.  In fact, quite a few
    functions aren't ansi and there seems to be no option to get an 'ansi'
    compatible library.

					-Matt
>--
>Eric Norum			eric@skatter.usask.ca
>Research Engineer		phone: (306) 966-6308
>Accelerator Laboratory
>University of Saskatchewan

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000