comp.lang.c - 25 new messages in 3 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* arithmetic on a void * pointer - 21 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
* a CPAN for C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/6d957d79a1c23dac?hl=en
* Comparision of C Sharp and C performance - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/4cf78a2afa73b77a?hl=en

==============================================================================
TOPIC: arithmetic on a void * pointer
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
==============================================================================

== 1 of 21 ==
Date: Sat, Jan 9 2010 5:33 am
From: Phil Carmody

Mark Adler <madler@alumni.caltech.edu> writes:
> On 2010-01-08 23:50:17 -0800, Ian Collins said:
>> Nonsense, the size is the size of the data pointed to.
>
> Is it now. The size in what units? void has no size. So how do we
> know the size of the units a void * points to? Is that size the
> number of int's? Of struct foo's?

The size in bytes. As the standard tells us.

>> the length is a length in bytes.
>
> Ah, always in bytes you say. Excellent. Now we know the implicit
> size of void.

No we don't.

You're hallucinating.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 2 of 21 ==
Date: Sat, Jan 9 2010 5:36 am
From: Phil Carmody

Mark Adler <madler@alumni.caltech.edu> writes:
> On 2010-01-08 22:59:53 -0800, Beej Jorgensen said:
>> On 01/08/2010 08:12 PM, Mark Adler wrote:
>>> My current copy of gcc (4.2.1) will, with all warnings enabled (-Wall)
>>> is perfectly happy with (no warnings):
>>>
>>> void *buf;
>>> int n;
>>>
>>> buf += n;
>>
>> gcc -pedantic:
>>
>> foo.c:9: warning: pointer of type 'void *' used in arithmetic
>>
>> Perhaps it's only warning idiots like me? ;-)
>
> Apparently -Wall really only means -Wsome.

No, all warnings in a clearly defined set.

However, that's not your mistake - your mistake is that you've forgotten
to chose which language to use, and so GCC has defaulted to something
which isn't strictly C.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 3 of 21 ==
Date: Sat, Jan 9 2010 6:20 am
From: spinoza1111

On Jan 9, 11:43 am, Mark Adler <mad...@alumni.caltech.edu> wrote:
> On 2010-01-08 19:20:53 -0800, Keith Thompson said:
>
> > Mark Adler <mad...@alumni.caltech.edu> writes:
> >> In the good old days, any self-respecting C compiler knew ...
> > Arithmetic has *never* been permitted on void* by standard C.
>
> I wasn't talking about the standard.  I was talking about the compilers.
>
> > There as been no dumbing down of the language;
>
> You're correct.  I meant dumbing down of the compilers to agree with
> the religious extremism of the standard.
>
> > If you want to advance a void* so it points n bytes later in memory,
> > you can do this:
> >     buf = (char*)buf + n;
>
> Thank you.  That's what I'll do.  Of course, at the loss of the
> expessiveness and readability of the wonderful += operator of C.
>
> On 2010-01-08 19:23:24 -0800, Dennis \(Icarus\) said:
>
> > Is void a data type?
> > Does void foo(); return a byte?
> > Does void a; define a byte?
>
> Is void * a pointer?  Yes.
> If I add n to the register that pointer is in, does it go up by n?  Yes.
> Isn't that what you'd expect?  Yes.
>
> Anyway, I get the concept that void * deliberately makes the size of
> the type ambiguous, so in principle arithmetic on it should be
> undefined.  On the other hand, the standard could make life easier and
> still entirely self-consistent if it simply said that arithmetic on
> void * pointers treats the size as 1.  Why make a useful expression
> illegal when instead it can mean what everyone expects it to mean?
>
> >> (And why a cast of a pointer to another pointer type is no longer a
> >> pointer, I have no idea.)
>
> > It is a pointer  but an r-value not an l-value.
>
> Why is it not an l-value?  I can see no ambiguity whatsoever about what
> it means as an l-value.
>
> Mark

Watch out fella, you're Daniel in the lions' den. Keep up the good
questions.

== 4 of 21 ==
Date: Sat, Jan 9 2010 6:34 am
From: spinoza1111

On Jan 9, 11:57 am, "Dennis \(Icarus\)" <nojunkm...@ever.invalid>
wrote:
> "Mark Adler" <mad...@alumni.caltech.edu> wrote in message
>
> news:2010010819433816807-madler@alumnicaltechedu...
>
> > On 2010-01-08 19:20:53 -0800, Keith Thompson said:
> >> Mark Adler <mad...@alumni.caltech.edu> writes:
> >>> In the good old days, any self-respecting C compiler knew ...
> >> Arithmetic has *never* been permitted on void* by standard C.
>
> > I wasn't talking about the standard.  I was talking about the compilers.
>
> And compilers generally follow the standard. You may check to see if there's
> a mode on te cpmpiler you're using that allows it as an extension.
> Do you have an option like "disable language extensions" set?
>
>
>
> >> There as been no dumbing down of the language;
>
> > You're correct.  I meant dumbing down of the compilers to agree with the
> > religious extremism of the standard.
>
> The C language is defined b the standard. Do you want to program in C or
> not?

No, from the standpoint of science (linguistics), no standard can
"define" C. This is because independent of the standard are all sorts
of C compilers with a fuzzy relation to any one formal definition of
C. Somewhat like world received English, C is what intelligent users
"say" it is. In addition, linguists also add that the language should
be the canonical user's first language, but this is impossible with C,
of course.

Now, the problem is measuring "intelligence", especially here. It
cannot be measured by "correct use of C" since "the correct use of C"
is basically "what I say it is" or "what is in the Holy Standard
[which was written to protect vendor profits and leaves too much
undefined]".

