On Mar 25, 2007, at 7:12 AM, Gerhard Fiedler wrote:

>
>> And of course we can't talk to a "real" compiler vendor without taking
>> along a list of "special" features that their compiler has to support
>> before we can even consider looking at it.
>
> See... the "real" vendors don't seem to be a "real" alternative.

Sure they are.  "real vendors" are more interested in meeting customer
needs in return for the customers spending their dollars there.  If
you're big enough to dangle a potential couple of thousand seats of
compiler usage in front of a vendor, there's a good chance that they'll
do quite a bit for you...  Smaller companies have similar influence over
smaller compiler vendors.

> The problem doesn't seem to be open source, but the very
> specific features you guys need.
>
In general, they're not "very specific", but rather behaviors that
match older versions of the compiler(s).  As an example, sometime
around 1986, cisco engineers decided that that it would be a nice
idea if our version of printf() supported formats like "%i" and "%e"
for Internet and Ethernet addresses, respectively.  That was swell;
C was a language syntax that explicitly didn't include much in the
way of specifications for how libraries behaved...  Somewhat later,
standards organizations decided (probably correctly) that a language
spec with no library spec was ... less than ideal.  People started
to grumble about our printf() not being "standard."  More years went
by and "buffer overflows" became a hot topic, and compiler vendors
implemented CHECKING of the printf() arguments against the format
strings.  That was a nice feature and we wanted to benefit from it,
but of course our arguments didn't match the standard.  So we need
vendors to either support our specific argument sets (yuck) or
support a configurable method of specifying which argument types
go with which format specifiers for which printf-like functions (which
they ought to have done anyway, IMO, since the format string/arg list
concept is so generally useful...)  And more recently we have problems
with the way the preprocessor orders string concatenation WRT other
preprocessor operations like #include.  It was never called out in
the language specifications, but it used to work and now it doesn't.
(you USED to be able to have parts of the path for a #include come
from one string and parts from another string, and now you can't,
as far as I can tell...)

BillW

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist