"Criticism of the C programming language ??????"

[aarklon]

Hi all,

I found an interesting article here:-
http://en.wikipedia.org/wiki/Critici...mming_language

well what do you guys think of this article....???
Is it constructive criticism that needs to be appreciated always...???

[jacob navia]

Keith Thompson wrote:

[snip]

Consider a hypothetical GC implementation (not the one you're proposing)
in which memory allocated by malloc can be garbage-collected, and free
becomes a no-op (or perhaps forces an immediate deallocation). Then
existing programs and libraries gain the benefits of GC (in some cases,
memory leaks just go away), and new code can be written more simply
without bothering to call free().

This can't be done with a recompile.

Presumably there's a way to enable or disable GC for each program,
perhaps by specifying a library at link time.

You can disable the GC from a GC enabled program by defining
void *GC_malloc(size_t s)
{
return malloc(s);
}

But obviously, nothing can be done for the missing fre()
calls!

For some applications, it seems to me that this could potentially be a
good thing. Most programs, I suspect, would continue to work in such an
environment, some better than they did before. Those few programs that
play games with pointers would just have to be built with GC disabled,
or modified to keep the pointers visible.

Given such an implementation, it would be very important to specify that
certain actions which are well-defined in standard C would become
undefined.

In my earlier comments, I failed to distinguish between these two
alternatives, and I thought that you were ignoring a very important
issue, though one that perhaps affects only a few programs.

Now, a few questions about the form of GC that you propose.

If you allocate memory with GC_alloc, and free the same memory with
free, what happens? Is it undefined behavior?

YES!
You can't do that because the pointer is not in the malloc
list of allocated memory. It will have the same effect of
calling free with a pointer that wasn't allocated at all!

Is there a GC_free function that forces an immediate deallocation?

Yes.

Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory.

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers?

No.

Or, since the malloc()ed memory is still in the program's
address space, will this create a leak?

Yes.

Has the interaction between GC
and the existing malloc/free interface been thought through?

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

If you have GC pointers in a malloced structure you should set that
structure to zero (or other value) to avoid that the GC sees the
pointer and thinks that memory is used.

To be very clear, none of this implies that I'm rejecting your ideas.
I'm merely asking some technical questions.

In general, mixing two systems of memory allocation is not a good idea.
The best is to replace malloc/free by GC_malloc and be done with it,
if you want to use the GC, and to avoid the GC when you want to use
malloc.

The malloc/free system has its uses, and can be reasonable choice in
small applications or in applications where the GC would be impractical
for whatever reasons.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

jacob navia wrote:

Keith Thompson wrote:

[snip]

>Consider a hypothetical GC implementation (not the one you're
proposing) in which memory allocated by malloc can be
garbage-collected, and free becomes a no-op (or perhaps forces an
immediate deallocation). Then existing programs and libraries gain
the benefits of GC (in some cases, memory leaks just go away), and new
code can be written more simply without bothering to call free().

This can't be done with a recompile.

ERROR

That should have been

This can't be done without a recompile
*******

Excuse me for that.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Francine.Neary]

On Nov 16, 10:40 pm, jacob navia <[e-mail]:

Keith Thompson wrote:

Suppose I allocate a chunk of memory using malloc. Within that chunk of
memory, I have one or more pointers pointing to memory allocated by
GC_alloc. (If both models are supported, this kind of thing is going to
happen.) Then I free() the chunk of memory.

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

What if the reference to your pointer is stored in memory that has
been malloc()ated by a third-party library, which doesn't zero its
allocated memory before free()ing it?

>
Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

Typically, though that
chunk of memory is no longer visible to my program, it's still going to
be in my program's address space with its contents unchanged (until the
same memory is allocated again and re-initialized). Will the garbage
collector be able to collect the memory pointed to by the GC_alloc()ed
pointers?

No.

Or, since the malloc()ed memory is still in the program's
address space, will this create a leak?

Yes.

Has the interaction between GC
and the existing malloc/free interface been thought through?

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

If you have GC pointers in a malloced structure you should set that
structure to zero (or other value) to avoid that the GC sees the
pointer and thinks that memory is used.

To be very clear, none of this implies that I'm rejecting your ideas.
I'm merely asking some technical questions.

In general, mixing two systems of memory allocation is not a good idea.
The best is to replace malloc/free by GC_malloc and be done with it,
if you want to use the GC, and to avoid the GC when you want to use
malloc.

