181  4959 
On Sat, 20 Jan 2007 18:08:01 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>Mark McIntyre escreveu:
>On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>>You'll not find a market for a 1000 dollar drug dispensing device if a
single manufacturer manages to produce one at the 100 price mark.
Sure you will - if your drug is safer, more effective or has fewer
side-effects. Why do you think they sell Humira when Voltarol exists?
The point was that the cost is linked to the amount of safety. Cheap
drugs are either proven safe by longevity of previous patients, or
untested.
Non sequitur. We were discussing a drug *dispensing* device.
We weren't until you introduced it, but so what? Insert any object of
your choice into the sentence, its still valid.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Sat, 20 Jan 2007 23:23:52 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>
It is pointless, he doesn't seem to be able to read
Remind me who it was that was complaining about comments adding no
value, and containing nothing but abuse?
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On 20 Jan 2007 13:47:13 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
[...]
>Secondly he noted that its false that _all_ memory overruns are fatal.
This is completely true, your hyperbole and other nonsense
notwithstanding. Consider a simple case - two adjacent arrays of 10
chars each. Overwriting the 1st char of the 2nd array by mistake will
be annoying maybe, confusing possibly. Fatal no.
[...]
It's entirely possible that overwriting the first element of a char
array could have fatal consequences.
Absolutely, and at no point did I intend to infer othewise (I seem to
recall posting an example elsethread). I was disputing the claim that
all array overruns were 100% fatal.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
On Sat, 20 Jan 2007 23:21:58 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre a écrit :
>On Sat, 20 Jan 2007 18:25:21 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>
I don't see your point. You mean C is just for writing games?
Idiot.
What an argument!
Did you expect anything better when you make idiotic statements?
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mark McIntyre <ma**********@spamcop.netwrites:
On 20 Jan 2007 13:47:13 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
Mark McIntyre <ma**********@spamcop.netwrites:
[...]
Secondly he noted that its false that _all_ memory overruns are fatal.
This is completely true, your hyperbole and other nonsense
notwithstanding. Consider a simple case - two adjacent arrays of 10
chars each. Overwriting the 1st char of the 2nd array by mistake will
be annoying maybe, confusing possibly. Fatal no.
[...]
It's entirely possible that overwriting the first element of a char
array could have fatal consequences.
Absolutely, and at no point did I intend to infer othewise (I seem to
recall posting an example elsethread).
As I acknowledged in the part you snipped.
I was disputing the claim that
all array overruns were 100% fatal.
And quite correctly. But what you wrote above:
| Consider a simple case - two adjacent arrays of 10
| chars each. Overwriting the 1st char of the 2nd array by mistake will
| be annoying maybe, confusing possibly. Fatal no.
*could* be read to imply that such overwriting is *never* fatal. I
accept that you know that's not the case, and that it's not what you
meant to imply, but it's what your words "Fatal no" implied to me, and
potentially to others.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
"Malcolm McLean" <re*******@btinternet.comwrote in message
news:Fe*********************@bt.com...
>
"David T. Ashley" <dt*@e3ft.comwrote in message
>The handling of multi-dimensional arrays in 'C' is pure genius. It was a
good call to realize that (with [i][j][k], for example), the compiler
only needs to know about the dimensioning of k in order to operate using
j (i has nothing to do with it).
No it isn't.
An image is a two-dimensional object if anything is.
However what good is an image algorithm that will only work on one size of
image? In practise, you need to pass the dimensions in at run-time. Which
means treating it as a 1d array and manually calculating the offset.
It would have been very easy to add some decent syntax to the language.
Again, in some cases we're back to the argument of choice.
I believe some languages (like FORTRAN) allow you to pass variable-sized
arrays and the compiler will deal with the row and column indexing.
The method in 'C' in that case is going to resemble the method you
mentioned -- treating it as a 1d array and manually calculating the offset.
But really, when you get to the nuts and bolts of it, the same thing will be
happening under the hood in 'C' or FORTRAN, just that in 'C' you write the
code yourself.
In every language, you have to decide what to include and not to include. A
variable-dimension array is a complex construct, and it is a reasonable
decision not to support it directly as part of the language (for the same
reason that linked lists, binary trees, and so on are left to the
programmer).
Not including support for variable-dimension arrays was a good decision.
This is a complex data structure, and best left out of the language proper.
And really, when you get down to it, it can get even more complex. In
addition to indexing, there is the possibility of sparse arrays or arrays
likely to be in other special forms where a more compact or efficient
representation can be adopted. Best to leave that to the programmer ...
--
David T. Ashley (dt*@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
"Mark McIntyre" <ma**********@spamcop.netwrote in message
On Sat, 20 Jan 2007 16:59:00 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>>You'll not find a market for a 1000 dollar drug dispensing device if a
single manufacturer manages to produce one at the 100 price mark.
Sure you will - if your drug is safer, more effective or has fewer
side-effects. Why do you think they sell Humira when Voltarol exists?
The point was that the cost is linked to the amount of safety. Cheap
drugs are either proven safe by longevity of previous patients, or
untested.
Exactly.
If we could produce guaranteed bug-free code then the pharmaceutical
industry would demand such code, whatever the price. The fact is we can't,
and the example was a real one - deaths have occured because some dispensing
device delivered the wrong quantity of a radioactive medicine.
Techniques for verifying code are very costly. Whilst bugs are also costly,
and you can certainly argue about the amount of money you should spend on
verification, it obviously depends on your application. A game that crashes
once every two months is acceptable, a drug dispenser that kills a patient
every two months is not.
I've got a list of five bugs in BASICdraw. I wouldn't have deliberately put
them in, but none of them make the program unusable. However they can be
irritating. By getting a second person involved, they could probably have
been avoided but I, sob, have no friends, so in fact the program would not
have been released at all.
-- http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean wrote:
>
Exactly.
If we could produce guaranteed bug-free code then the pharmaceutical
industry would demand such code, whatever the price. The fact is we can't,
and the example was a real one - deaths have occured because some dispensing
device delivered the wrong quantity of a radioactive medicine.
Techniques for verifying code are very costly. Whilst bugs are also costly,
and you can certainly argue about the amount of money you should spend on
verification, it obviously depends on your application. A game that crashes
once every two months is acceptable, a drug dispenser that kills a patient
every two months is not.
Hi Malcolm,
A good point. Besides medical devices I was wondering how applications
that have the potential to cause a great loss of life (such as missile
command and control systems, nuclear power systems, etc.) deal with
software? Will the people who develop these systems spend any amount of
money to make a very robust fault tolerant system or do they also cut
corners and have a minimum threshold of "acceptable bugs"?
Zach
Zach wrote:
Malcolm McLean wrote:
>>Exactly.
If we could produce guaranteed bug-free code then the pharmaceutical
industry would demand such code, whatever the price. The fact is we can't,
and the example was a real one - deaths have occured because some dispensing
device delivered the wrong quantity of a radioactive medicine.
Techniques for verifying code are very costly. Whilst bugs are also costly,
and you can certainly argue about the amount of money you should spend on
verification, it obviously depends on your application. A game that crashes
once every two months is acceptable, a drug dispenser that kills a patient
every two months is not.
Hi Malcolm,
A good point. Besides medical devices I was wondering how applications
that have the potential to cause a great loss of life (such as missile
command and control systems, nuclear power systems, etc.) deal with
software? Will the people who develop these systems spend any amount of
money to make a very robust fault tolerant system or do they also cut
corners and have a minimum threshold of "acceptable bugs"?
It's not uncommon in safety critical systems (flight control for
example) to use three duplicate components sourced from different
vendors and use majority voting to minimise the risk of an undetected bug.
Last time I worked with such systems, ADA was the preferred language.
--
Ian Collins.
Mark McIntyre wrote:
On 18 Jan 2007 21:41:55 -0800, in comp.lang.c , "Zach"
<ne****@gmail.comwrote:
Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:
http://en.wikipedia.org/wiki/Critici...mming_language
Amusing article. Many of the 'weaknesses' and 'lacks' of C are IMHO
actually benefits which keep the language lean and portable.
Much of the "justification" given for these being weaknesses relies on
either an assumption that another language is superior, or upon stuff
that was true 20 years ago (such as the #include model slowing down
compilation - come on, I've not had a problem with that since oh, the
nineties). The argument based upon design decisions taken by the C++
developers was humorous. Essentially "C is bad because we had to copy
it..."
I've amended it mildly, to try to point ouf that the viewpoint
presented in the article is highly subjective and disputed by many
experienced programmers. I expect my amendments to be removed by
someone fairly switfly.
Indeed they have by someone who uses the name
DAGwyn.
Ian Collins wrote:
>
Last time I worked with such systems, ADA was the preferred language.
Oh very interesting. I wonder which language is more in use these days:
Lisp or ADA?
Zach
Zach said:
Ian Collins wrote:
>>
Last time I worked with such systems, ADA was the preferred language.
Oh very interesting. I wonder which language is more in use these days:
Lisp or ADA?
Perhaps you should ask the Lisp bloke and the ADA lass to compare
timesheets.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
In article <11**********************@a75g2000cwd.googlegroups .com>, Zach
<ne****@gmail.comwrites
>Can someone give a detailed rejoinder to this. Would also be nice if
someone updates the wiki page so that readers get the other perspective
and don't get the wrong impression about C:
http://en.wikipedia.org/wiki/Critici...mming_language
Zach
It just goes to show how poor wikipeadia is as a source.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Torek wrote:
<snip>
In article <51**************@mid.individual.net>
Ian Collins <ia******@hotmail.comwrote:
Do you think the common Unix function alloca(), which allocates memory
from the stack should have been standardised?
It can be a direct replacement for VLAs with failure detection and I've
often wondered why it wasn't included in the standard library.
For alloca() to be reliable, the compiler has to recognize calls
to it. Try something like:
foo(bar(),
128, alloca(128),
baz(i, alloca(i), j),
32, alloca(32),
zog(42));
on a straightforward Intel x86 compiler that does not recognize
alloca(), for instance, and then observe the carnage. :-) (The
problem is that each alloca() call adjusts the stack while the
compiler is building the stack that is going to be used to call
the functions involved. The stack thus built interleaves "alloca
created stack space" with "compiler created stack space", and
everything goes haywire when pieces of this are removed. [...]
<Complete and utter nitpick>
It's my understanding that it's not necessary for "pieces to be
removed" to create havoc. Rather, the interleaving of alloca-created
stack space and compiler-created function argument stack space (for
passed-by-stack arguments in whatever ABI we're talking about-- in the
case of register-rich architectures with a register-passing ABI it can
sometimes not matter, depending on the number of function arguments
and/or whether its variadic) directly creates problems for called
functions when they find that space normally used for argument passing
has been instead allocated for another purpose behind its back.
For classic x86 stuff, and perhaps mips o32 stuff (off the top of my
head), since a ton of things are passed via stack, alloca as a function
argument may result in the callee "finding" the wrong arguments.
Please correct me if I'm mistaken.
Mark F. Haigh mf*****@sbcglobal.net
Greetings,
Cesar Rabak wrote:
kyle york escreveu:
>Greetings,
jacob navia wrote:
[snipped]
>>My argument is that any writing outside the bounds of
an array is 100% fatal and that specially in embedded
software defensive programming is necessary.
The ``is 100% fatal'' is completely false, the defensive programming
is necessary is a big, ``Duh!'' There are numerous cases where writing
out of the bounds of the array is innocuous, or at worst will cause
the program to simply fail.
Interesting approach! I think there's a company in Redmond that probably
has a poster in some wall with this mantra!
Oh goodie, I guess I'll have to add yet another corollary to my
repertoire, just change `it's always been done that way'' to ``oh, you
must work in redmond''
For what it's worth, and clearly neither you nor Jacob care, I put it
checks where necessary, and don't bother when it's clearly not. For
example, let's say I've a function to clear an array whose base it ptr
and size is sz:
void clear(size_t sz, char *ptr)
Knowing that everything from 0 through sz - 1 is allowed, a 'C'
programmer might write a body such as:
while (sz--) {
ptr[sz] = 0;
}
(on my platform, that requires 6 instructions)
whereas a programmer in your language would be required the (implicit)
overhead of:
size_t ii;
for (ii = 0; ii < sz; ii++) {
if ((ii >= 0) && (ii < sz)) {
ptr[ii] = 0;
}
}
which requires far more instructions, yet I fail to see how it's any
more secure. When one has only 1 or 2K with which to work, one wants to
make the best of it.
--
Kyle A. York
Kyle's corollary: As a technical discussion grows longer, the
probability of someone stating, ``But it's always been done that way,''
approaches one.
Ian Collins wrote:
You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them.
In the operator overloading implementation of lcc-win32 you can define
typedef struct tagArray {
size_t siz;
void *data;
int element_size;
unsigned flags;
} Array;
Then you do the operator overloading using that structure
instead of C arrays. This means that array accesses are
checked, and you have just to change
int tab[45];
Array tab = newArray(45,sizeof(int));
and leave the rest of the code as it was before.
I'm afraid you are pissing
in the wind if you try to get either of these features added to C. They
exist elsewhere, so if you want them, you have to go there.
I have added them to my compiler system lcc-win32. It is a very small
modification of the compiler. http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Ian Collins wrote:
>You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them.
In the operator overloading implementation of lcc-win32 you can define
typedef struct tagArray {
size_t siz;
void *data;
int element_size;
unsigned flags;
} Array;
Then you do the operator overloading using that structure
instead of C arrays. This means that array accesses are
checked, and you have just to change
int tab[45];
Array tab = newArray(45,sizeof(int));
and leave the rest of the code as it was before.
Which is how it could be done in C++.... As I keep saying, why add
baggage to C when it's available elsewhere? I'm sure part of the
problem with C99 adoption is the added complexity. So if a hypothetical
new C standard where to add yet more, it would be even less portable
than the current one.
I haven't looked, but I'd wager there are more platforms with a C++ or
EC++ compiler than there are with a C99 compiler. Which is why I keep
saying if you want a feature found in C++ and not C, use C++ and don't
try for a half arsed solution in C.
>I'm afraid you are pissing
in the wind if you try to get either of these features added to C. They
exist elsewhere, so if you want them, you have to go there.
I have added them to my compiler system lcc-win32. It is a very small
modification of the compiler.
http://www.cs.virginia.edu/~lcc-win32
If you want to push for a feature to be added to C, a single platform
compiler probably isn't the best place to add it.
--
Ian Collins.
"Zach" <ne****@gmail.comwrote in message
Malcolm McLean wrote:
>>
Exactly.
If we could produce guaranteed bug-free code then the pharmaceutical
industry would demand such code, whatever the price. The fact is we
can't,
and the example was a real one - deaths have occured because some
dispensing
device delivered the wrong quantity of a radioactive medicine.
Techniques for verifying code are very costly. Whilst bugs are also
costly,
and you can certainly argue about the amount of money you should spend on
verification, it obviously depends on your application. A game that
crashes
once every two months is acceptable, a drug dispenser that kills a
patient
every two months is not.
Hi Malcolm,
A good point. Besides medical devices I was wondering how applications
that have the potential to cause a great loss of life (such as missile
command and control systems, nuclear power systems, etc.) deal with
software? Will the people who develop these systems spend any amount of
money to make a very robust fault tolerant system or do they also cut
corners and have a minimum threshold of "acceptable bugs"?
The problem is that no-one knows how to verify that non-trivial software
works as specified. Endless methods have been proposed, and whilst some of
them have had some success, none has eliminated errors or cost overruns. So
Mars Rovers still malfunctioin due to bugs, not in this case causing loss of
life, but certainly wasting millions of dollars.
In article <11*********************@38g2000cwa.googlegroups.c om>, Zach
<ne****@gmail.comwrites
>Ian Collins wrote:
>>
Last time I worked with such systems, ADA was the preferred language.
Oh very interesting. I wonder which language is more in use these days:
Lisp or ADA?
ADA by a long way I should think. It is the de-facto language for safety
critical systems.
I see Ada used quite a bit.
Lisp gets mentioned occasionally by academics.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <11**********************@m58g2000cwm.googlegroups .com>, Zach
<ne****@gmail.comwrites
>Malcolm McLean wrote:
>>
Exactly.
If we could produce guaranteed bug-free code then the pharmaceutical
industry would demand such code, whatever the price. The fact is we can't,
and the example was a real one - deaths have occured because some dispensing
device delivered the wrong quantity of a radioactive medicine.
Techniques for verifying code are very costly. Whilst bugs are also costly,
and you can certainly argue about the amount of money you should spend on
verification, it obviously depends on your application. A game that crashes
once every two months is acceptable, a drug dispenser that kills a patient
every two months is not.
Hi Malcolm,
A good point. Besides medical devices I was wondering how applications
that have the potential to cause a great loss of life (such as missile
command and control systems, nuclear power systems, etc.)
Elevator controls, central heating boiler controls , systems in cars
and trucks, medical systems, microwave cookers, factory control systems
fire and security systems, etc etc
There is a Lot more critical embedded SW out there that you probably
realise,.
>deal with
software? Will the people who develop these systems spend any amount of
money to make a very robust fault tolerant system
Yes.
or do they also cut
corners and have a minimum threshold of "acceptable bugs"?
No.
They have to work to standards such as FDA, 60601-14, 60730, Do178B,
61508-3 etc which require documented procedures, specific methods and
certified tools etc etc .
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Ian Collins a écrit :
jacob navia wrote:
>>Ian Collins wrote:
>>>You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them.
In the operator overloading implementation of lcc-win32 you can define
typedef struct tagArray {
size_t siz;
void *data;
int element_size;
unsigned flags;
} Array;
Then you do the operator overloading using that structure
instead of C arrays. This means that array accesses are
checked, and you have just to change
int tab[45];
Array tab = newArray(45,sizeof(int));
and leave the rest of the code as it was before.
Which is how it could be done in C++.... As I keep saying, why add
baggage to C when it's available elsewhere? I'm sure part of the
problem with C99 adoption is the added complexity. So if a hypothetical
new C standard where to add yet more, it would be even less portable
than the current one.
I haven't looked, but I'd wager there are more platforms with a C++ or
EC++ compiler than there are with a C99 compiler. Which is why I keep
saying if you want a feature found in C++ and not C, use C++ and don't
try for a half arsed solution in C.
C++ is not a simple language and it is object oriented.
Two characteristics that make it impossible to use.
My opinion of course.
>
>>>I'm afraid you are pissing
in the wind if you try to get either of these features added to C. They
exist elsewhere, so if you want them, you have to go there.
I have added them to my compiler system lcc-win32. It is a very small
modification of the compiler.
http://www.cs.virginia.edu/~lcc-win32
If you want to push for a feature to be added to C, a single platform
compiler probably isn't the best place to add it.
Maybe not.
jacob navia <ja***@jacob.remcomp.frwrites:
Ian Collins wrote:
You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them.
In the operator overloading implementation of lcc-win32 you can
[snip]
Yes, a language with operator overloading lets you do thing that you
can't do as conveniently in C.
Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.
(Now you can falsely accuse me of wanting C to die.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia wrote:
Ian Collins a écrit :
>jacob navia wrote:
>>Ian Collins wrote:
I haven't looked, but I'd wager there are more platforms with a C++ or
EC++ compiler than there are with a C99 compiler. Which is why I keep
saying if you want a feature found in C++ and not C, use C++ and don't
try for a half arsed solution in C.
C++ is not a simple language and it is object oriented.
So what? Just use the bits you want. The struct you posted is legal in
both C and C++. Adding overloaded operators is simple and legal in C++
and not in C.
One thing the two languages do share is the underlying philosophy of you
don't pay for what you don't use. You persist in ignoring this.
--
Ian Collins.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.
That seems to imply that there's no newsgroup for discussing possible
extensions to C unless you want to talk about standardising them,
which is a bit unfortunate, as in a language as mature as C extensions
should be experimented with long before standardisation is considered.
comp.lang.c seems like the most natural home for such discussions.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963. ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.
That seems to imply that there's no newsgroup for discussing possible
extensions to C unless you want to talk about standardising them,
which is a bit unfortunate, as in a language as mature as C extensions
should be experimented with long before standardisation is considered.
comp.lang.c seems like the most natural home for such discussions.
Extensions provided by lcc-win32 can be discussed in
comp.compilers.lcc. Extensions provided by gcc can be discussed in
the various gcc newsgroups. And so on.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Extensions provided by lcc-win32 can be discussed in
comp.compilers.lcc. Extensions provided by gcc can be discussed in
the various gcc newsgroups. And so on.
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963. ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
Extensions provided by lcc-win32 can be discussed in
comp.compilers.lcc. Extensions provided by gcc can be discussed in
the various gcc newsgroups. And so on.
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
I've modified the subject header, since the discussion seems to be
veering in a new direction.
The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.
If there's a proposal to alter the (somewhat informal) topicality
guidelines, I'd have no problem discussing that, though I'd personally
oppose any major changes. I can't think of a simple set of guidelines
that would permit discussion of the C-like language implemented by,
for example, lcc-win32, but would not permit discussion of the C-like
language known as C++.
Note that both lcc and gcc have their own newsgroups. Other
implementations may not, but the lack of an appropriate forum is not
the resposibility of this one.
(Meta-discussions about topicality, such as this one, are
traditionally considered to be topical.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>>
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
I've modified the subject header, since the discussion seems to be
veering in a new direction.
The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.
How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
--
Ian Collins.
In article <ep***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.
That seems to imply that there's no newsgroup for discussing possible
extensions to C unless you want to talk about standardising them,
which is a bit unfortunate, as in a language as mature as C extensions
should be experimented with long before standardisation is considered.
comp.lang.c seems like the most natural home for such discussions.
You're not from here, is you?
(... like discussing abortion at a KofC meeting ...)
Ian Collins <ia******@hotmail.comwrites:
Keith Thompson wrote:
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
I've modified the subject header, since the discussion seems to be
veering in a new direction.
The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.
How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
I suppose POSIX might qualify as such an extension, but of course
there are more appropriate newsgroups for that.
But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
>>Keith Thompson wrote:
>>>ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
I've modified the subject header, since the discussion seems to be
veering in a new direction.
The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.
How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
I suppose POSIX might qualify as such an extension, but of course
there are more appropriate newsgroups for that.
But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
Unfortunately this topic (proposed extensions) gets bounced as off topic
both here and on c.s.c. I still think new ideas can be an interesting
diversion here.
--
Ian Collins.
Ian Collins <ia******@hotmail.comwrites:
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
[...]
>How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
I suppose POSIX might qualify as such an extension, but of course
there are more appropriate newsgroups for that.
But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
Unfortunately this topic (proposed extensions) gets bounced as off topic
both here and on c.s.c. I still think new ideas can be an interesting
diversion here.
Proposed extensions *beyond the standard* would be off-topic in c.s.c;
proposed *changes* to the standard itself would be topical.
In this case, one poster insists on discussing a specific extension
(operator overloading) implemented in a single compiler. I haven't
seen him or anyone else advocating that it be implemented in other
compilers, except possibly as a future standard feature.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
jacob navia wrote:
Ian Collins a écrit :
jacob navia wrote:
>Ian Collins wrote:
You still hit the fundamental problem that C arrays are not objects, so
you can't bind overloaded operators to them.
In the operator overloading implementation of lcc-win32 you can define
<snip>
Which is how it could be done in C++.... As I keep saying, why add
baggage to C when it's available elsewhere? I'm sure part of the
problem with C99 adoption is the added complexity. So if a hypothetical
new C standard where to add yet more, it would be even less portable
than the current one.
<snip>
C++ is not a simple language and it is object oriented.
You can certainly use a simpler, C-like subset of it. Much of it's
complexity seems to come from multiple inheritence and templates, and
they're certainly not needed for many programs.
Also C++, according to Stroustrup, is a multi-paradigm language. You
need not use the OO features, if you don't want to, or use a select
subset of it.
Chris Hills wrote:
Zach <ne****@gmail.comwrites
>Can someone give a detailed rejoinder to this. Would also be nice
if someone updates the wiki page so that readers get the other
perspective and don't get the wrong impression about C:
http://en.wikipedia.org/wiki/Critici...mming_language
It just goes to show how poor wikipeadia is as a source.
I just got around to taking a look, and I see nothing highly
objectionable. The authors have failed to separate features from
the language, viz the silly complaints about garbage collection and
header inclusion. They also have appreciable bias towards OO style
languages.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
In article <ep***********@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<ri*****@cogsci.ed.ac.ukwrites
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>Extensions provided by lcc-win32 can be discussed in
comp.compilers.lcc. Extensions provided by gcc can be discussed in
the various gcc newsgroups. And so on.
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
-- Richard
I agree. This is a good place for informal discussions of this sort.
First see what the user community think then take it to comp.c.std
Especially where the extension is not going to be compiler or target
specific.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills <ch***@phaedsys.orgwrites:
[...]
I agree. This is a good place for informal discussions of this
sort. First see what the user community think then take it to
comp.c.std
Especially where the extension is not going to be compiler or target
specific.
What extensions that have been discussed here are not compiler or
target specific?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
Just because something might, if successful, be considered in a future
standard, that doesn't mean that comp.std.c is the appropriate place
to discuss it now. Language design isn't standardisation, nor is it
necessarily compiler-specific. If people want to ask questions about,
say, how to use lcc's extensions, then an lcc group is appropriate.
But if they want to discuss whether such extensions are a good idea,
or how they might be done differently, then comp.lang.c is a good
place.
Look at the current discussions in comp.std.c: they're mostly
discussions about exactly what the wording of the standard implies.
If operator overloading were added to C, eventually there would come a
time for that sort of discussion, but we're not there yet.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>What extensions that have been discussed here are not compiler or
target specific?
Pointer addition :-)
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>I agree. This is a good place for informal discussions of this
sort. First see what the user community think then take it to
comp.c.std
Especially where the extension is not going to be compiler or target
specific.
What extensions that have been discussed here are not compiler or
target specific?
Are you ever going to grow up?
In article <ep**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:
>You're not from here, is you?
I've been here, on and off, for 20 years.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <ep***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>In article <ep**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:
>>You're not from here, is you?
I've been here, on and off, for 20 years.
I know. Which is what makes it so interesting.
You were arguing a perfectly reasonable position, something which,
obviously, the regs will not tolerate.
Richard Tobin a écrit :
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
Just because something might, if successful, be considered in a future
standard, that doesn't mean that comp.std.c is the appropriate place
to discuss it now. Language design isn't standardisation, nor is it
necessarily compiler-specific. If people want to ask questions about,
say, how to use lcc's extensions, then an lcc group is appropriate.
But if they want to discuss whether such extensions are a good idea,
or how they might be done differently, then comp.lang.c is a good
place.
Exactly.
And the arguments I have heared are (mostly) that it is
off topic, non portable, can't discuss it here blah blah blah...
The extensions I propose are intended for the C language as a whole.
The implementation in lcc is just to prove that their implementation
is very easy and doesn't have any particular difficulty.
In article <ep***********@pc-news.cogsci.ed.ac.uk>, Richard Tobin
<ri*****@cogsci.ed.ac.ukwrites
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>Standard C doesn't support operator overloading. If you want to
discuss some language that does, find a newsgroup for that language.
If you want to advocate adding operator overloading to a future C
standard, take it to comp.std.c.
That seems to imply that there's no newsgroup for discussing possible
extensions to C unless you want to talk about standardising them,
which is a bit unfortunate,
I agree. No compiler AFAIK is normally used in PURE Standard C mode
because none of them fully implement C99. When you query that here with
the pedants they say this ng is for:
K&R C, K&R C2, ANSI C 89, ISO C 90, C95/6 C99 or any other version of
the C standard no mater how obsolete.
basically any version of the C standard from K&R C onwards but not C as
actually used by 90% of the C community.
I can not see any justification for discussion ANSI C 89 or the original
K&R (both of which are obsolete) but not C as currently used. There
are a few holier than thou pedants on there who want to artificially
restrict the NG to a sub set of C that most do not use. But then
pointlessly widen it to various obsolete versions of the standard.
If you want to discuss Standard C it should be ISO C99 and probably ISO
C 95 (as the previous and most widley used version) not all the other
obsolete versions from over a decade or two ago. Nor the local BSI, DIN
ANSI versions they are not the International Standard.
It is discussions like "overloading C" that lead to the extensions of
the language. Some make it into the ISO standard some don't .
as in a language as mature as C extensions
should be experimented with long before standardisation is considered.
comp.lang.c seems like the most natural home for such discussions.
-- Richard
I agree.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
>Keith Thompson wrote:
>>Ian Collins <ia******@hotmail.comwrites:
[...]
>>>How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
I suppose POSIX might qualify as such an extension, but of course
there are more appropriate newsgroups for that.
But as far as language (as opposed to library) extensions are
concerned, I can't think of an example of an extension that isn't
either compiler-specific or intended for a new standard. The operator
overloading extension that triggered this, for example, is (currently)
specific to lcc-win32. Is anyone suggesting that operator overloading
should be implemented as an extension by multiple compilers, but not
considered for a future standard?
Unfortunately this topic (proposed extensions) gets bounced as off topic
both here and on c.s.c. I still think new ideas can be an interesting
diversion here.
Proposed extensions *beyond the standard* would be off-topic in c.s.c;
proposed *changes* to the standard itself would be topical.
In this case, one poster insists on discussing a specific extension
(operator overloading) implemented in a single compiler. I haven't
seen him or anyone else advocating that it be implemented in other
compilers, except possibly as a future standard feature.
You must have missed the main thing then. Jacob Navia keeps repeating
and repeating, that he wants operator overloading and whatnot
in C, and presents his compiler as an example of how it can be
and how cool it is. Maybe it's only my reading of his posts,
I admit I didn't try to analyze them as carefully as you probably
did, but my summary of what I read is "C must not be as bad language
as it is, it must have operator overloading and strings and arrays which
remember their length".
As far as I remember he didn't advocate implementing it in other
compilers, true; but it's only you who talks about other compilers;
Jacob talks fancier stuff, "future and present of C language".
Yevgen
On Tue, 23 Jan 2007 14:40:03 +1300, Ian Collins <ia******@hotmail.com>
wrote:
>Keith Thompson wrote:
>ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>>>
That might be appropriate when first implementing an extension, but
surely there is scope for discussions that are neither limited to a
single implementation nor proposed for standardisation?
I've modified the subject header, since the discussion seems to be
veering in a new direction.
The general (though not universal) consensus in this newsgroup is, and
has been for a long time, that compiler-specific extensions are
off-topic. It's not *quite* that simple; for example, discussion of
the fact that the standard permits extensions, and of the restrictions
it places on them for a conforming implementation, is topical. But a
detailed discussion of, say, gcc's syntax for inline assembly
language, or of functions specified by POSIX but not by the C
standard, is not.
How about non-compiler specific extensions? My understanding of the
subject of Richard's post was the topicality of proposed extensions to C.
Don't such discussions belong in comp.std.c?
>
This group has a good number of well qualified and highly opinionated
regulars who would make a good sounding board for these ideas!
--
Al Balmer
Sun City, AZ ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ep**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:
[snip]>
I've been here, on and off, for 20 years.
Please don't feed the troll.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Chris Hills <ch***@phaedsys.orgwrites:
[...]
I can not see any justification for discussion ANSI C 89 or the
original K&R (both of which are obsolete) but not C as currently used.
There are a few holier than thou pedants on there who want to
artificially restrict the NG to a sub set of C that most do not
use. But then pointlessly widen it to various obsolete versions of the
standard.
[...]
Perhaps we can have this discussion without insulting other
participants.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Chris Hills a écrit :
I agree. No compiler AFAIK is normally used in PURE Standard C mode
because none of them fully implement C99. When you query that here with
the pedants they say this ng is for:
K&R C, K&R C2, ANSI C 89, ISO C 90, C95/6 C99 or any other version of
the C standard no mater how obsolete.
basically any version of the C standard from K&R C onwards but not C as
actually used by 90% of the C community.
I can not see any justification for discussion ANSI C 89 or the original
K&R (both of which are obsolete) but not C as currently used. There
are a few holier than thou pedants on there who want to artificially
restrict the NG to a sub set of C that most do not use. But then
pointlessly widen it to various obsolete versions of the standard.
If you want to discuss Standard C it should be ISO C99 and probably ISO
C 95 (as the previous and most widley used version) not all the other
obsolete versions from over a decade or two ago. Nor the local BSI, DIN
ANSI versions they are not the International Standard.
It is discussions like "overloading C" that lead to the extensions of
the language. Some make it into the ISO standard some don't .
This is a very good description of the problem in this NG.
Instead of a forward looking spirit like (for instance)
in the C++ groups, any discussion about the
problems inherent into the language will be dismissed as
just a bug of incompetent programmers or "off topic".
This way the C language doesn't have any forum where
a possible solution to the languages weakness can be proposed.
A possible solution goes as a matter of course AFTER
people acknowledge that there is a problem. If we find that
memory overwrites are not 100% fatal, then, we say that they
are the result of "incompetent programmers" there is
nothing to be changed and nothing to be added/modified
The crux of the matter is just to hire those wonderful
programmers (that are here in abundance as it seems) that
are "competent" and never in their career have had a
memory overwrite or a array out of bounds indexing
error.
And actual FACTS like the total loss of Mars Global Surveyor
because of a memory overwrite will be dismissed as the
fact of an "incompetent" programmer. NASA has a lot of them
as it seems...
This is a similar situation when I pointed out to the problems
of using p = malloc(n*sizeof(*p)). The same people starting
arguing that there isn't any UB (because overflow is
well defined for unsigned even if the result is mathematically
wrong). And the "incompetent programmer" came up again. Nothing
was said that the language doesn't have anything to test overflow!
I will write a wrap up discussion article later on, even if
many people here do not like this kind of discussions.
jacob
jacob navia wrote:
Chris Hills a écrit :
I agree. No compiler AFAIK is normally used in PURE Standard C mode
because none of them fully implement C99. When you query that here with
the pedants they say this ng is for:
K&R C, K&R C2, ANSI C 89, ISO C 90, C95/6 C99 or any other version of
the C standard no mater how obsolete.
basically any version of the C standard from K&R C onwards but not C as
actually used by 90% of the C community.
I can not see any justification for discussion ANSI C 89 or the original
K&R (both of which are obsolete) but not C as currently used. There
are a few holier than thou pedants on there who want to artificially
restrict the NG to a sub set of C that most do not use. But then
pointlessly widen it to various obsolete versions of the standard.
If you want to discuss Standard C it should be ISO C99 and probably ISO
C 95 (as the previous and most widley used version) not all the other
obsolete versions from over a decade or two ago. Nor the local BSI, DIN
ANSI versions they are not the International Standard.
It is discussions like "overloading C" that lead to the extensions of
the language. Some make it into the ISO standard some don't .
This is a very good description of the problem in this NG.
Instead of a forward looking spirit like (for instance)
in the C++ groups, any discussion about the
problems inherent into the language will be dismissed as
just a bug of incompetent programmers or "off topic".
There're no "problems" in C, just features which are admittedly more
prone to accidental misuse than in certain other languages.
It was a concious design decision by the creator of C. That it'll go on
to become one of the most used programming languages was probably never
thought of. It was well suited to it's original purpose and it still
is, besides being moderately suited to many other areas of programming.
And actual FACTS like the total loss of Mars Global Surveyor
because of a memory overwrite will be dismissed as the
fact of an "incompetent" programmer. NASA has a lot of them
as it seems...
Accidents are rare but eventually always happen. What do you think
would've been the fate of the same spacecraft it it's software had been
written in say Java or Python.
C's good as long as you use it correctly. No language can protect you,
(in the long run), from improper or thoughtless coding.
This is a similar situation when I pointed out to the problems
of using p = malloc(n*sizeof(*p)). The same people starting
arguing that there isn't any UB (because overflow is
well defined for unsigned even if the result is mathematically
wrong).
malloc() has already been standardised, so nothing can be done. As you
note, a wrapper with a check is probably the best solution.
It's true that there isn't any UB, because, wraparound for unsigned
objects is precisely specified by the standard. It's just careless on
the part of the callee to not check the expression for possible
wraparound. I agree it's a subtle thing but, if you're serious about
programming in C, then you've got to know such stuff.
And the "incompetent programmer" came up again. Nothing
was said that the language doesn't have anything to test overflow!
Adding overflow checking is an option that implementations can offer as
a useful extension. Building it into C is not practicable.
Chris Hills wrote:
>
.... snip ...
>
I can not see any justification for discussion ANSI C 89 or the
original K&R (both of which are obsolete) but not C as currently
used. There are a few holier than thou pedants on there who want
to artificially restrict the NG to a sub set of C that most do not
use. But then pointlessly widen it to various obsolete versions of
the standard.
The point is that when referenced to a published standard all sides
know (or should know) what they are talking about. Once you let in
the wild extensions there is no reference.
You can still extend the language with functions, provided you
publish their source code, written in standard C.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andrew Chalk |
last post by:
A few year's ago someone (eminent in the C++ community) criticicized the use
of exceptions on the grounds that they introduced "a whole shadow type
system"). Can anyone recall the article and...
|
by: Matt Kruse |
last post by:
I've looked at some of the popular javascript libraries for use by
developers on upcoming projects:
jQuery, Moo Tools, YUI, Prototype (+Dojo), Fork
Of these most popular libraries, jQuery seems...
|
by: lorlarz |
last post by:
Although I believe your criticisms of jQuery are without merit, I have
tried to see the fuss in a positive light. I, thusly, have decided
that perhaps there is a need for YET further transparency...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| |
