I'm working on a program which has a strange operator, :>. This is
the syntax:

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

Any clue?

In article <765d62e8-4da4-402e-a735-f0f7830f56cb@v17g2000hsa.googlegroups.com>,
<email7373388@kinglibrary.net> 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

email7373388@kinglibrary.net 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;
??>

--
Eric.Sosman@sun.com

In article <1201727105.616296@news1nwk>,
Eric Sosman <Eric.Sosman@sun.com> wrote:
>email7373388@kinglibrary.net 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

Richard Tobin wrote:
> In article <1201727105.616296@news1nwk>,
> Eric Sosman <Eric.Sosman@sun.com> wrote:
>> email7373388@kinglibrary.net 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.

--
Eric.Sosman@sun.com

In article <1201735819.744335@news1nwk>,
Eric Sosman <Eric.Sosman@sun.com> 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

Eric Sosman <Eric.Sosman@sun.com> writes:
> Richard Tobin wrote:
>> In article <1201727105.616296@news1nwk>,
>> Eric Sosman <Eric.Sosman@sun.com> wrote:
>>> email7373388@kinglibrary.net 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 ful.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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 )))

In article <76dce5be-9069-4de6-b9e0-6e66bcffb40f@k39g2000hsf.googlegroups.com>,
<email7373388@kinglibrary.net> 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'.

> 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.

One more thought on your comment about an extension... the compile
process did include a bunch of pharlap libraries. I'm not familiar
with pharlap but possibly it has something to do with that?

Also, the compiler errors I'm getting are from Visual C++ 6, and that
error (C2215) is nowhere to be found in the MS documentation, although
the compiler spits it out.

In article <11502156-a01d-436e-997b-7d4e06b5d460@z17g2000hsg.googlegroups.com>,
<email7373388@kinglibrary.net> wrote:
>Also, the compiler errors I'm getting are from Visual C++ 6, and that
>error (C2215) is nowhere to be found in the MS documentation, although
>the compiler spits it out.

If you google for the error message, you'll find it in some lists of
Microsoft C errors, but only a few, so I conjecture that it's a
feature from some very old version of the compiler that's no longer
documented.

You might be better off asking in some Microsoft group: there's probably
a more modern equivalent, if it still makes sense at all.

-- Richard


--
:wq

email7373388@kinglibrary.net 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 looks like the macro was written for a C-like language
that isn't exactly C, but "C with decorations." In C as
defined by ISO, :> is either a syntax error (older versions)
or equivalent to ] (newer versions), but in neither case does
the macro make C-sense.

Probably, your C-like compiler has its origins in the time
before :> entered the official language, and co-opted :> for
its own purposes -- it seemed safe enough, no doubt, since :>
could not occur in a legal C program of the time, so giving it
a special meaning wouldn't alter the treatment of legal C.
Unfortunately, other people coveted :> too, and they wrote the
next version of the Standard ...

All I can suggest is that you search the documentation for
your compiler to see what meaning it attaches to :> and to find
out what rules are being broken. Maybe there's a section on
"Language Extensions" or "Nifty Features" or something. But
unfortunately, :> as used in the macro isn't really C at all,
and only someone familiar with the "decorated C" compiler will
be able to you.

--
Eric.Sosman@sun.com

On Jan 30, 10:56 pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <76dce5be-9069-4de6-b9e0-6e66bcffb...@k39g2000hsf.googlegroups.com>,
>
> <email7373...@kinglibrary.net> 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.

Some googling around with the terms that the OP posted ("pharlap",
"watcom") pulls up the OpenWatcom project. Their documentation on the
Watcom C/C++ compiler (and their recreation of it) indicates that the
Watcom compiler allowed for a :> operator as an extension to the C
language

The documentation says:
7.3.3.3 Void Based Pointers
A void based pointer must be explicitly combined with a segment value
to produce a reference
to a memory location. A void based pointer does not infer its segment
value from another
object. The :> (base) operator is used to combine a segment value and
a void based pointer.
For example, on an IBM PC or PS/2 computer, running DOS, with a color
monitor, the screen
memory begins at segment 0xB800, offset 0. In a video text mode, to
examine the first
character currently displayed on the screen, the following code could
be used:

extern void main()
{
segmentscreen;
charbased(void)*scrptr; screen = 0xB800;
scrptr = 0;
printf( "Top left character is '%c'.\n",
*(screen:>scrptr) );
}

The general form of the :> operator is:
segment :> offset
where segment is an expression of typesegment, and offset is an
expression of type
based(void)*.


[snip]