The malloc/free system has its uses, and can be reasonable choice in
small applications or in applications where the GC would be impractical
for whatever reasons.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

jacob navia <ja***@nospam.orgwrites:

Keith Thompson wrote:

<snip>

>Suppose I allocate a chunk of memory using malloc. Within that
chunk of memory, I have one or more pointers pointing to memory
allocated by GC_alloc. (If both models are supported, this kind of
thing is going to happen.) Then I free() the chunk of memory.

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

<snip>

>Has the interaction between GC and the existing malloc/free
interface been thought through?

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

You were suggesting that GC is essentially a library issue and that
there is no change to the "core" language, but these two examples
suggest that a subtle change is required (or at least implied): for
GC to work well, every pointer must behave rather as if it were
volatile. In fact, all memory will have to be treated like that.

In "old C", a compiler can remove the memset in the sequence:

memset(ptr, 0, size_of_date);
free(ptr);

but in your C, that would be a mistake (well, sub-optimal, maybe).
Similar things apply to the 'ptr = NULL;' example. Are you proposing
to make this change to C's "as if" rules?

[BTW, is the GC you ship the Boehm one or your own?]

--
Ben.

[J. J. Farrell]

Paul Hsieh wrote:

On Nov 15, 12:41 pm, Charlton Wilbur <[e-mail]:

>[...] We've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.

...

If the standard endorses good ideas, *LOTS* of people will pick them
up. One of the things you are missing with BSD sockets, is the fact
that Microsoft went and implemented them with an interface that is
very different under Windows than it is under the Unixes (I wonder how
they implemented it under MacOS9). And various embedded systems don't
even bother with any kind of sockets. So there's no "standard
sockets" that anyone can assume -- its just a platform specific idea.
The capability of sockets is good -- the current state of
fragmentation is not so good. With effort you can reasonably write
wrappers that let you write socket code that is portable -- but
there's not single centralized standard for this.

<OT>FWIW things are slowly getting better with sockets since they are
now defined by POSIX. I expect it to be a while before Microsoft
conforms, though.</OT>

[user923005]

On Nov 16, 3:56 pm, Ben Bacarisse <[e-mail]:

jacob navia <[e-mail]:

Keith Thompson wrote:

<snip>

Suppose I allocate a chunk of memory using malloc. Within that
chunk of memory, I have one or more pointers pointing to memory
allocated by GC_alloc. (If both models are supported, this kind of
thing is going to happen.) Then I free() the chunk of memory.

You should do
memset(ptr,0,size_of_ptr);
BEFORE.

Now, many free() implementations fill the freed block with
zeroes or other values. IN any case, the GC will
NOT find the pointer when it scans for pointers and
everything will work.

<snip>

Has the interaction between GC and the existing malloc/free
interface been thought through?

Yes. And it is very easy to see that if you want to get rid of
an object pointed to by p, the best thing is to just make

p = NULL;

and be done with it.

You were suggesting that GC is essentially a library issue and that
there is no change to the "core" language, but these two examples
suggest that a subtle change is required (or at least implied): for
GC to work well, every pointer must behave rather as if it were
volatile. In fact, all memory will have to be treated like that.

In "old C", a compiler can remove the memset in the sequence:

memset(ptr, 0, size_of_date);
free(ptr);

but in your C, that would be a mistake (well, sub-optimal, maybe).
Similar things apply to the 'ptr = NULL;' example. Are you proposing
to make this change to C's "as if" rules?

[BTW, is the GC you ship the Boehm one or your own?]

There are other problems with GC, when you have performance critical
operations.

If you are running a program and someone has used gc in a lib you are
using, then your program could 'hang' at inappropriate times when the
garbage collector is running.

It's a bigger problem than it sounds like. Although it is supposed to
be a bad idea, I find myself manually running the garbage collector in
GC languages to prevent inappropriate behavior (such as huge memory
consumption, very long pauses, etc.).

[Keith Thompson]

jacob navia wrote:

jacob navia wrote:

>Keith Thompson wrote:
[snip]

>>Consider a hypothetical GC implementation (not the one you're
proposing) in which memory allocated by malloc can be
garbage-collected, and free becomes a no-op (or perhaps forces an
immediate deallocation). Then existing programs and libraries gain
the benefits of GC (in some cases, memory leaks just go away), and
new code can be written more simply without bothering to call free().

This can't be done with a recompile.

ERROR

That should have been

This can't be done without a recompile
*******

No problem.

But why can't it be done without recompiling? What am I missing?

Provide two libraries, one that provides the usual non-GC malloc() and
free() functions, and another that provides GC versions of them
(malloc() allocates space that can be garbage-collected, and free() does
nothing). Take an existing program that uses malloc and free, linking
it with the first library. Re-link the same program (no recompilation,
just relinking) with the second library, and if it doesn't do funny
stuff with pointers, the program still works but with automatic garbage
collection (and free() calls ignored).

Of course this won't work if you want to distinguish between malloc()
and GC_alloc(), but I explicitly assumed an implementation in which
there's no such distinction.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[William Pursell]

On 16 Nov, 22:43, jacob navia <[e-mail]:

jacob navia wrote:

Keith Thompson wrote:

[snip]

Consider a hypothetical GC implementation (not the one you're
proposing) in which memory allocated by malloc can be
garbage-collected, and free becomes a no-op (or perhaps forces an
immediate deallocation). Then existing programs and libraries gain
the benefits of GC (in some cases, memory leaks just go away), and new
code can be written more simply without bothering to call free().

This can't be done with a recompile.

ERROR

That should have been

This can't be done without a recompile
*******

Maybe I'm missing something, but on my system it
certainly can:

$ ldd /bin/ls | grep libc
libc.so.6 =/lib/tls/i686/cmov/libc.so.6 (0xb7dc1000)

Update libc.so.6 and you get a new malloc.

[CJ]

On 17 Nov 2007 at 7:07, William Pursell wrote:

On 16 Nov, 22:43, jacob navia <[e-mail]:

>ERROR

That should have been

This can't be done without a recompile
*******

Maybe I'm missing something, but on my system it
certainly can:

$ ldd /bin/ls | grep libc
libc.so.6 =/lib/tls/i686/cmov/libc.so.6 (0xb7dc1000)

Update libc.so.6 and you get a new malloc.

I believe that on MS-DOS, and presumably therefore on most versions of
Windows too, it isn't possibly to link libraries dynamically.

[Richard Heathfield]

CJ said:

<snip>

I believe that on MS-DOS, and presumably therefore on most versions of
Windows too, it isn't possibly to link libraries dynamically.

MS-DOS had overlays, which were a way to load external code at runtime, so
they fulfilled much the same job as dynamically linked libraries.

As for Windows, one might reasonably describe it as little more than a
collection of dynamic link libraries. In most versions of Windows (and
probably all), it *is* possible to link libraries dynamically.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Hills]

In article
<e2**********************************@s36g2000prg. googlegroups.com>,
Paul Hsieh <we******@gmail.comwrites

>On Nov 15, 9:24 am, Charlton Wilbur <[e-mail]:

>>>>"PH" == Paul Hsieh <[e-mail]:

PHIn other words I just want to make the language to be a whole
PHhell of a lot better at doing what it already does today, and
PHstart making it less suck at what it sucks at today. Most of
PHwhat I want can be solved with a better library alone.

PHBut people are just satisfied with C for some reason. In the
PHyears of posting here I have barely had any support for my
PHpoint of view. It kind of disturbs me that nobody cares about
PHany of these issues. So its not like any of this would ever
PHmake it into a proposal which would be considered by the ANSI
PHC committee.

The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.

Ironically, the argument you make in what follows applies equally well
to C99 itself. In other words your argument is essentially moving
*backwards* in time, referring to things for which we already have
precedent. Compare this to my position in which I have observed the
ANSI C committee approve radical changes to the language (i.e., C99)
so I know that are *willing* to change the language and I am well
aware of the compiler vendor's reluctance to make the changes.

It's not up to ANSI. they are but one of many panels that make up the
ISO C Working Group 14 that makes the decision.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <fh**********@aioe.org>, Keith Thompson <ks***@mib.org>
writes

>Paul Hsieh wrote:

>On Nov 15, 2:47 pm, Keith Thompson <[e-mail]:

>>jacob navia wrote:
Charlton Wilbur wrote:
[...]
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
And I did not wait for people in ANSI to build lcc-win.
So What?
So why do you insist on discussing lcc-win's non-ISO extensions here in
comp.lang.c?

[...] In short, go fly a kite.

Go fly your own damned kite.

Not at all he has a point. It is just that a few of you want to have a
different restrictive set of rules for this NG

We have been round this loop many many times. Many of us disagree with
your narrow interpretation of what this NG is for.

