Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The Refrence C Compiler and a community website.

Reply
Thread Tools

The Refrence C Compiler and a community website.

 
 
James Kuyper
Guest
Posts: n/a
 
      10-07-2013
On 10/06/2013 06:57 AM, Gautam Sankrant wrote:
....
> -> It would necessarily be great, if a pure, fully featured pure C compiler written in C, acting as a reference implementation for the standard, is promoted among the community (Just like GHC). This endeavor would be great for students as well as developers.


What would such a "reference" compiler achieve that is not already
achieved by the existing open source implementations of C?

Much of what any C compiler does is outside the scope of the C standard.
Of those things that are in that scope, many are deliberately
unspecified. For each aspect unspecified by the standard, a reference
implementation would have to make a choice, and I'm very much afraid
that many people will derive the mistaken conclusion that the choices
made for the reference implementation are the only permitted ones. A
slightly less foolish, somewhat more plausible, but equally dangerous
misinterpretation would be that the choices made for the reference
implementation have somehow been endorsed as superior to the other
alternatives.

If that seems unlikely, consider that early versions of the standard
contained the full text of an excessively simple implementation of
rand(), that produced very low-quality random numbers. As a result, a
great many implementations used exactly that implementation. Some of the
implementors were simply being lazy, but others honestly thought,
without bothering to check, that it was endorsed by the C standard as an
acceptably good implementation.

Another example is asctime(), where the decision was made to define the
required behavior in terms of matching the behavior of example code. I
think this was a bad decision, but for some reason no one consulted me
in the matter .

Some people have mistakenly concluded that it is therefore required to
implement asctime() in exactly that way - they don't understand that the
phrase "using the equivalent of the following algorithm." allows for the
use of other algorithms. That example code has undefined behavior for
many possible values of the argument - usually in the form of reading or
writing before the beginning or past the end of an array. It is quite
feasible to implement asctime() in such a way as to detect such
problems, and to avoid them - it could return either a null pointer, or
a pointer to a string containing some indication of what the problem
was, or a pointer to a string residing in an array long enough to allow
for the longest possible output from each of the %d format specifiers.

Since the behavior in those cases is undefined in those cases, any
behavior is allowed for a fully conforming implementation of asctime(),
including, in particular, the behavior that would be produced by the
more useful alternatives I've suggested. Yet, I've seen people argue
that asctime() must be bug-for-bug compatible with the example code in
the standard.

I don't think it would be a good idea to create an entire reference
implementation of C filled with opportunities to trigger similar
misinterpretations.
--
James Kuyper
 
Reply With Quote
 
 
 
 
Noob
Guest
Posts: n/a
 
      10-07-2013
Robert Miles wrote:

> I've recently seen an article saying that GNU is planning to have
> their C compiler converted from being written in C to being written
> in C++


This has already happened (about a year ago).


http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html

From: Mark Mitchell <mark at codesourcery dot com>
Date: Sun, 30 May 2010 17:26:16 -0700
Subject: Using C++ in GCC is OK


http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html

From: Diego Novillo <dnovillo at google dot com>
Date: Thu, 02 Aug 2012 11:58:06 -0700
Subject: Merging the cxx-conversion branch into trunk

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-07-2013
James Kuyper <(E-Mail Removed)> writes:
[...]
> If that seems unlikely, consider that early versions of the standard
> contained the full text of an excessively simple implementation of
> rand(), that produced very low-quality random numbers. As a result, a
> great many implementations used exactly that implementation. Some of the
> implementors were simply being lazy, but others honestly thought,
> without bothering to check, that it was endorsed by the C standard as an
> acceptably good implementation.