Here, intelligence is only measurable by literacy in writing English
and basic honesty (not making crude lies such as Heathfield's "Nilges
has never posted in comp.risks"). Of the proponents of "standard C"
only Ben Bacarisse passes this test. Other posters spout what I regard
as incoherent nonsense, such as the claim that one can be clear and
false at the same time, and, they defend their complete nonsense to
the last round and the last man.

The original poster here is in fact asking good questions in a
literate way. He's toast since basic literacy and honesty are so
seldom found in this newsgroup.

>
>
>
> >> If you want to advance a void* so it points n bytes later in memory,
> >> you can do this:
> >>     buf = (char*)buf + n;
>
> > Thank you.  That's what I'll do.  Of course, at the loss of the
> > expessiveness and readability of the wonderful += operator of C.
>
> > On 2010-01-08 19:23:24 -0800, Dennis \(Icarus\) said:
> >> Is void a data type?
> >> Does void foo(); return a byte?
> >> Does void a; define a byte?
>
> > Is void * a pointer?  Yes.
>
> Yes it is, and dereferencing it will cause problems.

But if it is a pointer in truth, why would dereferencing it cause
problems, oh Divine Master? Yea this is hard for us mere mortals to
understand! For what is a pointer but that which dereferenceth?
>
> > If I add n to the register that pointer is in, does it go up by n?  Yes.
>
> That's assembly though - not C.

Oh divine Master, thou speakest horseshit indeed: for hath not C a
register declaration? And are we not supposed to think ahead a little
bit to what happeneth when our code runneth? Yea, verily they speak
with forked tongue who say, "behold: C is close to the Machine, and if
thou codest in C, thou shalt be one with the Machine, warm in winter
owing to the heat of its circuitry, cool in summer's heat owing to its
air conditioning", but then slay those, as Seebach has slain those,
who darest to speak of the mysteries of runtime such as the Stack, or
here the Register.

>
> > Isn't that what you'd expect?  Yes.
>
> If I was programming assembly, sure, but not if I was programming in C.
>
>
>
> > Anyway, I get the concept that void * deliberately makes the size of the
> > type ambiguous, so in principle arithmetic on it should be undefined.  On
> > the other hand, the standard could make life easier and still entirely
> > self-consistent if it simply said that arithmetic on void * pointers
> > treats the size as 1.  Why make a useful expression illegal when instead
> > it can mean what everyone expects it to mean?
>
> >>> (And why a cast of a pointer to another pointer type is no longer a
> >>> pointer, I have no idea.)
>
> >> It is a pointer  but an r-value not an l-value.
>
> > Why is it not an l-value?  I can see no ambiguity whatsoever about what it
> > means as an l-value.
>
> Morris Keesan explains this nicely.

Thou directest him away for thou art full of shit.

>
> Dennis

== 5 of 21 ==
Date: Sat, Jan 9 2010 6:36 am
From: spinoza1111

On Jan 9, 11:58 am, Mark Adler <mad...@alumni.caltech.edu> wrote:
> On 2010-01-08 19:39:37 -0800, Morris Keesan said:
>
> >> (char *)buf += n;
> > Which has also never (in my experience) been legal.
>
> Until recently, gcc -Wall didn't complain about that.
>
> > which in most cases one wouldn't expect to be a type
> > that's sufficiently compatible with the actual type of the original object
> > to make assignment reasonable.
>
> So what about the cases where assignment *is* reasonable?  Like casting
> a pointer?
>
> > This method has the advantage that it works equally well if the type
> > you're working with is anything OTHER than char, i.e. if (type *) is
> > NOT guaranteed
> > to have the same size and representation as (char *).  E.g.
>
> > buf = (int *)buf + n;
> > or
> > buf = (struct foo *)buf + n;
>
> I don't see why we should have to lose the += operator in this case.  
> (struct foo *)buf += n looks to me like it should make perfect sense to
> the compiler.

You poor bastard. Hast thou not heard? Hast thou not been told? Hast
thou not seen? Hast thou not gotten the memo? The motto of the regs
here is a song by David Byrne: Stop Making Sense.
>
> Mark

== 6 of 21 ==
Date: Sat, Jan 9 2010 6:39 am
From: spinoza1111

On Jan 9, 12:04 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Mark Adler wrote:
>
> > Is void * a pointer?  Yes.
> > If I add n to the register that pointer is in, does it go up by n?  Yes.
>
> That depends how big a "void" is, doesn't it?
>
> > Isn't that what you'd expect?  Yes.
>
> Not really.

Mark Adler: note what the guy says: he uses a negative as his major
operator. To say "it is not the case that" or "that is undefined" is
what the regs do here. That way, they don't take the risk of saying
something that can be easily falsified, since they need to avoid
humiliation at all costs.

And why do they need to avoid humiliation at all costs?

This is because most of the regs here (Seebach, Heathfield, Thompson
and Rosenau being the four horsemen) make it their business to stab
newbies in the back and shame people for not talking their talk.
>
> --
> Ian Collins

== 7 of 21 ==
Date: Sat, Jan 9 2010 6:44 am
From: spinoza1111

On Jan 9, 12:12 pm, Keith Thompson <ks...@mib.org> wrote:
> Mark Adler <mad...@alumni.caltech.edu> writes:
> > On 2010-01-08 19:39:37 -0800, Morris Keesan said:
> >>> (char *)buf += n;
> >> Which has also never (in my experience) been legal.
>
> > Until recently, gcc -Wall didn't complain about that.
>
> It sounds like gcc has been improved.
>
> >> which in most cases one wouldn't expect to be a type
> >> that's sufficiently compatible with the actual type of the original object
> >> to make assignment reasonable.
>
> > So what about the cases where assignment *is* reasonable?  Like
> > casting a pointer?
>
> You find it reasonable; I don't.
>
> A cast specifies a conversion, which takes a value as its operand and
> yields a converted value of the specified type.
>
> An lvalue designates an object.  For the result of a cast to designate
> an object, there has to be some object *of the specified type* for it
> to designate.  Since the operand of the cast was of a different type,
> there is no such object.
>
> Conceivably the language could specify that a cast yields an lvalue if
> the source and target types both have the same representation (this
> happens to be guaranteed for char* and void*).  But in my opinion that
> would be ugly and inconsistent.  Would you want this:
>
>     long l;
>     (int)l = 42;
>
> to compile if and only if int and long happen to be the same size?
> Would you want this:
>
>     int *ptr;
>     (void*)ptr = NULL;
>
> to work as "expected" on most systems, but fail to compile on systems
> where int* and void* have different representations?
>
> And would you want such a special-case rule just so you can use "+="?
>
> >> This method has the advantage that it works equally well if the type
> >> you're working with is anything OTHER than char, i.e. if (type *) is
> >> NOT guaranteed
> >> to have the same size and representation as (char *).  E.g.
>
> >> buf = (int *)buf + n;
> >> or
> >> buf = (struct foo *)buf + n;
>
> > I don't see why we should have to lose the += operator in this case.
> > (struct foo *)buf += n looks to me like it should make perfect sense
> > to the compiler.
>
> But it doesn't.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
> Nokia
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

This reply is sickeningly dishonest. Thompson wants the user of a
weakly typed language to use it as if it were strongly typed when
there are all sorts of languages that enforce type safety.

Kiki, get this through your head. Companies force programmers to use C
precisely because at the critical moment, C can be butt fucked into
doing things pathologically, and therefore "saving time" and
preserving short-term profits.

Hard magic constants, pre-allocated fixed arrays, void pointers and
all sorts of other crap are the norm in production C code.

== 8 of 21 ==
Date: Sat, Jan 9 2010 6:46 am
From: spinoza1111

On Jan 9, 12:25 pm, Mark Adler <mad...@alumni.caltech.edu> wrote:
> On 2010-01-08 20:18:17 -0800, Alan Curry said:
>
> >http://en.wikipedia.org/wiki/Mark_Adler?adler32, etc? and thinks void *
> > arithmetic should be acceptable? What a world!
>
> Human sacrifice, dogs and cats living together, mass hysteria!
>
> Mark

Mark, are you the guy in the wikipedia article? Whether you are or are
not, you appear to be one of the few intelligent people to wander in
here. Be advised of the bozo factor, including the incorrect
designation of bozoidness being hurled by bozos.

== 9 of 21 ==
Date: Sat, Jan 9 2010 6:46 am
From: Eric Sosman

On 1/8/2010 9:51 PM, Mark Adler wrote:
> Helpful C swamis,
>
> In the good old days, any self-respecting C compiler knew what you meant
> when you did arithmetic on a void * pointer, i.e. that the units were
> bytes.

If by "the good old days" you mean "before the ANSI Standard
in 1989," you might be sort of right. In those days there was no
formal definition of C, and all manner of compilers bestowed the
"C" label on themselves. Some of those may have had a void* type
(K&R C did not), and some of those may have permitted arithmetic
on that type. I never ran across a pre-ANSI compiler with these
characteristics, but there were lots and lots of compilers I
never ran across at all.

Also, if it's pre-ANSI C you speak of, I dispute the adjective
"good."

Starting with ANSI C, which first (formally) introduced void*
to the language, no conforming compiler has ever permitted
arithmetic on void* values. The only compiler I happen to know
of that permits it is gcc (in a non-conforming mode), but perhaps
there are others. There are certainly "self-respecting" compilers
that follow the language definition and forbid it.

> Then someone decided that we would all be more productive somehow
> if the compilers couldn't figure out obvious things like that on their
> own. So now you can't do arithmetic on void * pointers.

It'd be bogus. Since void is an incomplete type, the sizeof
the thing a void* points at is unknown. That's what makes void*
useful in the first place: You can point it at anything at all
without worrying about the sizeof the target. The very same void*
variable can point at a char, an int, and a struct foobar, all
during a single execution of one program. What is "the" size of
all these different targets?

Here's another incomplete type, and an example of how it
might be used in a hypothetical implementation of an ADT:

struct unknown; // incomplete type
struct unknown * newUnknown(int); // a "constructor"
struct unknown * uptr = newUnknown(42); // instantiation

Okay, uptr (we'll suppose) now points at a struct unknown instance.
If you now do ++uptr, what ought to happen? Should the address
advance by one byte? Forty-two bytes? Eleven? Where is the
"one past the end" location for the struct unknown object whose
size is a mystery? Arithmetic on a void* encounters exactly the
same problem: The size of the target is unknown, so the compiler
can't know how far to advance the pointer.

> Ok, fine. So I adjusted, I would do this:
>
> void *buf;
> int n;
>
> (char *)buf += n;

This is also bogus, for the same reason (double)n += 0.42
would be bogus. The left-hand side is an expression with an
operand, an operator, and a value, not an object to which you
can assign something (I'm speaking somewhat loosely here; look
up the term "assignable lvalue" for a more rigorous treatment).

> But now I'm getting nastygrams like "warning: target of assignment not
> really an lvalue; this will be a hard error in the future". Once again
> someone, probably the same person, decided that compilers shouldn't have
> to burden this great responsibility of understanding obvious things like
> that. (And why a cast of a pointer to another pointer type is no longer
> a pointer, I have no idea.)

Because the cast is an operator that derives a value from
its operand. Try this one: (char*)(ptr + 42) = "Hello". Where
do you think the pointer to 'H' should be stored, and why?

> So now what am I supposed to do? It starts to get just downright silly.
> E.g.
>
> void *buf;
> int n;
> char *cmon;
>
> cmon = (char *)buf;
> cmon += n;
> buf = (void *)cmon;
>
> Is there a better way to work around this, at least until the *next*
> dumbing down of the language?

buf = (char*)buf + n;

And before you say "That's just dim-witted," ponder

buf = (int*)buf + n;

It seems to me there are two misconceptions buried in your
mental model of the language. One is the notion that a pointer
is "just an address," which is wrong: A pointer is an address
*and* a type, and the type is important. The second mistake is
to think of the cast operator as meaning "let's pretend this
thing is of a different type," when in fact it means "take the
value of this thing, convert it to a new type, and deliver the
converted value (which may even be unequal to the original)."

You are not the first to fall victim to these two mistaken
notions, nor will you be the last.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 10 of 21 ==
Date: Sat, Jan 9 2010 6:55 am
From: spinoza1111

On Jan 9, 1:30 pm, Keith Thompson <ks...@mib.org> wrote:
> Mark Adler <mad...@alumni.caltech.edu> writes:
> > On 2010-01-08 20:12:55 -0800, Keith Thompson said:
> >> Since the operand of the cast was of a different type,
> >> there is no such object.
>
> > Sez you.  If what you said was correct, then we should never be able
> > to cast a pointer to another pointer type, since that object it's
> > pointing to doesn't exist.
>
> Huh?
>
> If you're going to snip context, can you please indicate that you're
> doing so?  Here's what I wrote:
>
>     An lvalue designates an object.  For the result of a cast to
>     designate an object, there has to be some object *of the specified
>     type* for it to designate.  Since the operand of the cast was of a
>     different type, there is no such object.
>
> I'm not talking about the object (if any) to which the pointer points.
> I'm talking about the pointer object itself.
>
> For example, given:
>
>     void *vp = ...;
>     ... (char*)vp ...
>
> vp is an object of type void*.  There is no object of type char*.
> There is a *value* (not an lvalue) of type char*, the result of
> converting the value of vp from void* to char*.
>
> [...]
>
> >> Would you want this:
>
> >>     long l;
> >>     (int)l = 42;
>
> > No I would not want that.  l is not a pointer.
>
> And why does that matter?
>
> >>     int *ptr;
> >>     (void*)ptr = NULL;
>
> >> to work as "expected" on most systems, but fail to compile on systems
> >> where int* and void* have different representations?
>
> > Uh oh.  Now I'm really worried, if having different, non-transferrable
> > data pointer representations is permitted by the C standard.  I sure
> > hope you're wrong.
>
> I'm not.  Different pointer types can have different representations.
>
> Consider a system where a machine address points to, say, a
> 64-bit word, but the C implementation specifies an 8-bit byte.
> Word pointers can be represented as machine addresses, but byte
> pionters need an additional offset stored somewhere.  (I've worked
> on such a system.)
>
> You might take a look at section 4 of the comp.lang.c FAQ,
> <http://www.c-faq.com/>.
>
> > I certainly would expect the code above to work, though I can think of
> > no reason to do that since NULL is of the type void *, and so can be
> > assigned to other pointers without an explicit cast.  It should just
> > be ptr = NULL.  (At least that's what the compilers allow -- I hope
> > that doesn't get messed up too.  I don't want to have to cast NULL
> > every time I use it.)
>
> I just used NULL as a trivial example.  The point isn't whether it's a
> sensible thing to do, it's whether it's legal.

ROTFLMAO, another for the Red Book, along with Heathfield
("comp.programming not about programmers", "Nilges not in comp.risks",
"functions return expressions") and Seebach ("the 'heap' is a DOS
term"):

"The point isn't whether it's a sensible thing to do, it's whether
it's legal"

...meaning it must conform to the Holy Standard. When asked why, the
*imams* of the Standard tell their *taliban* that their code must be
portable.

This is completely absurd. C is so dangerously NON portable that ANY
port needs a line by line analysis for gotchas no matter how "good" is
the code. When people want to be portable they use Java.

The reality is that if it works on a specific compiler, that is the
goal in 99.9% of cases.

>
> > Anyway, I thought that the void * type *must* be able to be a vessel
> > for a pointer to any other data object.  In fact, it has no other
> > reason to exist.  If you cannot put an anydata * in a void * variable,
> > pass it along, and later convert it back to an anydata * and get the
> > anydata it's pointing to, then the value of void * is lost.
>
> > So is it not true that void * must be able to be a vessel for a
> > pointer to any data object?
>
> Depends on what you mean by "vessel".
>
> A value of any pointer type (other than a pointer-to-function type)
> may be converted to void* and back to the original type without
> loss of information.  The language specifically guarantees this.
>
> But it's important to understand that conversions operate on values,
> not on objects.  There is no implication that an object of type void*
> can be treated as if it were an object of some other pointer type
> (except for the special guarantee that void* and char* have the
> same representation).  Conversion is not type-punning.
>
> It's true that, on many systems, all pointer types have the same
> representation, but the language does not make this assumption.
>
> I think the use of the unadorned word "pointer" can lead to a great
> deal of confusion.  A pointer object and a pointer value are two
> very different things.
>
> It seems to me like you dislike the fact that C doesn't let you
> treat pointer objects as if they were of different pointer types.
> That's fine; there are certainly things I dislike about C (though
> that's not one of them).  But the language is the way it is.
> You might even consider the possibility that there might be rational
> reasons for for some of the decisions, even if you might not
> agree with them.
>
> And there are plenty of other languages -- including the C-like
> dialect that gcc implements.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
> Nokia
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

== 11 of 21 ==
Date: Sat, Jan 9 2010 7:04 am
From: spinoza1111

On Jan 9, 1:50 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-01-09, Mark Adler <mad...@alumni.caltech.edu> wrote:
>
> > On 2010-01-08 20:12:55 -0800, Keith Thompson said:
> >> Since the operand of the cast was of a different type,
> >> there is no such object.
>
> > Sez you.  If what you said was correct, then we should never be able to
> > cast a pointer to another pointer type, since that object it's pointing
> > to doesn't exist.
>
> You don't seem to have understood the difference between the pointer
> and the thing pointed to.

I have said it before, and I'll say it again. You and the other regs
consistently morph friendly technical discussions into cybernetic
lynchings by starting this shit, Peter. You start using language that
instead of sticking to the technical issues, challenges the
professional standing of your interlocutor. You did this with Schildt,
and now it appears that you are doing it to Adler. And he's the guy
with the track record in technology, it appears now from his email and
the wikipedia article.

He wants to use C in one of the ways it was originally intended: as a
(somewhat) machine independent assembly language. Had you ever
programmed in assembler language, you'd know that it uses puns in many
cases including "void" pointers: in fact, in pure assembler, all
pointers are void, and we somehow figured out how to manage this. It
wasn't great (which is why I debugged a nonworking Fortran compiler in
1972) but it was doable.

Whereas C programmers in a contradictory fashion want people to think
of their language as simultaneously Adult (portable and Standard) yet
also Close to the Machine where they can, like Peter Pan, have Fun.
>
> When you convert a pointer to a new type, you may well create a new
> value which is different from the value you converted.
>
> > Uh oh.  Now I'm really worried, if having different, non-transferrable
> > data pointer representations is permitted by the C standard.  I sure
> > hope you're wrong.
>
> No, he's not.  They've been around forever and have been essential for some
> high-performance systems.
>
> > So is it not true that void * must be able to be a vessel for a pointer
> > to any data object?
>
> Of course it must.
>
> But that means a conversion.  And in some cases, the conversion actually changes
> the bit contents or even SIZE of the pointer.
>
> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 12 of 21 ==
Date: Sat, Jan 9 2010 7:09 am
From: spinoza1111

On Jan 9, 2:16 pm, Mark Adler <mad...@alumni.caltech.edu> wrote:
> On 2010-01-08 21:47:42 -0800, Seebs said:
>
> > On some real-world systems, "(int *)" and "(void *)" have different
> > representations.
>
> For example ...?

At runtime, I would have the choice:

(1) Let the pointer to int be a four byte (assuming the existence of
bytes in the first place) value which has to be multiplied by four
every time I use it (assuming byte addresibility and 32 bit ints)

(2) Let the pointer be a byte address at all times which is always
divisible by four if all ints must be aligned.

Number (1) is a major performance boner: you might as well be using
array indexes in Visual Basic.

I understand that pointers come in different flavors, especially on
different machines. But in most cases, having different pointer
"shapes" in machine language is a design flaw.
>
> Mark

== 13 of 21 ==
Date: Sat, Jan 9 2010 7:10 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <2010010819433816807-madler@alumnicaltechedu>,
Mark Adler <madler@alumni.caltech.edu> wrote:
>On 2010-01-08 19:20:53 -0800, Keith Thompson said:
>> Mark Adler <madler@alumni.caltech.edu> writes:
>>> In the good old days, any self-respecting C compiler knew ...
>> Arithmetic has *never* been permitted on void* by standard C.
>
>I wasn't talking about the standard. I was talking about the compilers.
>
>> There as been no dumbing down of the language;
>
>You're correct. I meant dumbing down of the compilers to agree with
>the religious extremism of the standard.
>
>> If you want to advance a void* so it points n bytes later in memory,
>> you can do this:
>> buf = (char*)buf + n;
>
>Thank you. That's what I'll do. Of course, at the loss of the
>expessiveness and readability of the wonderful += operator of C.

Mark - I'm curious. How did this issue become a problem for you.

Presumably, you were tootling along just fine, doing arithmetic on your
void *s, thinking nothing of it. Then, something changed to make it a
problem. Did you switch compilers (I'm going to guess from gcc [a
sensible compiler] to something else, something more religious, something
more in keeping with the tards on this newsgroup)

Or, did you "upgrade" to a newer version of gcc, that has more warnings?
Are you under some corporate mandate that your code must compile w/o
warnings?

== 14 of 21 ==
Date: Sat, Jan 9 2010 7:11 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <2010010820015043658-madler@alumnicaltechedu>,
Mark Adler <madler@alumni.caltech.edu> wrote:
>On 2010-01-08 19:59:33 -0800, Mark Adler said:
>> On 2010-01-08 19:57:52 -0800, Dennis \(Icarus\) said:
>>> Morris Keesan explains this nicely.
>>
>> What is this in reference to?
>
>Oh, I see -- another post here.
>
>I wasn't convinced by the argument that because sometimes casting
>results in something that's not an l-value, that you must then assume
>that all casts cannot be an l-value.
>
>Mark
>

Then you're just not into the dogma in force around here.

== 15 of 21 ==
Date: Sat, Jan 9 2010 7:14 am
From: spinoza1111

On Jan 9, 3:50 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Mark Adler wrote:
>
> > Now I can play the game!  (Gets up on soap box ...)  I assert that a
> > function that takes a void * pointer and a size_t length to identify a
> > thing makes no sense whatsoever in the C standard, since length has no
> > meaning with respect to the void * pointer.  
>
> Nonsense, the size is the size of the data pointed to.  What the data is
> is irrelevant.
>
> > Yet there are many such
> > functions that are also part of the C standard, such as memcpy(),
> > write(), etc.  They should all really be char *, since only then can the
> > length have meaning.  
>
> How so?  the length is a length in bytes.  I really think you either
> don't understand the concept of void*, or you are being obtuse.
>
> > Those functions are in a sense implying char *
> > through the meaning of the length, but presenting void * as the argument
> > instead, and are therefore lying.  (I realize of course that they do
> > this for the convenience of not having to cast to (char *) everytime you
> > use one of those functions.)
>
> Eh?
>
> consider
>
> int n;
> write( &n, sizeof(n) );
>
> > I would argue that alternatively we could eliminate this mixed message
> > of void both implicitly having a size and not having a size by changing
> > the C standard to give void a size, i.e. one.  sizeof(void) == 1.  
>
> Nowhere does void implicitly have a size.
>
> > Nothing would break -- this would just add to the things that can be
> > expressed, in a way that is consistent with how library functions use
> > void * arguments.  (The void type would still not be allowed by itself,
> > and so function(void) would still mean no arguments.)  In fact, in the
> > evil gcc, n = sizeof(void); sets n to 1, and it seems to work fine.
>
> So nonsense like:
>
> int n;
> int *p = n;
>
> ...
>
> void* v = p;
> ++v;
>
> would become legal?

It is well known that legal C code can be bulls*t. There is (was?)
even a contest for producing the worst (most obfuscated) but legal
(compiles and runs) C code. C is a used Ford Pinto, fun to drive in
its own way as long as you realize you're putting your life on the
line.
>
> --
> Ian Collins

== 16 of 21 ==
Date: Sat, Jan 9 2010 7:15 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <op.u58xsblm5qv6o3@toshiba-laptop>,
Morris Keesan <mkeesan@post.harvard.edu> wrote:
...
>I've been programming in C since before the "void" type was invented, and I
>don't think I've ever encountered a compiler that would do arithmetic on
>(void *) objects. Since arithmetic on pointers is defined in terms of the
>size of the object pointed to, why would you assume that sizeof(void) == 1?

You've never used gcc?

Not that that is impossible, of course, but, as the saying goes, it
sounds like bullshit to me.

== 17 of 21 ==
Date: Sat, Jan 9 2010 7:16 am
From: Mark

spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Jan 9, 11:57 am, "Dennis \(Icarus\)" <nojunkm...@ever.invalid>
> wrote:
>>
>> The C language is defined b the standard. Do you want to program in C or
>> not?
>
> No, from the standpoint of science (linguistics), no standard can
> "define" C. This is because independent of the standard are all sorts
> of C compilers with a fuzzy relation to any one formal definition of
> C. Somewhat like world received English, C is what intelligent users
> "say" it is. In addition, linguists also add that the language should
> be the canonical user's first language, but this is impossible with C,
> of course.

Using norms from the realm of natural languages isn't necessarily
helpful. Natural languages and computer languages share much in common,
but much is not common. Indeed, you note one further down, when you
point out that it would difficult for anyone to claim C as their first
language.

Whilst it's true that (in line with natural languages) there are many
dialects of C, programming languages are (I would argue) necessarily
constrained by the need for programmers to agree very specific outcomes
to very specific constructs; where (most) humans will happy handle (a
certain level of) variation in usage and still be able to comprehend the
essential meaning of the words, most computer languages and their
execution environments struggle to be more than literal. As a result
(and in my experience), languages which don't have formal definitions
which implementations *try* to conform to tend to either exist in a
monoculture (as single implementations) or fail to gain widespread
adoption.

What I'm saying is, there *is* a widely agreed definition of what C
"is", and that's not invalidated by the fact that most implementations
(to one extent or another) fail to fully conform.

To address the issue of "C is what intelligent users say it is", to an
extent I agree. Equally (as with revisions of the OED), it's also
almost the other way round in that "C adapts to reflect what intelligent
users demand". As a result, subsequent revisions of the standard tend
to take on board the best ideas of non-conforming implementations and,
as a result, many features from many different "C" compilers have ended
up as part of future standards. That's as it should be.

It would be nice to think, however, that both compiler writers *and*
software engineers (try to) only go outside the standard deliberately,
and are fully aware of what that means. As someone who has (over the
course of a twenty year career) had to deal with cross platform
development, environment changes, moves between 16, 32 and 64 bit
implementations and so on, life is *much* easier where that is built
into the assumptions of the developers from the start.

Of course, it also depends on the context. If the code is *known* to be
used within quite limited environments and, perhaps more significantly,
if it's known to be short-lived*, this becomes less important.

* I have, however, known code that "will only be in use for the next
couple of months" that suddenly became permanent.

>> Yes it is, and dereferencing it will cause problems.
>
> But if it is a pointer in truth, why would dereferencing it cause
> problems, oh Divine Master? Yea this is hard for us mere mortals to
> understand! For what is a pointer but that which dereferenceth?

In C, a pointer is something which can contain something which looks
like a pointer. If it contains a valid pointer, it can be safely
dereferenced. If it contains something which looks like a valid pointer
but isn't (isn't a pointer or isn't valid), it will cause a problem.

>> That's assembly though - not C.
>
> Oh divine Master, thou speakest horseshit indeed: for hath not C a
> register declaration? And are we not supposed to think ahead a little
> bit to what happeneth when our code runneth? Yea, verily they speak
> with forked tongue who say, "behold: C is close to the Machine, and if
> thou codest in C, thou shalt be one with the Machine, warm in winter
> owing to the heat of its circuitry, cool in summer's heat owing to its
> air conditioning", but then slay those, as Seebach has slain those,
> who darest to speak of the mysteries of runtime such as the Stack, or
> here the Register.

Unfortunately, "register" is somewhat tricky concept in C. There is no
obligation for the register keyword to do anything. The "register"
storage-class specifier hints to the compiler that this storage
declaration declares an object (small-o) which the compiler should try
to ensure fast accesses to. That request may be validly disregarded.
In some implementations (and originally, hence the wording) this may
be achieved by ensuring that it's kept in a register. If an
architecture has a way of producing fast accesses which doesn't involve
registers, the compiler is perfectly entitled to emit code as a direct
result of "register" which has nothing to do with registers.

== 18 of 21 ==
Date: Sat, Jan 9 2010 7:22 am
From: spinoza1111

On Jan 9, 5:13 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> Seebs wrote:
> > On 2010-01-09, Mark Adler <mad...@alumni.caltech.edu> wrote:
> >> On 2010-01-08 20:12:55 -0800, Keith Thompson said:
> >>> Since the operand of the cast was of a different type,
> >>> there is no such object.
> >> Sez you.  If what you said was correct, then we should never be able to
> >> cast a pointer to another pointer type, since that object it's pointing
> >> to doesn't exist.
>
> > You don't seem to have understood the difference between the pointer
> > and the thing pointed to.
>
> > When you convert a pointer to a new type, you may well create a new
> > value which is different from the value you converted.
>
> >> Uh oh.  Now I'm really worried, if having different, non-transferrable
> >> data pointer representations is permitted by the C standard.  I sure
> >> hope you're wrong.
>
> > No, he's not.  They've been around forever and have been essential for some
> > high-performance systems.
>
> >> So is it not true that void * must be able to be a vessel for a pointer
> >> to any data object?
>
> > Of course it must.
>
> And therein lies the nub of his problem (I think). A void* is a generic
> pointer to an object of unspecified type and so unknown size. The rules

A void pointer is a thing of holy dread
It may only be copied, writ or read
If thou dost arithmetic on a void pointer
Thou shalt be damn'd in the hereinafter.
Hark, I here Satan and his imps
Coming to get you twerps and gimps
Who darest to increment a void pointer
Jes' cuz it's permitted by your compiler!
Hell and Perdition yawn for thee
Heaven's trumpets summon me
For I codeth standard C
And I shall wear dem golden sandals
Whilst in Hell thou'rt sodomiz'd wif candles!

> of pointer arithmetic specify that the unit of change for incrementing
> or decrementing a pointer is the size of the data type it is pointing
> to. So what should be the value of ++v_ptr (where that is of type
> void*). The compiler has no idea and when faced with that there are two
> choices, refuse to attempt it (which is what the C Standard mandates) or
> use a default (and early versions of GNU C did that)
>
> Why did GNU C make that choice? Perhaps unwisely, to help with
> converting pre ISO C code where char* was sometimes used as a generic
> pointer. Incidentally that usage is probably why char* and void* were
> required to have the same size and layout.

== 19 of 21 ==
Date: Sat, Jan 9 2010 7:23 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <2010010820513527544-madler@alumnicaltechedu>,
Mark Adler <madler@alumni.caltech.edu> responded to our own little Kiki
thusly:
...
>Uh oh. Now I'm really worried, if having different, non-transferrable
>data pointer representations is permitted by the C standard. I sure
>hope you're wrong.

Here, I think you are barking up the wrong tree. Kiki is wrong about
just about everything and anything that is useful or relevant, but when
it comes to the C standard, he is never wrong. As we know, he sleeps
with a copy of it under his pillow.

You might want to search Google groups for a post I made some time ago
about Kiki preparing for a vacation on a sunny tropical isle. I think
if you search for author (Kenny MacCormack - or however I spell it) and
the word "lotion" (or maybe "oil"), you should find it.

== 20 of 21 ==
Date: Sat, Jan 9 2010 7:25 am
From: spinoza1111

On Jan 9, 5:17 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Mark Adler wrote:
> > On 2010-01-08 22:59:53 -0800, Beej Jorgensen said:
>
> >> On 01/08/2010 08:12 PM, Mark Adler wrote:
> >>> My current copy of gcc (4.2.1) will, with all warnings enabled (-Wall)
> >>> is perfectly happy with (no warnings):
>
> >>> void *buf;
> >>> int n;
>
> >>> buf += n;
>
> >> gcc -pedantic:
>
> >> foo.c:9: warning: pointer of type 'void *' used in arithmetic
>
> >> Perhaps it's only warning idiots like me?  ;-)
>
> > Apparently -Wall really only means -Wsome.
>
> Well, as far as I can tell, it really means "ALL the warnings the gcc
> development team think might be handy" - i.e. hardly any. When writing
> portable C, at a bare minimum you want -W -Wall -ansi -pedantic

Portable C is an oxymoron. Any responsible port of C takes if done
properly the same time as a rewrite in Java, or more. Therefore, any
organization with an inventory of C contemplating a port to a new
machine should rewrite the code in Java UNLESS the code is truly time-
critical, because the time it takes to do an acceptable job of
verifification that the C code will work on the new platform can be
used to rewrite in Java, which is portable, period.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

== 21 of 21 ==
Date: Sat, Jan 9 2010 7:43 am
From: spinoza1111

On Jan 9, 10:46 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 1/8/2010 9:51 PM, Mark Adler wrote:
>
> > Helpful C swamis,
>
> > In the good old days, any self-respecting C compiler knew what you meant
> > when you did arithmetic on a void * pointer, i.e. that the units were
> > bytes.
>
>      If by "the good old days" you mean "before the ANSI Standard
> in 1989," you might be sort of right.  In those days there was no
> formal definition of C, and all manner of compilers bestowed the
> "C" label on themselves.  Some of those may have had a void* type
> (K&R C did not), and some of those may have permitted arithmetic
> on that type.  I never ran across a pre-ANSI compiler with these
> characteristics, but there were lots and lots of compilers I
> never ran across at all.
>
>      Also, if it's pre-ANSI C you speak of, I dispute the adjective
> "good."
>
>      Starting with ANSI C, which first (formally) introduced void*
> to the language, no conforming compiler has ever permitted
> arithmetic on void* values.  The only compiler I happen to know
> of that permits it is gcc (in a non-conforming mode), but perhaps
> there are others.  There are certainly "self-respecting" compilers
> that follow the language definition and forbid it.
>
> > Then someone decided that we would all be more productive somehow
> > if the compilers couldn't figure out obvious things like that on their
> > own. So now you can't do arithmetic on void * pointers.
>
>      It'd be bogus.  Since void is an incomplete type, the sizeof
> the thing a void* points at is unknown.  

This is incorrect. Since C is a weakly typed and punning language
which permits values to be casted with few constraints, what you call
an "incomplete" pointer is a Von Neumann pointer to the smallest
addressable unit, whose size is by definition, 1. C assumes von
Neumann architecture.

> That's what makes void*
> useful in the first place: You can point it at anything at all
> without worrying about the sizeof the target.  

On the one hand, the *imams* here of Holy C claim of its pathology
(such as the fact that sprintf() can be broken at any time in running
code simply by passing it a to-long string) that if one is "competent"
one won't get bitten (although it is impossible to write code that
prevents the sprintf() problem without predeciding a limit that should
not be predecided).