Relax and stop your anti LCC-win paranoia

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Dollin]

Richard Heathfield wrote:

Nobody - but *nobody* - that I've ever met face to face, with the
*possible* exceptions of Chris Dollin and Ian Woods, calls it ISO C.

Old habits die hard.

I know it's ISO, but the knowing bit doesn't always wrest control away
from the knew bit.

My current tactic nowadays is to say/write "/Standard/ C", and hope that
won't lead to painful, inflammatory, and ultimately pointless arguments
about whether older Standards are Standards.

--
Chris "now on version 4.0, obviously" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Charlie Gordon]

"jacob navia" <ja***@nospam.orga écrit dans le message de news:
47***********************@news.orange.fr...

Paul Hsieh wrote:

>I haven't followed JN's GC proposal too closely, but if he had a way
of turning it off (which I would highly recommend) then I don't see
the issue.

If you call malloc/free and do not call GC_malloc the GC is
completely turned off!

It is a library!

If you do not use it you do not use it and it will not
be linked with your program!

The GC in lcc-win is an OPTIONAL feature.

Point made.

But even THAT is too much for the regulars

But could you refrain from always adding the single last remark that keeps
the argument going ?
Removing the ironic stance from your posts would greatly enhance your
ability to convince the readers.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

I did not "agree" to post corrections to *all* of Jacobs's mistakes
instantly,

Partly true - you rightly allowed yourself a reasonable time. But you did
agree to correct *all* of his mistakes (although obviously we can safely
exclude those that are corrected by others - no point in doubling up).

And yet you have not done so.

This is hardly your fault. It's practically impossible for any one person
to keep up with the volume.

I agreed that I considered "fair" that Richard would stop
posting
derogatory comments

I'm not sure that I agree that my comments are derogatory. Some, sure, out
of sheer exasperation - but mostly I seem to attract flak for correcting
his errors. The reason for my offer was simply to demonstrate that
/anyone/ - even you - would attract this flak if they corrected as many of
his errors as I have done in the past.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Charlie Gordon]

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de news:
he******************************@bt.com...

>
"Paul Hsieh" <we******@gmail.comwrote
3) Some kind of fseek/ftell on intmax_t

>instead of long: every modern compiler I know implements some sort 64
bit fseek and ftell (again, each incompatible with the other), because
"64 bits ought to be enough for everyone".

I've still got some "give me 64" T-shirts left. These tasteful designs
feature the numerals "64" made up of 64 separate squares, and promote the
campaign for 64 bit ints.

ITYM 64 bit integers ?

--
Chqrlie.

[jacob navia]

Richard Heathfield wrote:

Charlie Gordon said:

<snip>

>I did not "agree" to post corrections to *all* of Jacobs's mistakes
instantly,

Partly true - you rightly allowed yourself a reasonable time. But you did
agree to correct *all* of his mistakes (although obviously we can safely
exclude those that are corrected by others - no point in doubling up).

And yet you have not done so.

This is hardly your fault. It's practically impossible for any one person
to keep up with the volume.

>I agreed that I considered "fair" that Richard would stop
posting
derogatory comments

I'm not sure that I agree that my comments are derogatory. Some, sure, out
of sheer exasperation - but mostly I seem to attract flak for correcting
his errors. The reason for my offer was simply to demonstrate that
/anyone/ - even you - would attract this flak if they corrected as many of
his errors as I have done in the past.

<snip>

poor heathfield... in what a predicament he is

sniff!

:-)

at least this group is funny sometimes!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Charlie Gordon]

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de news:
xc*********************@bt.com...

>
"Paul Hsieh" <we******@gmail.comwrote in message

