Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Strange C operator

Reply
Thread Tools

Strange C operator

 
 
email7373388@kinglibrary.net
Guest
Posts: n/a
 
      01-30-2008
I'm working on a program which has a strange operator, :>. This is
the syntax:

((unsigned short)( var1)):>((void __near *)( var2 ))

Any clue?
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      01-30-2008
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
>I'm working on a program which has a strange operator, :>. This is
>the syntax:


>((unsigned short)( var1)):>((void __near *)( var2 ))


>Any clue?


ISO C 6.4.6

In all aspects of the language, these six tokens
<: :> <% %> %: %:%:
behave, respectively, the same as these six tokens

[ ] { } # ##

except for their spelling.

--
"All is vanity." -- Ecclesiastes
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-30-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> I'm working on a program which has a strange operator, :>. This is
> the syntax:
>
> ((unsigned short)( var1)):>((void __near *)( var2 ))
>
> Any clue?


:> is an alternate spelling of ] , one that can be used
even with a keyboard that lacks the ] character. The complete
list of these "digraphs" is

<: [
:> ]
<% {
%> }
%: #
%:%: ##

The underlying problem is that traditional C source uses
characters that are not in the "invariant subset" of the
ISO/IEC 646 character set standard; some of C's characters
are used for other purposes in local character sets. The
digraphs provide ways to spell C operators that use "variant"
characters, even on keyboards that have a Yen sign, say,
rather than one of the characters C source uses.

The odd thing is that this same problem has also been
addressed in another way, through the use of *tri*graphs:

??= #
??( [
??/ \
??) ]
??' ^
??< {
??! |
??> }
??- ~

.... which have been around since the original ANSI C Standard
and still work. Indeed, the digraphs only work in "open code"
and not in string literals and character constants:

#include <stdio.h> /* these */
%:include <stdio.h> /* are */
??=include <stdio.h> /* equivalent */

but

puts ("#"); /* prints octothorpe */
puts ("??="); /* prints octothorpe */
puts ("%:"); /* prints percent and colon */

As far as I can see, the digraphs don't add anything that wasn't
already possible with trigraphs (or with the original large set
of C source characters, of course), but seem to have been added
just because they're thought to be more readable.

The practical value is that you can amaze your friends with
things like

%:include <stdio.h>
int main(void)
<%
printf ("O brave new world!??/n");
return 0;
??>

--
(E-Mail Removed)
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-30-2008
In article <1201727105.616296@news1nwk>,
Eric Sosman <(E-Mail Removed)> wrote:
>(E-Mail Removed) wrote:
>> I'm working on a program which has a strange operator, :>. This is
>> the syntax:
>>
>> ((unsigned short)( var1)):>((void __near *)( var2 ))


> :> is an alternate spelling of ] , one that can be used
>even with a keyboard that lacks the ] character.


But that doesn't look like a plausible explanation in this case, since
a ] character would make no sense.

And the __near suggests it's not exactly portable C. Perhaps the
OP could post a larger fragment, and explain where the code comes from?

-- Richard
--
:wq
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-30-2008
Richard Tobin wrote:
> In article <1201727105.616296@news1nwk>,
> Eric Sosman <(E-Mail Removed)> wrote:
>> (E-Mail Removed) wrote:
>>> I'm working on a program which has a strange operator, :>. This is
>>> the syntax:
>>>
>>> ((unsigned short)( var1)):>((void __near *)( var2 ))

>
>> :> is an alternate spelling of ] , one that can be used
>> even with a keyboard that lacks the ] character.

>
> But that doesn't look like a plausible explanation in this case, since
> a ] character would make no sense.


Plausible or not, ] is what it is. Maybe the O.P.'s
attention was drawn to this line because the compiler honked
about a syntax error?

> And the __near suggests it's not exactly portable C. Perhaps the
> OP could post a larger fragment, and explain where the code comes from?


It'd be nice to see a little more context, yes. Something
about the identifiers and the lavish use of parentheses suggests
that what we see is snipped from the middle of a macro definition.

--
(E-Mail Removed)
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-30-2008
In article <1201735819.744335@news1nwk>,
Eric Sosman <(E-Mail Removed)> wrote:

>>>> I'm working on a program which has a strange operator, :>. This is
>>>> the syntax:
>>>>
>>>> ((unsigned short)( var1)):>((void __near *)( var2 ))


>>> :> is an alternate spelling of ] , one that can be used
>>> even with a keyboard that lacks the ] character.


>> But that doesn't look like a plausible explanation in this case, since
>> a ] character would make no sense.


> Plausible or not, ] is what it is.


If the code is, in fact, intended to be (post-digraph) standard C,
rather than some other C-like language, and has not been damaged in
transit (e.g. by character set conversion).

Of course, it could just be a smiley :>

-- Richard
--
:wq
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-31-2008
Eric Sosman <(E-Mail Removed)> writes:
> Richard Tobin wrote:
>> In article <1201727105.616296@news1nwk>,
>> Eric Sosman <(E-Mail Removed)> wrote:
>>> (E-Mail Removed) wrote:
>>>> I'm working on a program which has a strange operator, :>. This is
>>>> the syntax:
>>>>
>>>> ((unsigned short)( var1)):>((void __near *)( var2 ))

>>
>>> :> is an alternate spelling of ] , one that can be used
>>> even with a keyboard that lacks the ] character.

>>
>> But that doesn't look like a plausible explanation in this case, since
>> a ] character would make no sense.

>
> Plausible or not, ] is what it is. Maybe the O.P.'s
> attention was drawn to this line because the compiler honked
> about a syntax error?

[...]

It's ] *if* the compiler supports it. Digraphs were introduced in the
C95. It's conceivable that the compiler is an old one that doesn't
support digraphs, but has some other extension that uses :>. That
doesn't seem likely, though.

Yes, more context would be helpful.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
email7373388@kinglibrary.net
Guest
Posts: n/a
 
      01-31-2008
I'm getting this when I try to compile:
error C2215: ':>' operator only for objects based on 'void'


This is the line that's blowing up:

return (BYTE *) MAKE_FAR (0x34, address);


And this is the macro that defines the thing:

#define MAKE_FAR( var1, var2) (((unsigned short)( var1)):>((void
__near *)( var2 )))

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-31-2008
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
>I'm getting this when I try to compile:
>error C2215: ':>' operator only for objects based on 'void'


>This is the line that's blowing up:


>return (BYTE *) MAKE_FAR (0x34, address);


>And this is the macro that defines the thing:
>
>#define MAKE_FAR( var1, var2) (((unsigned short)( var1)):>((void
>__near *)( var2 )))


It appears to me that you are using a compiler that has
an extension.

I would speculate that the extension operator
creates a far pointer by splicing the integer given by the
first argument on to the beginning of the address.
Or possibly on to the end of the address. Or possibly
it takes the integer and uses it as a segment number in addition
to the address. The variation that would sound most useful
to me is if the pointer it took (as the second parameter)
were the pointer to the base of a far pointer and the integer
given was spliced in as the offset into that far pointer.

How to solve the problem? Dunno -- the operator is not part
of C, so I can only guess what it is supposed to do. But
considering the message you are getting, my first experiment
would be to try removing the __near from the MAKE_FAR
macro definition. If that didn't work, I would see if I could
find some documentation.
--
'Roberson' is my family name; my given name is 'Walter'.
 
Reply With Quote
 
email7373388@kinglibrary.net
Guest
Posts: n/a
 
      01-31-2008
> It appears to me that you are using a compiler that has
> an extension.


At one point it was compiled with a Watcom compiler on an old DOS
system. I've done a good amount of searching for documentation. I
may just run some tests and do some investigation to see what happens
to the program downstream. Thanks for the reply.
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
T::operator int () const ambiguous with T::operator Handle () const? Tim Clacy C++ 15 05-30-2005 02:14 AM
Member operators operator>>() and operator<<() Alex Vinokur C++ 3 03-20-2005 03:11 PM
operator*(Foo) and operator*(int) const: ISO C++ says that these are ambiguous: Alex Vinokur C++ 4 11-26-2004 11:46 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM
Q: operator void* or operator bool? Jakob Bieling C++ 2 03-05-2004 04:27 PM



Advertisments