Early versions? The C90, C99, and C11 standards all have the same
sample implementation of srand() and rand(). (It's not as bad as some;
at least the generated numbers don't alternate odd and even.)

> Another example is asctime(), where the decision was made to define the
> required behavior in terms of matching the behavior of example code. I
> think this was a bad decision, but for some reason no one consulted me
> in the matter .


Unfortunately, C code is probably the most unambiguous way to define the
algorithm. You could define it in English, but the description would be
much longer (and, unless it's written *very* carefully, likely even more
subject to argument).

> Some people have mistakenly concluded that it is therefore required to
> implement asctime() in exactly that way - they don't understand that the
> phrase "using the equivalent of the following algorithm." allows for the
> use of other algorithms. That example code has undefined behavior for
> many possible values of the argument - usually in the form of reading or
> writing before the beginning or past the end of an array. It is quite
> feasible to implement asctime() in such a way as to detect such
> problems, and to avoid them - it could return either a null pointer, or
> a pointer to a string containing some indication of what the problem
> was, or a pointer to a string residing in an array long enough to allow
> for the longest possible output from each of the %d format specifiers.
>
> Since the behavior in those cases is undefined in those cases, any
> behavior is allowed for a fully conforming implementation of asctime(),
> including, in particular, the behavior that would be produced by the
> more useful alternatives I've suggested. Yet, I've seen people argue
> that asctime() must be bug-for-bug compatible with the example code in
> the standard.


C90, C99, and C11 all say that asctime() must be implemented
"using the equivalent of the following algorithm", followed by C
code that implements asctime(). I've argued myself that C90 and
C99 require implementations to behave like the specified algorithm
for cases where that algorithms behavior is defined. For example,
it uses sprintf() with a "%d" format for 1900 + timeptr->ym_year,
with the implicit assumption that that's going to be 4 digits; if
it's fewer than 4 digits, that leaves room for other fields to be
outside their normal ranges. I've also argued that an implementation
can do anything it likes in cases where the presented algorithm's
behavior is undefined.

For example, under C90 and C99 rules, I believe that this program:

#include <stdio.h>
#include <time.h>
int main(void) {
struct tm t;
t.tm_sec = 999;
t.tm_min = 42;
t.tm_hour = 42;
t.tm_mday = 999;
t.tm_mon = 0;
t.tm_year = -1858;
t.tm_wday = 0;
fputs(asctime(&t), stdout);
}

must print:

Sun Jan999 42:42:999 42

(Look at the asctime() algorithm in the standard; its behavior is well
defined for those values.)

This is a disadvantage of describing the algorithm in C; any quirks in
the C code become requirements.

C11 adds this:

If any of the members of the broken-down time contain values
that are outside their normal ranges, the behavior of the
asctimefunction is undefined. Likewise, if the calculated year
exceeds four digits or is less than the year 1000, the behavior
is undefined.

which makes my program's behavior undefined.

Personally, I'd be happier if that paragraph started with "Except
that", since strictly speaking it contradicts the previous text.

> I don't think it would be a good idea to create an entire reference
> implementation of C filled with opportunities to trigger similar
> misinterpretations.


Agreed.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-07-2013
On 10/07/2013 11:14 AM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:
> [...]
>> If that seems unlikely, consider that early versions of the standard
>> contained the full text of an excessively simple implementation of
>> rand(), that produced very low-quality random numbers. As a result, a
>> great many implementations used exactly that implementation. Some of the
>> implementors were simply being lazy, but others honestly thought,
>> without bothering to check, that it was endorsed by the C standard as an
>> acceptably good implementation.

>
> Early versions? The C90, C99, and C11 standards all have the same
> sample implementation of srand() and rand(). (It's not as bad as some;
> at least the generated numbers don't alternate odd and even.)


I thought they'd fixed that in C2011 - I looked under rand() (7.22.2.1),
and didn't find it. It's actually on the next page of the standard,
under srand(), as I should have remembered.

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      10-07-2013
On Monday, October 7, 2013 4:14:52 PM UTC+1, Keith Thompson wrote:
> For example, it uses sprintf() with a "%d" format for 1900 + timeptr-
> ym_year, with the implicit assumption that that's going to be 4 digits; if
> it's fewer than 4 digits, that leaves room for other fields to be
> outside their normal ranges.
>

Yes, that's bug waiting to happen in year 10,000.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-09-2013
On Sun, 2013-10-06, Gautam Sankrant wrote:

....
> -> The community should host a website for C (similar in comparison
> to Python, Scala, Haskell, and notably C++)


I know Python has one, and I wouldn't be surprised if Scala and
Haskell do. But C++ does certainly not have a community website.

C++ is like C that way. Really old languages without a single an
implementation, a Benevolent Dictator for Life, or a big company
designing it around business plans, stuff like that. For better and
for worse.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      10-10-2013
On Sunday, October 6, 2013 11:12:06 PM UTC+8, (E-Mail Removed) wrote:
> On Sunday, October 6, 2013 11:45:56 PM UTC+10, Rui Maciel wrote:
>
> > (E-Mail Removed) wrote:

>
> >

>
> >

>
> >

>
> > > Wow, you are an enormous asshole. He's not whining, he just had an idea

>
> >

>
> > > he thought was good and wanted to share. Like seriously, way to justbe a

>
> >

>
> > > straight up horrible person.

>
> >

>
> > >

>
> >

>
> > > As for the OP, there are a few reasons why none of this is going to

>
> >

>
> > > happen. C is a great language. It's minimal and fast. The problem is

>
> >

>
> > > that it doesn't solve any problems any more.

>
> >

>
> >

>
> >

>
> > <snip more nonsense/>

>
> >

>
> >

>
> >

>
> > You're a poor troll.

>
> >

>
> >

>
> >

>
> >

>
> >

>
> > Rui Maciel

>
>
>
> What use case does C have for someone that this kind of community websitewould appeal to? I still write stuff in C, just did a big project that needed MPI and OpenMP (and didn't want to cross the border into C++ for a fewminor niceties), and it's good and fast and I like working with the GNU toolchain a lot.
>
>
>
> It seems like every month you see a new post somewhere saying that C isn't dead, you can still use it for modern projects, look someone wrote a C web framework that's inferior to the zillion others in Ruby/Python/Java/Scala/Go/whatever. How do you sell C to a developer? If you're not already writing it, it probably doesn't solve any problem you have.
>
>
>
> I'm not trying to troll, hell, help me understand if I'm so blatantly wrong, because I like C. It just seems to me that the type of thing the OP issuggesting doesn't fit what C currently offers.


For those who care about new
instructions of CPUs and OSes , C is still the number one portable assembler and system programming
language.

But in the higher level applications
programming languages in the
5-th or 6 -th gens are better in
applications.

 
Reply With Quote
 
mark.piffer@gmail.com
Guest
Posts: n/a
 
      10-10-2013
Am Sonntag, 6. Oktober 2013 15:45:56 UTC+2 schrieb Rui Maciel:
> (E-Mail Removed) wrote:
>
>
>
> > Wow, you are an enormous asshole. He's not whining, he just had an idea

>
> > he thought was good and wanted to share. Like seriously, way to just be a

>
> > straight up horrible person.

>
> >

>
> > As for the OP, there are a few reasons why none of this is going to

>
> > happen. C is a great language. It's minimal and fast. The problem is

>
> > that it doesn't solve any problems any more.

>
>
>
> <snip more nonsense/>
>
>
>
> You're a poor troll.
>
>
>
>
>
> Rui Maciel


No, he is Dan Pop's rightful heir. IMHO c.l.c can live with such individuals as long as their topical output is correct and to the point...

Mark
 
Reply With Quote
 
Albert van der Horst
Guest
Posts: n/a
 
      10-25-2013
In article <(E-Mail Removed)>,
David Brown <(E-Mail Removed)> wrote:
>
>So back to the topic, there is no reason at all why a C compiler should
>be implemented in C - there are other languages that better suited.
>(Historically, of course, most C compilers have roots that go back to a
>time when C /was/ the best choice of language for such programs.)


There is a reason for the GNU compilers to be written in C.
That is bootstrapping. I remembered having problems with the
c-compiler on SUN. The licensing just didn't work. But I could
use the SUN compiler we had a working license for, to compile GNU-c.
Then recompile GNU-c with the new compiler, and voila, you're
totally there.

Moving to c++ goes against the spirit of laying the ultimate weapon of
a portable compiler in the hands of the worlds programmers. It seems
that they think weapons are no longer necessary once you've conquered
the world. We'll see.

(I admit I'm a minimalist and I want to go to the roots and have
absolute control. See yourforth at bitbucket.org for a compiler defined
in assembler. One source file. )



Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The node.js Community is Quietly Changing the Face of Open Source Rodrick Brown Python 2 04-17-2013 04:47 PM
Re: The node.js Community is Quietly Changing the Face of Open Source Andrew Berg Python 4 04-17-2013 09:09 AM
Re: The node.js Community is Quietly Changing the Face of Open Source Terry Jan Reedy Python 1 04-17-2013 04:22 AM
Re: The node.js Community is Quietly Changing the Face of Open Source Sven Python 0 04-16-2013 04:41 PM
Re: The node.js Community is Quietly Changing the Face of Open Source Ned Batchelder Python 0 04-16-2013 04:25 PM



Advertisments