>My angle is different. There is a reasonable language hiding
somewhere in there, but it needs to be fixed. What I want to do is
plug all the stupid holes (start defining things that are currently
undefined), create a fully functional modification of the C library
that is fully re-entrant, have mandated runtime debugging assistance
and vastly expanded functionality for the heap, expose standard
functionality available on most modern CPUs (and which is otherwise
emulatable), redesign the file-IO for generic I/O (so that "FILE as
memory" emulation or sockets can happen fully at the library level)
and implement "one shot continuations" style coroutines into the
language. And fix glaring stupidities like ftell() and fseek() using
long as the file pointer offset.

Generally object-orientation is more trouble than its worth. But one
exception is streams. Serialisation is so fundamental that it should be
built in. You might want to look at my serialisation pages.

>>
Methinks there isn't a strong enough lobby for rationality in the
continued development of the C standard. And getting them to
acknowledge problems? I mean they are going to finally get rid of
gets() in the next standard.

gets() is something and nothing. Yes it is an easy way to make a broken
program, but it is only one function, not a methodology.

The other problem is the dependency feature. Time after time code which
could be reusable actually pulls in three of four headers, which pull in
an entire library, often for something totally trivial, such as a Point3d
type.

Another one, which you will realise if you use Lisp, is that in C there
are too many ways to express the same thing - arrays of arrays of
structures with arrays, or lists of list of lists. Lisp handles it fine by
simply having one "list" structure. In C you are constantly checking - is
it a pointer or a nested array, where is the size member ?

a countof operator/macro that would fail on non arrays would be a welcome
extension!

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de
news: he******************************@bt.com...

<snip>

>the campaign for 64 bit ints.

ITYM 64 bit integers ?

Whichever he means, he doesn't need to campaign. All he has to do is use
any of the vast[1] number of implementations whose designers agree with
him that 64 bit int[eger]s are the way forward. C itself does not mandate
64 bit int[eger]s, but it doesn't forbid them either, so if it's a
technically sensible thing to do, you can be sure that lots of
compiler-writer techies will already have done it.

[1] For a certain value of "vast".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mark McIntyre]

jacob navia wrote:

>
poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much.
It seems that you /always/ post a rude or sarcastic final word,
insulting someone.

[Richard Bos]

"Charlie Gordon" <ne**@chqrlie.orgwrote:

"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de news:
he******************************@bt.com...

"Paul Hsieh" <we******@gmail.comwrote
3) Some kind of fseek/ftell on intmax_t

instead of long: every modern compiler I know implements some sort 64
bit fseek and ftell (again, each incompatible with the other), because
"64 bits ought to be enough for everyone".

I've still got some "give me 64" T-shirts left. These tasteful designs
feature the numerals "64" made up of 64 separate squares, and promote the
campaign for 64 bit ints.

ITYM 64 bit integers ?

Don't you know? It's all the same. Any other kind of integer than int is
an abomination unto McLean, and should never be used lest it scare the
compiler.

Richard

[Charlie Gordon]

"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de news:
13*************@corp.supernews.com...

jacob navia wrote:

>>
poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much. It
seems that you /always/ post a rude or sarcastic final word, insulting
someone.

No insult here: Jacob is using a French onomatopy for weeping. He did not
mean to express any drug related slur. He could certainly confirm this and
apologize accordingly. It is very difficult to express irony in a foreign
language, tragic misunderstandings are common place. I would advise Jacob
to refrain from this.

--
Chqrlie.

[jacob navia]

Charlie Gordon wrote:

"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de news:
13*************@corp.supernews.com...

>jacob navia wrote:

>>poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much. It
seems that you /always/ post a rude or sarcastic final word, insulting
someone.

No insult here: Jacob is using a French onomatopy for weeping. He did not
mean to express any drug related slur. He could certainly confirm this and
apologize accordingly. It is very difficult to express irony in a foreign
language, tragic misunderstandings are common place. I would advise Jacob
to refrain from this.

No cocaine intended!
Long ago I read American comics and when some character
weeps, they write "sniff". But that was in the
forgotten years of my youth, and now "sniff" means
sniffing coke or whatever.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

In article <fi**********@aioe.org>, jacob navia <ja***@nospam.comwrote
on Wednesday 21 Nov 2007 4:39 pm:

Charlie Gordon wrote:

>"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de
news: 13*************@corp.supernews.com...

>>jacob navia wrote:
poor heathfield... in what a predicament he is

sniff!
Again you demonstrate just why you annoy some of the regulars so
much. It seems that you /always/ post a rude or sarcastic final
word, insulting someone.

No insult here: Jacob is using a French onomatopy for weeping. He
did not
mean to express any drug related slur. He could certainly confirm
this and
apologize accordingly. It is very difficult to express irony in a
foreign
language, tragic misunderstandings are common place. I would advise
Jacob to refrain from this.

No cocaine intended!
Long ago I read American comics and when some character
weeps, they write "sniff". But that was in the
forgotten years of my youth, and now "sniff" means
sniffing coke or whatever.

Your intended meaning was the one I understood too.

[Richard Heathfield]

Charlie Gordon said:

"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de
news: 13*************@corp.supernews.com...

>jacob navia wrote:

>>>
poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much.
It seems that you /always/ post a rude or sarcastic final word,
insulting someone.

No insult here:

You appear to have missed the sarcasm to which Mark McIntyre was referring.

But I have long since given up on any sensible response from Mr Navia - he
has accused me of nonsense and lying so many times now that I have long
since forgotten which particular misunderstandings of C led him to make
such claims, and I doubt very much whether he will ever have the courtesy
to make amends for all of the many times when he has allowed his arrogance
to blind him to his ignorance and has posted insults instead of reasoning.
If you think I'm "derogatory" about Mr Navia, look long and hard at his
posting history, and then please just get off my back.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kuyper]

Richard Heathfield wrote:

Charlie Gordon said:

>"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de
news: he******************************@bt.com...

<snip>

>>the campaign for 64 bit ints.

ITYM 64 bit integers ?

Whichever he means, he doesn't need to campaign. All he has to do is use
any of the vast[1] number of implementations whose designers agree with
him that 64 bit int[eger]s are the way forward. C itself does not mandate

....

[1] For a certain value of "vast".

I think that the required value for 'vast' is vastly different, if he's
referring to ints rather than integers.

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

>Charlie Gordon said:

>>"Malcolm McLean" <re*******@btinternet.coma écrit dans le message de
news: he******************************@bt.com...

<snip>

>>>the campaign for 64 bit ints.
ITYM 64 bit integers ?

Whichever he means, he doesn't need to campaign. All he has to do is use
any of the vast[1] number of implementations whose designers agree with
him that 64 bit int[eger]s are the way forward. C itself does not
mandate

...

>[1] For a certain value of "vast".

I think that the required value for 'vast' is vastly different, if he's
referring to ints rather than integers.

I don't think Malcolm accepts that there is any distinction. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

In article <6_V0j.1136$ng.1085@trnddc08>, James Kuyper
<ja*********@verizon.netwrote on Wednesday 21 Nov 2007 6:30 pm:

Richard Heathfield wrote:

>Charlie Gordon said:

>>"Malcolm McLean" <re*******@btinternet.coma écrit dans le message
de news: he******************************@bt.com...

<snip>

>>>the campaign for 64 bit ints.
ITYM 64 bit integers ?

Whichever he means, he doesn't need to campaign. All he has to do is
use any of the vast[1] number of implementations whose designers
agree with him that 64 bit int[eger]s are the way forward. C itself
does not mandate

...

>[1] For a certain value of "vast".

I think that the required value for 'vast' is vastly different, if
he's referring to ints rather than integers.

Malcolm has previously expressed his disapproval of multiple integer
types. After all size_t, his personal devil, is an integer too. He
favours near universal use of the int type, wherever an integer is
needed (except for the case of char), which is why he wants int to be
64-bits: to iron out (to an extent), the inconveniences entailed by
this decision.

I also get the feeling that he similarly strongly favours signed types
over unsigned types, even in situations that literally beg for the use
of the latter.

His is an eccentric opinion and though some of his rationale for it are
reasonable, the overall argument is not, IMO.

[Richard]

santosh <sa*********@gmail.comwrites:

In article <fi**********@aioe.org>, jacob navia <ja***@nospam.comwrote
on Wednesday 21 Nov 2007 4:39 pm:

>Charlie Gordon wrote:

>>"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de
news: 13*************@corp.supernews.com...
jacob navia wrote:
poor heathfield... in what a predicament he is
>
sniff!
Again you demonstrate just why you annoy some of the regulars so
much. It seems that you /always/ post a rude or sarcastic final
word, insulting someone.

No insult here: Jacob is using a French onomatopy for weeping. He
did not
mean to express any drug related slur. He could certainly confirm
this and
apologize accordingly. It is very difficult to express irony in a
foreign
language, tragic misunderstandings are common place. I would advise
Jacob to refrain from this.

No cocaine intended!
Long ago I read American comics and when some character
weeps, they write "sniff". But that was in the
forgotten years of my youth, and now "sniff" means
sniffing coke or whatever.

No. "Sniff" in conversation is always accompanied with a downtown of the
mouth and an upset look. It has one meaning in a context like this.

>
Your intended meaning was the one I understood too.

It's the one anyone whose first language is English would understand
too. Mark was simply stirring the sludge while demonstrating his
"regulars" fixation yet again (his word not mine).

[Keith Thompson]

Charlie Gordon wrote:

"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de news:
13*************@corp.supernews.com...

