Are ++ and -- operators really more efficient

[CBFalconer]

CBFalconer wrote:
.... snip ...


That's a unary **; a binary ** would be exponentiation. Compilers
have no problem distinguishing unary * from binary *, so your
complaint seems to be without merit.

A point, I think. I am used to parsing tokens in the lexer, rather
than the language grammer.

 

[Keith Thompson]

That's a unary **; a binary ** would be exponentiation. Compilers
have no problem distinguishing unary * from binary *, so your
complaint seems to be without merit.

No, there is no unary **; currently ** is two separate tokens.

If ** were added as an exponentation operator, would
x**y
mean x ** y, or x * (*y)? I suppose it could be resolved based
whether y has pointer type or not (with a special rule for 0, which
could be either a null pointer constant or a zero exponent), but I'm
uncomfortable with requiring that kind of feedback from semantic
analysis to parsing.

 

[Guest]

And you accuse Keith of over stating things? It seems the intent is
merely to dislodge bully boys like yourself and to broaden the scope a
little to more than how many bytes are in a word etc.


Like the ones where they point out errors in your book? Or where they,
yet again, point out that Chuck Falconer doesn't know his arse from his
elbow?


Because Han and co are not liars. If you can point out lies from him on
the topic of C all well and good. I suspect you can't. This makes you
the liar and you the problem.

he's forged posts. That may not be "on the topic of C" (it seems
strange
for you of all people to try and limit the scope in this way) but it
certainly looks like lieing to me

<snip>

 

[Flash Gordon]

he's forged posts. That may not be "on the topic of C" (it seems
strange
for you of all people to try and limit the scope in this way) but it
certainly looks like lieing to me

He has also stated that a post was by me when it clearly was not. That
is definitely lying.

 

[Stephen Sprunk]

No, there is no unary **; currently ** is two separate tokens.

If ** were added as an exponentation operator, would
x**y
mean x ** y, or x * (*y)? I suppose it could be resolved based
whether y has pointer type or not (with a special rule for 0, which
could be either a null pointer constant or a zero exponent), but I'm
uncomfortable with requiring that kind of feedback from semantic
analysis to parsing.

We rely on similar rules to distinguish whether x&&y means x&(&y) or x
&& (y).

Anyone who writes "x**y" to mean x*(*y) deserves to have their code
broken, IMHO. It is more likely they'd write the clearer "x * *y", in
which case the compiler could tell they weren't using a binary ** operator.

S

 

[Nate Eldredge]

We rely on similar rules to distinguish whether x&&y means x&(&y) or x
&& (y).

Anyone who writes "x**y" to mean x*(*y) deserves to have their code
broken, IMHO. It is more likely they'd write the clearer "x * *y", in
which case the compiler could tell they weren't using a binary **
operator.

True, but the standard isn't in the business of prescribing style, and
IMHO it's unacceptable to break code which the standard permits even if
it is stylistically poor. (It could be, for instance, that the code in
question was automatically generated and not intended to be
human-readable, and therefore stylistic issues were ignored. It might
even be desirable in such an instance to omit the whitespace and save
some bytes.)

