Strange C operator

Discussion in 'C Programming' started by email7373388@kinglibrary.net, Jan 30, 2008.

  1. Guest

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

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

    Any clue?
    , Jan 30, 2008
    #1
    1. Advertising

  2. In article <>,
    <> 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
    Walter Roberson, Jan 30, 2008
    #2
    1. Advertising

  3. Eric Sosman Guest

    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, Jan 30, 2008
    #3
  4. In article <1201727105.616296@news1nwk>,
    Eric Sosman <> wrote:
    > 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, Jan 30, 2008
    #4
  5. Eric Sosman Guest

    Richard Tobin wrote:
    > In article <1201727105.616296@news1nwk>,
    > Eric Sosman <> wrote:
    >> 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, Jan 30, 2008
    #5
  6. In article <1201735819.744335@news1nwk>,
    Eric Sosman <> 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
    Richard Tobin, Jan 30, 2008
    #6
  7. Eric Sosman <> writes:
    > Richard Tobin wrote:
    >> In article <1201727105.616296@news1nwk>,
    >> Eric Sosman <> wrote:
    >>> 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) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 31, 2008
    #7
  8. Guest

    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 )))
    , Jan 31, 2008
    #8
  9. In article <>,
    <> 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'.
    Walter Roberson, Jan 31, 2008
    #9
  10. Guest

    > 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.
    , Jan 31, 2008
    #10
  11. Guest

    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.
    , Jan 31, 2008
    #11
  12. In article <>,
    <> 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
    Richard Tobin, Jan 31, 2008
    #12
  13. Eric Sosman Guest

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

    --
    Eric Sosman, Jan 31, 2008
    #13
  14. Lew Pitcher Guest

    On Jan 30, 10:56 pm, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    >
    > <> 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]
    Lew Pitcher, Jan 31, 2008
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dmitriy Iassenev

    to guru : strange C++ operator behaviour

    Dmitriy Iassenev, Oct 2, 2003, in forum: C++
    Replies:
    35
    Views:
    830
  2. Harvey Twyman
    Replies:
    8
    Views:
    552
    August Derleth
    Oct 25, 2003
  3. paulo

    Strange operands to conditional operator

    paulo, Nov 14, 2006, in forum: C Programming
    Replies:
    5
    Views:
    307
    Keith Thompson
    Nov 14, 2006
  4. vj
    Replies:
    11
    Views:
    557
  5. Henryk
    Replies:
    11
    Views:
    531
    Marcelo Pinto
    Feb 8, 2006
Loading...

Share This Page