>jacob navia wrote:

>>poor heathfield... in what a predicament he is

sniff!

Again you demonstrate just why you annoy some of the regulars so much. It
seems that you /always/ post a rude or sarcastic final word, insulting
someone.

No insult here: Jacob is using a French onomatopy for weeping. He did not
mean to express any drug related slur. He could certainly confirm this and
apologize accordingly. It is very difficult to express irony in a foreign
language, tragic misunderstandings are common place. I would advise Jacob
to refrain from this.

Huh?

I read jacob's "sniff!" exactly has he intended it, as a sarcastic
indication of weeping, and I see absolutely nothing specifically French
about it. It would never occur to me that it was related to drug use
and jacob has no need to apologize on those grounds.

As usual, I found jacob's attempt at sarcasm tedious and annoying. He
has some actual ideas, and some subset of them are both valid and
topical. He could improve the tone of this newsgroup significantly if
he would drop his attempts at sarcasm (whether he feels they're provoked
or not) and stick to discussing technical issues.

jacob: You are not good at sarcasm. This is honestly meant as
constructive criticism, not as a personal insult. I don't expect you to
accept it, but hope springs eternal.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
fi**********@aioe.org...

Charlie Gordon wrote:

>"Mark McIntyre" <ma**********@spamcop.neta écrit dans le message de
news: 13*************@corp.supernews.com...

>>jacob navia wrote:
poor heathfield... in what a predicament he is

sniff!
Again you demonstrate just why you annoy some of the regulars so much.
It seems that you /always/ post a rude or sarcastic final word,
insulting someone.

No insult here: Jacob is using a French onomatopy for weeping. He did
not mean to express any drug related slur. He could certainly confirm
this and apologize accordingly. It is very difficult to express irony in
a foreign language, tragic misunderstandings are common place. I would
advise Jacob to refrain from this.

Huh?

I read jacob's "sniff!" exactly has he intended it, as a sarcastic
indication of weeping, and I see absolutely nothing specifically French
about it. It would never occur to me that it was related to drug use and
jacob has no need to apologize on those grounds.