On the other hand, having blessed all sorts of nonsense, they suddenly
get religion when it comes to void pointer arithmetic, like the vicar
returning from the whorehouse goin' back to church!

>The very same void*
> variable can point at a char, an int, and a struct foobar, all
> during a single execution of one program.  What is "the" size of
> all these different targets?
>
>      Here's another incomplete type, and an example of how it
> might be used in a hypothetical implementation of an ADT:
>
>         struct unknown;                         // incomplete type
>         struct unknown * newUnknown(int);       // a "constructor"
>         struct unknown * uptr = newUnknown(42); // instantiation
>
> Okay, uptr (we'll suppose) now points at a struct unknown instance.
> If you now do ++uptr, what ought to happen?  Should the address
> advance by one byte?  Forty-two bytes?  Eleven?  Where is the
> "one past the end" location for the struct unknown object whose
> size is a mystery?  Arithmetic on a void* encounters exactly the
> same problem: The size of the target is unknown, so the compiler
> can't know how far to advance the pointer.
>
Apples and oranges. A struct has different lengths. Memory has a
smallest addressable unit. The fact that there might be constraints on
addresses at the smallest unit (alignment) doesn't change this.

> > Ok, fine. So I adjusted, I would do this:
>
> > void *buf;
> > int n;
>
> > (char *)buf += n;
>
>      This is also bogus, for the same reason (double)n += 0.42
> would be bogus.  The left-hand side is an expression with an
> operand, an operator, and a value, not an object to which you
> can assign something (I'm speaking somewhat loosely here; look
> up the term "assignable lvalue" for a more rigorous treatment).

Brilliant. Yet Another piece of silliness alongside sequence points,
invented PURELY to pretend that C is a grown-up's language: the
Unassignable LValue! A pointer that cannot be dereferenced! It's a
bird! It's a plane! It's a mule!
>
> > But now I'm getting nastygrams like "warning: target of assignment not
> > really an lvalue; this will be a hard error in the future". Once again
> > someone, probably the same person, decided that compilers shouldn't have
> > to burden this great responsibility of understanding obvious things like
> > that. (And why a cast of a pointer to another pointer type is no longer
> > a pointer, I have no idea.)
>
>      Because the cast is an operator that derives a value from
> its operand.  Try this one: (char*)(ptr + 42) = "Hello".  Where
> do you think the pointer to 'H' should be stored, and why?
>
> > So now what am I supposed to do? It starts to get just downright silly.
> > E.g.
>
> > void *buf;
> > int n;
> > char *cmon;
>
> > cmon = (char *)buf;
> > cmon += n;
> > buf = (void *)cmon;
>
> > Is there a better way to work around this, at least until the *next*
> > dumbing down of the language?
>
>         buf = (char*)buf + n;
>
>      And before you say "That's just dim-witted," ponder
>
>         buf = (int*)buf + n;
>
>      It seems to me there are two misconceptions buried in your
> mental model of the language.  One is the notion that a pointer
> is "just an address," which is wrong: A pointer is an address
> *and* a type, and the type is important.  
> The second mistake is
> to think of the cast operator as meaning "let's pretend this
> thing is of a different type," when in fact it means "take the
> value of this thing, convert it to a new type, and deliver the
> converted value (which may even be unequal to the original)."
>
>      You are not the first to fall victim to these two mistaken
> notions, nor will you be the last.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

==============================================================================
TOPIC: a CPAN for C
http://groups.google.com/group/comp.lang.c/t/6d957d79a1c23dac?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 9 2010 5:57 am
From: "bartc"

"Richard" <rgrdev_@gmail.com> wrote in message
news:hi9vb7$sfk$3@news.eternal-september.org...
> Tom St Denis <tom@iahu.ca> writes:

>> [and to what]. I prefer code like
>>
>> {
>> declarations;
>>
>> initializations;
>>
>> code;
>> }
>
> How nOObish!
>
>>
>> I'm ok with things like
>>
>> if (blah) {
>> int x;
>> x = some_struct->member;
>> // blah...
>> }
>>
>> But I think declaring variables wherever is messy and shows a lack of
>> forethought/design [e.g. you're just making up variables mid thought
>> as opposed to fully thinking through your algorithm first].
>
> Local declaration is THE way to do it since no namepsaces are unduly
> polluted.

Functions already have a local namespace.

How big are your functions that you need to have multiple namespaces inside
them!

(I believe C allows you at least 1e50 distinct identifiers within one
namespace, and that's without even making use of case sensitivity.)

>
> If you dont agree then I suspect your code is like something from the
> ark.
>
> for(int i=0; i<LIMIT;i++){}
>
> Perfect, clean, readable.

Presumably you can also do this:

for(int i=0; i<LIMIT1;i++)
for(int i=0; i<LIMIT2;i++)
for(int i=0; i<LIMIT3;i++) int a=i+i+i;

Very neat.

--
Bartc

== 2 of 2 ==
Date: Sat, Jan 9 2010 6:22 am
From: Richard

"bartc" <bartc@freeuk.com> writes:

> "Richard" <rgrdev_@gmail.com> wrote in message
> news:hi9vb7$sfk$3@news.eternal-september.org...
>> Tom St Denis <tom@iahu.ca> writes:
>
>>> [and to what]. I prefer code like
>>>
>>> {
>>> declarations;
>>>
>>> initializations;
>>>
>>> code;
>>> }
>>
>> How nOObish!
>>
>>>
>>> I'm ok with things like
>>>
>>> if (blah) {
>>> int x;
>>> x = some_struct->member;
>>> // blah...
>>> }
>>>
>>> But I think declaring variables wherever is messy and shows a lack of
>>> forethought/design [e.g. you're just making up variables mid thought
>>> as opposed to fully thinking through your algorithm first].
>>
>> Local declaration is THE way to do it since no namepsaces are unduly
>> polluted.
>
> Functions already have a local namespace.

Yes. I know.

>
> How big are your functions that you need to have multiple namespaces inside
> them!

Huh? Immaterial. Keep the variable definition where its needed. It makes
ZERO sense to bunch them at the top.

>
> (I believe C allows you at least 1e50 distinct identifiers within one
> namespace, and that's without even making use of case sensitivity.)
>
>>
>> If you dont agree then I suspect your code is like something from the
>> ark.
>>
>> for(int i=0; i<LIMIT;i++){}
>>
>> Perfect, clean, readable.
>
> Presumably you can also do this:
>
> for(int i=0; i<LIMIT1;i++)
> for(int i=0; i<LIMIT2;i++)
> for(int i=0; i<LIMIT3;i++) int a=i+i+i;
>
> Very neat.

I'm not quite sure what you think that contrived example proves. Did you
seem me extrapolating the "bunched variables" idea to something like all
globals declared in a remote file? No. because thats silly and childish.

A basic paradigm of writing maintainable clean SW is to localise
variables to where they are needed. It also helps protect against
possible misuse of said variables.

Bunching them at the top is plain silly.

How can it NOT be clearer when reading code to see someting like

if(f){
int myCount=getNumber();
callFunc(myCount);
}

than

if(f)
callFunc(myCount);

and having to go off searching for myCount.

It's ridiculous to even try to argue against the benefits of localised
variable definitions.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

==============================================================================
TOPIC: Comparision of C Sharp and C performance
http://groups.google.com/group/comp.lang.c/t/4cf78a2afa73b77a?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 9 2010 6:14 am
From: spinoza1111

On Jan 9, 5:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> <snip>
>
> >> I think you've missed the point.  The parentheses around (a) are not
> >> the issue because they are, of course, correct.  The problem is the
> >> lack of parentheses around the conditional expression.
>
> > Correctomundo: the conditional expression violates "my" rule, which I
> > developed in 1990, that "each macro that intends to return an
> > EXPRESSION must return an EXPRESSION surrounded by PARENTHESES: each
> > macro that intends to return a STATEMENT must return a STATEMENT LIST
> > surrounded by BRACES".
>
> Macros don't return either expressions or statements.

Then you misunderstand their proper use despite your "expertise" in C.
If a macro returns anything else besides an expression or statement it
can cause errors. It can also cause errors if it is restricted by
outer parentheses or brackets to returning expressions-as-text or
statements-as-text, but this reduces the error space.

> They represent
> user-defined rules for relatively simple textual substitutions.
> Functions return expressions (never statements).

Wow, I'll alert the media. Functions return expressions? This is
nonsense. Functions return the values of expressions. I'd say you're
thinking of Lisp, but you probably know less about Lisp than you know
about the high concepts of C as opposed to coding details and trivia.

I suppose a function could return a pointer to a function and this
could be called (painfully) "returning an expression", but for a C
function to return an unevaluated expression? It'd have to return the
source code and the user would have to call a C compiler!

That's one for the Heathfield tab of the Red Book, along with "Nilges
was never accepted to post at Comp.risks" and over in the Seebie tab,
"the 'heap' is a DOS term".

> Operators are sometimes
> spoken of as returning expressions (indeed, the Standard used to employ
> that turn of phrase in one or two places);

All the more reason to ignore a Standard which was written to make
vendors rich.

> more formally, they yield
> expressions. But macros don't return anything.
>
> <nonsense snipped>
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

== 2 of 2 ==
Date: Sat, Jan 9 2010 6:47 am
From: Francis Glassborow

spinoza1111 wrote:
> On Jan 9, 5:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111wrote:
>>> On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> <snip>
>>
>>>> I think you've missed the point. The parentheses around (a) are not
>>>> the issue because they are, of course, correct. The problem is the
>>>> lack of parentheses around the conditional expression.
>>> Correctomundo: the conditional expression violates "my" rule, which I
>>> developed in 1990, that "each macro that intends to return an
>>> EXPRESSION must return an EXPRESSION surrounded by PARENTHESES: each
>>> macro that intends to return a STATEMENT must return a STATEMENT LIST
>>> surrounded by BRACES".
>> Macros don't return either expressions or statements.
>
> Then you misunderstand their proper use despite your "expertise" in C.
> If a macro returns anything else besides an expression or statement it
> can cause errors. It can also cause errors if it is restricted by
> outer parentheses or brackets to returning expressions-as-text or
> statements-as-text, but this reduces the error space.

For someone who claims expertise in English your reading skills leave
much to be desired. A C pre-processor macro (which would be the default
use for the word 'macro' in this newsgroup) does not return anything; it
causes a textual substitution in the source code.

>
>> They represent
>> user-defined rules for relatively simple textual substitutions.
>> Functions return expressions (never statements).
>
> Wow, I'll alert the media. Functions return expressions? This is
> nonsense. Functions return the values of expressions. I'd say you're
> thinking of Lisp, but you probably know less about Lisp than you know
> about the high concepts of C as opposed to coding details and trivia.
>
> I suppose a function could return a pointer to a function and this
> could be called (painfully) "returning an expression", but for a C
> function to return an unevaluated expression? It'd have to return the
> source code and the user would have to call a C compiler!

1) In the terminology of C (and that is what we discuss here) a value is
a (trivial) expression.
2) the return statement in the body of the code does indeed return a(n
evaluated) expression.

>
> That's one for the Heathfield tab of the Red Book, along with "Nilges
> was never accepted to post at Comp.risks" and over in the Seebie tab,
> "the 'heap' is a DOS term".

Your behaviour is typical of the playground bully. You continue to use
quotes to taunt people.
>
>> Operators are sometimes
>> spoken of as returning expressions (indeed, the Standard used to employ
>> that turn of phrase in one or two places);
>
> All the more reason to ignore a Standard which was written to make
> vendors rich.

Then please do so and go somewhere else and waste your weekends and
holidays polishing your halo somewhere else.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en