What about using x^^y instead? It doesn't have the precedent of x^y or
x**y, but it's somewhat intuitive, and as far as I can tell, it wouldn't
break any legal code. (For better or worse, C doesn't have "logical
xor".)

 

[Keith Thompson]

We rely on similar rules to distinguish whether x&&y means x&(&y) or x
&& (y).

No, we don't. The "&&" in "x&&y" is a single "&&" token, regardless
of the types of the operands. This is handled entirely by lexical
analysis, using the "maximal munch" rule, when the compiler knows
nothing more about x and y than that they're identifiers.

Anyone who writes "x**y" to mean x*(*y) deserves to have their code
broken, IMHO. It is more likely they'd write the clearer "x * *y", in
which case the compiler could tell they weren't using a binary **
operator.

Yes, "**" could be added as a new token and a new binary operator. If
we retain the "maximal munch" rule, then "x**y" would mean "x ** y";
it would never mean "x * (*y)". The problem is that "x**y" means
"x * (*y)" in C as it's defined now, so the change you propose would
break existing code. Even if the code it would break "deserves" to be
broken, that's still a high hurdle to clear for a proposed new feature.

Even worse are ordinary cases like:
char **ptr;
Either every existing program that uses two adjacent '*' delimiters in
this way becomes illegal, or we have to make some very ugly changes to
the grammar to accomodate this. We could say that "**" is treated as
two "*" tokens in some contexts, but the lexical analysis phase
typically doesn't have enough information to know what the context is.
Or we could say that "**" is a single token that means the same thing
as two consecutive "*" tokens in some contexts, but that's ugly;
the identical meanings of
char ** * ptr ;
and
char * ** ptr ;
and
char * * * ptr ;
would have to be defined separately. It could be done, but I wouldn't
bet large sums of money on (a) the standard committee getting it right
in all possible cases, and (b) compiler writers getting it right in
all possible cases.

I like the idea of using "**" as an exponentiation operator, but I'm
afraid that fitting it into C without breaking things just isn't
feasible.

Using "^^" isn't quite as pretty, but it avoids all these problems.
"^" is a valid token, but I'm fairly sure there are no legal programs
with two adjacent "^" tokens. Presumably "^^=" would be added as
well.

 

[CBFalconer]

Keith Thompson wrote:
.... snip ...


We rely on similar rules to distinguish whether x&&y means x&(&y)
or x && (y).

I don't think that is legitimate. &y is an address, and returns a
pointer value. The & operator requires integer operands. In
addition the "max absorption" rule requires that the sequence "&&"
be parsed as the single and operation (I think).

 

[CBFalconer]

He has also stated that a post was by me when it clearly was
not. That is definitely lying.

I'm not advocating the Han-spammer, but that may well be simply a
mistake, rather than a deliberate lie.

 

[Flash Gordon]

Indeed. Too often people confuse lying and mistakes.

What are the chances of mistakenly thinking a post under a different
name from a different continent made using different software and about
something I would not consider topical and written in a different style
is by me? It was damned obvious that he had just decided to claim that
an off-topic post was actually by one of the regulars who sometimes
redirects people to other groups. In other words I am stating that I am
certain it was a deliberate lie, i.e. a false statement made in the full
knowledge that it was completely false. Also note that he presented no
justification for the claim when called on it, something that would be
expected had he any reason to suspect what he said was true.

 

[Phil Carmody]

We rely on similar rules to distinguish whether x&&y means x&(&y) or x
&& (y).

We absolutely don't. I personally rely on the lexer to distinguish
the two, and the lexer wouldn't know a pointer from a slap in the
face.

Phil

 

[Phil Carmody]

I'm not advocating the Han-spammer, but that may well be simply a
mistake, rather than a deliberate lie.

I had presumed that what was being talked about was forgery (a
clear, blatant lie), not misattribution (sometimes nothing more
than one too many ^K's).

Phil

 

[Ben Pfaff]

We rely on similar rules to distinguish whether x&&y means x&(&y) or x
&& (y).

As others have remarked, no we don't.

But x&(&y) has no possible valid meaning anyhow, since the binary
& operator requires both of its operands to hvae integer type,
but the unary & operator yields a result of pointer type.

 

[Stephen Sprunk]

As others have remarked, no we don't.

But x&(&y) has no possible valid meaning anyhow, since the binary
& operator requires both of its operands to hvae integer type,
but the unary & operator yields a result of pointer type.

My compiler accepts x&(&y), though it warns about converting a pointer
to integer without a cast.

To all the comments about the lexing/parsing/tokens/etc., I'll admit I
don't know enough about compiler design to understand the arguments.
However, I would expect that the compiler would be able to distinguish
the ** in "x**y" from the ** in "**p" due to the preceding object/value
(or lack thereof). Perhaps that expectation is not correct, in which
case I'll grant there may be technical difficulties in implementing a
binary ** operator.

S

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My compiler accepts x&(&y), though it warns about converting a pointer
to integer without a cast.

To all the comments about the lexing/parsing/tokens/etc., I'll admit I
don't know enough about compiler design to understand the arguments.
However, I would expect that the compiler would be able to distinguish
the ** in "x**y" from the ** in "**p" due to the preceding object/value
(or lack thereof). Perhaps that expectation is not correct, in which
case I'll grant there may be technical difficulties in implementing a
binary ** operator.

S

If the lexer can distinguish x && y from x&(&y), it would need to rely
on whitespace to do so (it should always parse x & & y as the latter).
Therefore, creating any kind of ** would break (vast reams of) existing
code.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJJb3+qAAoJEKmxP9YxEE4rtlgP/2I6OwjNP9dv7UTBT+rMTbI1
NBiWBgQllOqP/7jhiNl536uw8O8f0kjI99U9xepuPT6wJz9K8LAP3NvVJIG4Kd33
3RBjFap/OhCB/d7Ab6uqoCdBv5QDB4TlpZPUbVy04bDQxlivoLp1scYYal8qwwcH
iI6QG7FQzrPeuVRSVQcO/bm3Ny8KTpXIUmlnD82l3BQbV4Va0qyA++TpHCMSwfe0
jxT26KR54j0xEYpfVzpQfNZi6oobq3fF2k6sxkeewTYYz/2c/6wMpzNJObL1PCQY
M/redv8JfT7TY0PLkIF8m26LrYEggb7jnvEaX4masO25W2N0d5ZrwvbnXfA0vN3x
gpuR+gpggMu6gfPwCrcSCJltEIP4mwKgwiUz2wXV4PNbHeXbMmJQM0swtIX7DGwi
QwiXINqzSOdBpLQHqeiHK5exTKxXiehDDYG68tuGM2MYUxrMGbF8bPRBckU5nxTo
LPrdcEuwFirkNK4MGHzTnceUP9RIJutdj/6OIs1BSORDnHRa5TpwPUxNRXqwEAAC
vgeREwXHV+xHhuq1dSJrQ7Ex46NbuMnizP2qeawCJxOnYKALtgLwniNhM+XcKiCb
EDxylmRfdpm6Yv/dpGPKHTTERSSlyL+v+UW7vGjgo3j/zEGqxwilKBue+fr4CHoJ
PQS/sHdtN1lnBdE+Nri8
=Owvk
-----END PGP SIGNATURE-----

 

[Flash Gordon]

I had presumed that what was being talked about was forgery (a
clear, blatant lie), not misattribution (sometimes nothing more
than one too many ^K's).

Your presumption was wrong. What I was refering to was an explicit
statement that a post was by me when it was not. There was no chance
that is was missatribution since it was a reply to the first post in the
thread before I had posted in the thread.

 

[Flash Gordon]

Don't argue with me, argue with Falconer. He's the one who
raised the possibility. I own that I erred in thinking against
all evidence that he might possibly be right in something, and
for that I apologize.

I was correcting you as well as Chuck rather than arguing with you, that
is why I posted in reply to your message. No animosity involved on my part.

Chuck should have known better than to suggest it might have been a
mistake without actually checking. Especially as I made it pretty clear
I did not think there was a possibility of it being a mistake.

 

[Keith Thompson]

My compiler accepts x&(&y), though it warns about converting a pointer
to integer without a cast.

It's a constraint violation, so the only requirement is that the
compiler must issue a diagnostic. Either printing a fatal error
message and failing to translate, or printing a warning (and probably
performing a rather silly implicit pointer-to-integer conversion) is
valid behavior, allowed by the standard.

To all the comments about the lexing/parsing/tokens/etc., I'll admit I
don't know enough about compiler design to understand the
arguments. However, I would expect that the compiler would be able to
distinguish the ** in "x**y" from the ** in "**p" due to the preceding
object/value (or lack thereof). Perhaps that expectation is not
correct, in which case I'll grant there may be technical difficulties
in implementing a binary ** operator.

Take a look at the translation phases defined in C99 5.1.1.2.
Preprocesing tokens are resolved in phase 3. In that phase, there is
no "preceding object/value", there's only a stream of tokens, and no
distinction between
x ** y
where y is the name of a pointer object, and
x ** y
where y is the name of an integer object. That information doesn't
exist until phase 7. (Preprocessor tokens are converted into tokens
in phase 7, but a preprocessor token is always converted to a single
token.)

Compilers don't necessarily implement each phase as a separate program
(for example, the first several phases are typically combined into the
preprocessor), but the each phase does reflect the information that's
available at that point in translation.

In summary, && is *always* treated as a single token (<OT>even in C++,
where x&(&y) can be legal due to operator overloading</OT>); treating
** as either one or two tokens depending on the context would require
information that's not available at the point where the decision needs
to be made.

Note that typedefs complicate this model a bit. This expression:
(x)-1
might be either a cast applied to a unary minus, or a subtraction
whose left operand is a parenthesized expression. Which one it is
depends on whether x is a currently visible typedef -- which means
that the parser requires feedback from the symbol table. (This gave
me a few gray hairs some years ago, when I was working on a C parser.)
But parsing and symbol table management both take place during phase
7, so in principle at least it's not as much of an issue. The C
grammar *could* have been designed, and some language grammars are
designed, so that a translation unit can be parsed without any
semantic analysis (knowledge of declarations, etc.), but since
typedefs were added relatively late that wasn't practical.

 

[Mark Wooding]

On some earlier processors (like the PDP-11 and the MC68000), some
assembly instructions had an "auto-increment" and "auto-decrement"
variation. The instruction would use the value of "i" and then
*also* do the increment or decrement--all in the same instruction.

Just to bring the conversation a little up-to-date, I'll mention that
ARM processors has these kinds of addressing modes. In particular,

ldr r0, [r1], #4 ; post-increment: r0 = *p++
ldr r0, [r1, #4]! ; pre-increment: r0 = *++p
ldr r0, [r1], #-4 ; post-decrement: r0 = *p--
ldr r0, [r1, #-4]! ; pre-decrement: r0 = *--p

(You can replace the constants #4 and #-4 by other small integers, use
LDRB instead of LDR for byte reads, and STR/STRB for storing. To a
lesser extent, you can also play similar games with the LDM and STM
instructions.)

I think that the ARM compilers are intelligent enough to do use these
addressing modes even without the rather unsubtle prompting implied by
the `++' and `--' operators. On the other hand, there are good reasons
why processor architectures provide addressing modes such as these:
they're very frequently applicable in all sorts of situations, and I
think it's right to use C's idiomatic operator-clusters for these kinds
of operations.

-- [mdw]

 

[Mark Wooding]

No.

Falcon Kirtaran is presumably using an RSA key. RSA signatures are very
large. If I'm going to sign a message, I'll use DSA or some variant of
it, which gives signatures that are at most a third the size of RSA for
equivalent security, and this ratio falls -- quite sharply -- for higher
security levels. The technical reasons for this are on-topic over in
sci.crypt -- where I'll be happy to explain in excruciating detail --
but not here.

Boneh--Lynn--Shacham signatures are even shorter (half the length), but
they require hairy mathematics -- in particular, Tate or Weil pairings
on elliptic curves -- and OpenPGP implementations don't support them.

As an example the message itself could be passed through a CCITCRC
generator. The result is a 16 bit unsigned int, which can be
expressed in a 4 char hex display. That can go in the headers (as an
x-hdr). The sig marker can be used as a message end marker, thus
allowing some providers to append a marker of their own.

You're obviously not even close to being a cryptographer. For a start,
a CRC such as you suggest is unkeyed -- there's nothing tying the author
to the message: anyone can modify the message (or just generate a new
one) and compute the right CRC. Secondly, there's no asymmetry here, so
anyone who can verify the CRC can generate a new one. Finally, CRCs are
linear, so under some circumstances you can work out how to modify the
CRC and message to construct a forgery without actually knowing either.

Digital signatures are the right tool for this job. Indeed, anything
which solves this problem -- allowing third parties to distinguish
authentic messages from forgeries without being able to construct new
authentic messages -- is by definition a digital signature scheme.

-- [mdw]