As usual, I found jacob's attempt at sarcasm tedious and annoying. He has
some actual ideas, and some subset of them are both valid and topical. He
could improve the tone of this newsgroup significantly if he would drop
his attempts at sarcasm (whether he feels they're provoked or not) and
stick to discussing technical issues.

jacob: You are not good at sarcasm. This is honestly meant as
constructive criticism, not as a personal insult. I don't expect you to
accept it, but hope springs eternal.

I agree completely.

Regarding sniff, I did not imply it was specific to French, but I was quite
sure Jacob got it from the French version of a famous american comic strip.
I was not aware that it was untranslated. It may even have been spelled as
'snif!' back then.

As a matter of fact, the word is used in French slang with the sole drug
related meaning: sniffer de la coke, sniffer de la colle... The original
French word is somewhat similar (renifler) but does not have the same
connotations anymore.

--
Chqrlie.

[Peter Nilsson]

santosh <[e-mail]:

...Malcolm has previously expressed his disapproval of
multiple integer types. After all size_t, his personal
devil, is an integer too. He favours near universal use
of the int type, wherever an integer is needed (except
for the case of char), ...

I also get the feeling that he similarly strongly favours
signed types over unsigned types, even in situations that
literally beg for the use of the latter.

His is an eccentric opinion...

No, just a very old one. You've described primordial C to a
tee.

--
Peter

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
7O******************************@bt.com...

Charlie Gordon said:

<snip>

>I did not "agree" to post corrections to *all* of Jacobs's mistakes
instantly,

Partly true - you rightly allowed yourself a reasonable time. But you did
agree to correct *all* of his mistakes (although obviously we can safely
exclude those that are corrected by others - no point in doubling up).

And yet you have not done so.

Too much traffic, a lot of which has little to do with C.

This is hardly your fault. It's practically impossible for any one person
to keep up with the volume.

>I agreed that I considered "fair" that Richard would stop
posting
derogatory comments

I'm not sure that I agree that my comments are derogatory. Some, sure, out
of sheer exasperation - but mostly I seem to attract flak for correcting
his errors. The reason for my offer was simply to demonstrate that
/anyone/ - even you - would attract this flak if they corrected as many of
his errors as I have done in the past.

I think you are mistaken: you attract flak not because of the number of
corrections you feel the need to make, but because of the tone you use and
the extra judgmental remarks you keep adding. Your typical "corrections"
too many times contain derogatory tone and allusions for Jacob Navia, such
as:

"I see no value in attempting to educate you"
"you appear to be incapable of holding a rational debate"
"I cannot take seriously the views on C of a man who, it is evident from his
own postings, knows so little about the language"
"You need to learn to tell right from wrong. For the past few years, you
appear to have got them mixed up with monotonous regularity"
"I've explained this before in clc, but Mr Navia obviously can't remember
that far back..."
"I know from experience that Mr Navia rarely if ever bothers to listen to
good advice"
"you are wrong - as usual"
"are all Frenchmen so wilfully ignorant ..."

I agree that Jacob makes mistakes, and gets carried away with baseless
allusions and misused irony, but both of you need to cool down and use
better manners for this group's sake.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

I think you are mistaken: you attract flak not because of the number of
corrections you feel the need to make,

Did you feel the need to reply in that way? Or did you just reply in that
way? It is possible to reply in a particular way without "feeling a need",
is it not?

but because of the tone you use

Check out Jacob Navia's tone some time - the tone he uses when he's wrong
but thinks he's right (which is most of the time).

and the extra judgmental remarks you keep adding.

It didn't start out that way - and by the way, they're not intended to be
judgemental. All the behaviour they describe can be corrected, if Mr Navia
so chooses.

Your typical "corrections"
too many times contain derogatory tone and allusions for Jacob Navia,

Let's see, shall we?

such as:

"I see no value in attempting to educate you"

What is Jacob Navia's learning percentage? How much of what we teach him
about C does he actually take in and absorb and act upon? I'm not saying
it's zero, but I would suspect it's not far above it. Therefore, I see no
value in attempting to educate him. This is not an allusion. It is not
even derogatory. It is simply a statement of fact (which, I might add, is
taken out of context - it is almost certainly the case that I said the
above in a context such as "but in case anyone else was misled by your
claim, I would point out the fact that..." or something like that).

"you appear to be incapable of holding a rational debate"

Again, this appears to me to be true. Have you any counter-examples?

"I cannot take seriously the views on C of a man who, it is evident from
his own postings, knows so little about the language"

Again, this appears to me to be true. Charlie, he's been getting this stuff
wrong for *years*.

"You need to learn to tell right from wrong. For the past few years, you
appear to have got them mixed up with monotonous regularity"

Again, this appears to me to be true. He seems to have things exactly the
wrong way round on so many issues. Have you any counter-examples?

"I've explained this before in clc, but Mr Navia obviously can't remember
that far back..."

If he could, he'd have got it right.

"I know from experience that Mr Navia rarely if ever bothers to listen to
good advice"

Again, absolutely true.

"you are wrong - as usual"

And again.

"are all Frenchmen so wilfully ignorant ..."

Context: "Just out of curiosity: are all Frenchmen so wilfully ignorant as
to drop honorifics from names (as you habitually do), or is it just you
giving your countrymen a bad name?" It seems to me to be a fair question.

I agree that Jacob makes mistakes, and gets carried away with baseless
allusions and misused irony,

Lots and lots of mistakes, *despite continued corrections*. Did you mean
"baseless allegations"? Because that's certainly the case. As for his
"irony", it is beyond parody.

but both of you need to cool down and use
better manners for this group's sake.

I think you need to get off my back about this, Charlie. If you want to
criticise anyone about manners, you're looking in the wrong direction.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[David Thompson]

On Thu, 15 Nov 2007 22:07:41 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:

Another one, which you will realise if you use Lisp, is that in C there are
too many ways to express the same thing - arrays of arrays of structures
with arrays, or lists of list of lists. Lisp handles it fine by simply
having one "list" structure. In C you are constantly checking - is it a
pointer or a nested array, where is the size member ?

Classic LISP yes, but even there you have 'raw' pairs (conses); for
example I (vaguely) remember some implementation I used did binding
context as list of pairs. Which could look misleading, since the
bindings of many (most?) variables would be lists, and dotting to a
list gives you something that looks like a different list.

Over time more structures were added. Standardized 'Common' Lisp has
arrays including vectors, bitvectors, and (character) strings; and
structs (with inheritance); and hashtables; as well as composites that
are primarily defined and used by 'the system' but are more or less
accessible to user code such as package/obarray, readtable,
metaclasses, I/O pathnames and streams.

- formerly david.thompson1 || achar(64) || worldnet.att.net