Date: Thu, 20 Mar 1997 19:55:11 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!village.org!imp, ponds!lambert.org!terry Cc: ponds!freebsd.org!hackers, ponds!wgold.demon.co.uk!james Subject: Re: Barb problem, FOUND Message-ID: <199703210055.TAA00572@lakes.water.net>
next in thread | raw e-mail | index | archive | help
>
> > : Just because a particular compiler is full of bugs doesn't mean that a
> > : construct allowed by the language spec is dubious. No way.
> >
> > I misspoke myself. There are several compilers that don't handle this
> > construct correctly. They generally don't whine about it, but they
> > generally do generate horrible code for this case. We saw a few years
> > ago that by removing the inline virtuals we had binaries that were
> > 500k! smaller. We also found with OI that lots of compilers had
> > subtle bugs with inline virtuals.
> >
> > Given all the problems that multiple compilers have implementing it
> > effectively, I think that it is as least unwise to use the construct.
> > In my book, that makes it dubious, but others will have a different
> > opinion.
>
> I remember when people were applying the same logic to dynamic scoping
> of stack variables:
>
> if( foo) {
> int my_dynamic_i;
>
> ...
> }
>
> Use of the register keyword on Lattice (later SASC) compilers:
>
> fum()
> {
> register int a, b, c, d, e, f; /* all the registers...*/
> register int q; /* XXX reuses register 'a'!!!*/
> }
Hey! As manager of the SAS/C compilers I object to that :-) :-)
[We like to keep our skeletons in the closet, thank you.]
Of course; you likely mean the ooolllddd ones - not the spiffy new
ones we have now :-) :-) We still use and actively maintain
those compilers - we just don't sell them to the public. The SAS
system on PC, mainframe (370 - MVS and VMS), MAC (68K and PowerPC)
is built with compilers that owe their existence to that offering.
[We still 'maintain' the amiga compiler via updates on-the-net. But,
you can't buy that one any more either.]
>
> And use of bit fields, unsigned values. and enumerated types (which
> didn't work in so many odd ways that it's not worth going into).
>
> Oh yeah: don't use sbrk() because you can't brk() back to the OS...
>
> 8-P.
>
> The argument is without merit: if a compiler is buggy, it should be
> fixed, or the vendor should be forced out of business by word of mouth.
My point here is that compiler vendors often do fix things. Sometimes,
even before they are forced out of business :-) :-) So, you'd due
well to report problems and #ifdef around them until they are repaired.
- Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703210055.TAA00572>