in reply to help porting a line of bitwise C code to perl

Not enough information.

Are the values token4 =  0 & token5 = 32 the values passed into func(), or the values returned by func()?

Because if those are the values coming out of func(), your C program is broken:

  1. 0 & 95 = 0. (0 & anything == 0)
  2. 32 & 32 = 32. (X & X) always == X
  3. 32 & 128 = 0.
  4. 0 | 32 | 0 = 32.

But if the values you've given are the values going into func(), then as you've only supplied a declaration (was that form ever legal C?), we cannot tell what might come out for those inputs.

Further more, the only way I can interpret that declaration of func(), is that it is expecting a pointer to an unsigned char as its input. And the likelyhood of 0 and 32 being valid pointers is minimal.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: help porting a line of bitwise C code to perl
by missingthepoint (Friar) on Sep 05, 2008 at 12:26 UTC
    was that form ever legal C?

    Yeah, it was (for certain values of 'legal'). That form of function prototype is known as 'K&R style'... There are - in the broadest possible terms - two versions of C. The first is usually called 'K&R C', from the initials of the authors of the canonical textbook (The C Programming Language). The second is called 'ANSI C' or 'ISO C', from the initials of the American and international standards bodies who, well, standardized the language.

    Anyway, when ANSI standardized the C language it got a major overhaul, which included a new form of function declaration. The old form will still compile on lots of compilers, but the new form (usually called 'ANSI style') is much better.

    email: perl -e 'print reverse map { chr( ord($_)-1 ) } split //, "\x0bufo/hojsfufqAofc";'
[reply]
      from the initials of the authors of the canonical textbook (The C Programming Language).

      Yes. My copy sits on the shelf above my computer. It has a loose front cover, is a faded yellow color, has the ISBN number 9-130110163-3 and dates from 1978.

      And on page 218/section 18.4 External definitions it give the following set of possibilities: 

      program:
    external-definition
    external-definition program

external definition:
    function-definition
    data-definition

function-definition:
    type-specifier(opt) function-declarator function-body

function-declarator
    declarator ( parameter-list(opt) )

parameter-list:
    identfier
    identifier , parameter-list

function-body:
    type-decl-list function-statement

function-statement:
    { declaration-list(opt) statement-list }

      [download]

      I don't think you you'll find a much earlier revision than my copy, indeed I can't find any sign that it is a revised edition at all, but I can't see any interpretation of the above, that means that: 

      unsigned long func (c) unsigned char *c;

      [download]

      was ever a legal function declaration.

      There are certainly no examples in the book that look like that, though there are precious few examples of function declaration. I've been doing C a long time and I've always declared function parameters inside the parens. I well remember the old DECUS compiler used to permit some extraordinary code, which why it was so favoured by the Obfuscated-C entrants, but I still do not recall seeing people use the above declaration form.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom