need this C translated to pascal-family - please.

[Ian Collins]

Below is my attempted translation of a C-source to Pascal/Oberon.
My added lines start with "!".
Please add your contributions. Pseudo-code is OK too.

How much are you paying?

<1400 odd lines snipped>

 

[Nick Keighley]

Below is my attempted translation of a C-source to Pascal/Oberon.

I see no attempt to translate the code into Pascal

I don't think there's any way to avoid learning C. This is a fairly
tangled and platform specific bit of C and to express it in Pascal
you're going to have to understand what it does. And to understand
what it does you're going to have to learn C.

My added lines start with "!".
Please add your contributions. Pseudo-code is OK too.
I'll clean-up and integrate all contributions.

/*
  Mode switching tool for controlling flip flop (multiple device) USB gear
  Version 1.1.4, 2010/08/17

  Copyright (C) 2007, 2008, 2009, 2010 Josua Dietze
 http://www.gnu.org/licenses/gpl.txt*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <signal.h>
#include <ctype.h>
#include <getopt.h>
#include <syslog.h>

#include <usb.h>
#include "usb_modeswitch.h"

I suspect you need to look inside these headers for some of the types
etc.

struct usb_dev_handle *devh;
! is '*dev' a pointer to a RECORD called usb_device ?? <------

devh is a pointer to a struct usb_dev_handle. A struct is analogous to
a Pascal record.

/* Settable Interface and Configuration (for debugging mostly) (jmw) */
int Interface = 0, Configuration = -1, AltSetting = -1;

static struct option long_options[] = {
        {"help",                              no_argument, 0, 'h'},
        {"version",                           no_argument, 0, 'e'},

        {0, 0, 0, 0}};

! is this a RECORD containing an ARRAY OF <strings>?

it's an array of structs. Each struct seems to have a string (char*)
member, maybe two into and a char. If you want to know more about the
struct find the definition.

void readConfigFile(const char *configFilename)
{
        if (verbose) printf("Reading config file: %s\n", configFilename);
        ParseParamHex(configFilename, TargetVendor);
        ParseParamHex(configFilename, TargetProduct);

! all the above PROC calls, initialies their 2nd arg, which is a global-var.
! configFilename is variably:
! but `readConfigFile` is only called from one place:
!   readConfigFile(optarg)
! with ONE arg  -- which doesn't match its declaration: of 2 args ?  

sorry? where is it declared with two arguments?

        /* TargetProductList has priority over TargetProduct */
        if (strlen(TargetProductList))
        {
                TargetProduct = 0;
                SHOW_PROGRESS("Warning: TargetProductList overrides TargetProduct!\n");
        }

        config_read = 1;}

! end of PROC readConfigFile

boredom sets in

<snip>

 

[BartC]

Below is my attempted translation of a C-source to Pascal/Oberon.
My added lines start with "!".
Please add your contributions. Pseudo-code is OK too.
I'll clean-up and integrate all contributions.

Copyright (C) 2007, 2008, 2009, 2010 Josua Dietze
http://www.gnu.org/licenses/gpl.txt */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <signal.h>
#include <ctype.h>
#include <getopt.h>
#include <syslog.h>

#include <usb.h>
#include "usb_modeswitch.h"
! various IMPORTs

Do you intend also to translate the code of these usb modules? Or do you
expect these C modules to link statically with the Pascal code? If that is
possible, you might need to define an interface to the C module, in the
Pascal code.

Sort out these possibilities first before worrying about translating the
rest of the code. If linking Pascal to C is feasible, then you may need not
need to translate at all... Just modify this module so that it can be linked
in the same way to a small Pascal program that just calls an entry point in
the C.

#define SEARCH_DEFAULT 0
#define SEARCH_TARGET 1
! various CONSTs <------

Yes, these are all the easy bits. The code here can be translated
mechanically. It's all the code that isn't here that is the problem.

 

[no.top.post]

How much are you paying?

If you've got nothing to contribute to the colaborators' forum,
then take your begging bowl and go out on the street.
The original coder made GPL contribution.
And I hope to have added some value.
Here's some more:-
Q. why has *nix got `p2c` but no `c2p` ?
A. apparently because PASCAL is designed & minimalist whereas C
is an evolved mess; and you can map from P to a reduced C, but
not [so easily] from all the multiple possibilities of a C construct
to the canonical P equivalent ?

But since syntax-coulour editors for C exist, that's half the job.
Mnay worthwhile tasks can be achieved by heuristic methods:
ie. with some human input, combined with the computer's
contribution.

 

[luserXtrog]

How much are you paying?

If you've got nothing to contribute to the colaborators' forum,
then take your begging bowl and go out on the street.
The original coder made GPL contribution.
And I hope to have added some value.
Here's some more:-
Q. why has *nix got `p2c` but no `c2p` ?
A. apparently because PASCAL is designed & minimalist whereas C
is an evolved mess; and you can map from P to a reduced C, but
not [so easily] from all the multiple possibilities of a C construct
to the canonical P equivalent ?

But since syntax-coulour editors for C exist, that's half the job.
Mnay worthwhile tasks can be achieved by heuristic methods:
ie. with some human input, combined with the computer's
contribution.

A search for "why pascal is not my favorite programming language"
might elucidate some of the differences and why c2p in general
isn't really possible. It might be possible for any given specific
case; but there are things in c that weren't dreamt of in pascal's
philosophy. I think function pointer is one.

 

[Ian Collins]

If you've got nothing to contribute to the colaborators' forum,
then take your begging bowl and go out on the street.

Which collaborators forum would that be? This is Usenet.

The original coder made GPL contribution.
And I hope to have added some value.
Here's some more:-
Q. why has *nix got `p2c` but no `c2p` ?

C has constructs Pascal lacks.

 

[Seebs]

If you've got nothing to contribute to the colaborators' forum,
then take your begging bowl and go out on the street.

This is not a forum for other people do do your work for you; it's for
*discussion*. If you want people to collaborate with you on code changes,
this is the wrong forum.

And I hope to have added some value.

No offense to our Pascal friends, but I really don't think that converting
this code to Pascal will add value. You haven't exactly given us any reason
for which you think you need to do this.

Here's some more:-
Q. why has *nix got `p2c` but no `c2p` ?
A. apparently because PASCAL is designed & minimalist whereas C
is an evolved mess; and you can map from P to a reduced C, but
not [so easily] from all the multiple possibilities of a C construct
to the canonical P equivalent ?

Exactly. There are huge numbers of C programs for which there is no
Pascal equivalent, at least at the level of "code which goes through the
same process". You could write a new program which took the same inputs
and the same outputs, but it would likely be unrecognizably different
for most non-trivial programs.

But since syntax-coulour editors for C exist, that's half the job.

No, no it isn't. It's not even one percent of the job.

Mnay worthwhile tasks can be achieved by heuristic methods:
ie. with some human input, combined with the computer's
contribution.

But not translating stuff from one language to another where one of the
languages has capabilities that the other intentionally omits.

-s

 

[Marco van de Voort]

Q. why has *nix got `p2c` but no `c2p` ?
A. apparently because PASCAL is designed & minimalist whereas C
is an evolved mess; and you can map from P to a reduced C, but
not [so easily] from all the multiple possibilities of a C construct
to the canonical P equivalent ?

Actually you can, but the trouble is the result is useless, since before
C2P, first the preprocessor must be run to produce actual C code.

Then the preprocessed C code can be fairly easily get mapped to Pascal.

But that result is useless for what most people want to do with the resulting
C code, and it only works for complete programs, not headers.

So the main problem is due to the heavy preprocessor use of C, which allows
to define stuff incompletely.

In theory, a #define in header can be used in two totally different context,
giving the earlier #define two possible sane translations (without
preprocessor)

 

[Marco van de Voort]

C has constructs Pascal lacks.

And vice versa.

 

[winston19842005]

I've done a little bit of such conversion. Easy enough for simple C...
but it became increasingly difficult.

I finally reached a point that when I tried to convert a mildly
interesting C program to Pascal, that my nuts fell off...

 

[Pascal J. Bourguignon]

I've done a little bit of such conversion. Easy enough for simple C...
but it became increasingly difficult.

I finally reached a point that when I tried to convert a mildly
interesting C program to Pascal, that my nuts fell off...

If you are doing a mechanical translation, where you want the exact C
program to be run (thru a Pascal compiler), then you will have to
emulate the C virtual machine. For example, to convert this:

char* f(int i){
static char data="Hello World"; // is a array of 12 bytes
if((0<i) || (sizeof(data)<i)){ // Notice <, not <=.
return(0);
}else{
return(data+i);
}
}

you have to simulate C pointers and C memory, you cannot just map them
to Pascal pointers, which have different properties, and abilities.


On the other hand, you could convert the program from a higher level
point of view, where you try to understand "what" is done by the
program (not "how" it's done), and re-implement it in the target
language.

When you go from a low level programming language (assembler, C) to a
higher level programming language, it's better to use this higher
level approach.

 

[Chris Burrows]

On the other hand, you could convert the program from a higher level
point of view, where you try to understand "what" is done by the
program (not "how" it's done), and re-implement it in the target
language.

When you go from a low level programming language (assembler, C) to a
higher level programming language, it's better to use this higher
level approach.

+1. To me that is the only sensible way of doing it. Otherwise it's like
trying to convert a scrambled egg into an omelette ;-)

Chris Burrows
CFB Software
Astrobe v3.2: ARM Oberon-07 Development System
http://www.astrobe.com

 

[no.top.post]

you have to simulate C pointers and C memory, you cannot just map them
to Pascal pointers, which have different properties, and abilities.

On the other hand, you could convert the program from a higher level
point of view, where you try to understand "what" is done by the
program (not "how" it's done), and re-implement it in the target
language.

When you go from a low level programming language (assembler, C)
to a higher level programming language, it's better to use this higher
level approach.

Yes, that's what I meant by using 'heuristic means': you 'pilot' the
vehicle/computer. The vehicle merely multiplies your natural
transportation capabilities. Eg. syntax colouring editors makes the
structure jump-out at you.

For this specific task, I actually want the algorithm, which I suspect
is rather simple, like:
* get the device's ID & get the corresponding driver; if any;
* otherwise try something from the heuristics-list based on the ID;
* otherwise send an evolving sequence of bytes to the device, while
monitoring it till is reracts as required.

Finding out if the C-boys could 'extract' the algorithm from my
description, plus the actual C-code, was an extra aim; which I
succeeded in doing: they can't.

Obviously I chose Pascal/P-code to represent the algorithm,
because it's the canonnical notation.

== Chris Glur.

BTW how's bablefish keeping?
I guess natural-language translators are quite useful now?
Could I collaborate with peole in China/Japan yet?
I've noticed that lots of Russian is written in latin-text.
Which is another example of operating at a higher-level,
ie. not being constrained by the noation.

 

[no.top.post]

I see no attempt to translate the code into Pascal

It's the algorithm that I want, and Pascal-like/P-code is best.

devh is a pointer to a struct usb_dev_handle.
A struct is analogous to a Pascal record.

You've paraphrased my sentence into two.

static struct option long_options[] = {
{"help", = no_argument, 0, 'h'},
{"version", =

no_argument, 0, 'e'},

{0, 0, 0, 0}};

! is this a RECORD containing an ARRAY OF <strings>?

it's an array of structs.

OK, an array of RECORDS - we must use the destination

language's notation. Ie. RECORDS, not 'structures'.
Doesn't each RECORD contain:
a string: eg "version";
?! wherewould <no_argument> be defined ?

Each struct seems to have a string (char*)
member, maybe two into and a char. If you want to know more
about the struct find the definition.

No, isn't it defined right here?

sorry? where is it declared with two arguments?

void readConfigFile(const char *configFilename)
OK, is this one arg:

boredom sets in

Well you've moved it along by adding value.

Thanks,

== Chris Glur

 

[Seebs]

Finding out if the C-boys could 'extract' the algorithm from my
description, plus the actual C-code, was an extra aim; which I
succeeded in doing: they can't.

Given the actual code, I suspect it would be possible.

"Can't" and "won't" aren't the same thing. You've come across as hostile,
dismissive, and having a sense of entitlement. There are many traits which
will induce me to spend substantial time helping someone do something.
None of those are in evidence, here.

-s

 

[Ian Collins]

Finding out if the C-boys could 'extract' the algorithm from my
description, plus the actual C-code, was an extra aim; which I
succeeded in doing: they can't.

You didn't complete you last sentence, it should have read "the can't be
bothered."!

No one is going to plough through 1400 lines of someone else's code
unless they have good reason to.

 

[BartC]

Yes, that's what I meant by using 'heuristic means': you 'pilot' the
vehicle/computer. The vehicle merely multiplies your natural
transportation capabilities. Eg. syntax colouring editors makes the
structure jump-out at you.

For this specific task, I actually want the algorithm, which I suspect
is rather simple, like:
* get the device's ID & get the corresponding driver; if any;
* otherwise try something from the heuristics-list based on the ID;
* otherwise send an evolving sequence of bytes to the device, while
monitoring it till is reracts as required.

Finding out if the C-boys could 'extract' the algorithm from my
description, plus the actual C-code, was an extra aim; which I
succeeded in doing: they can't.

Below is my attempted translation of a C-source to Pascal/Oberon.
My added lines start with "!".

However what you posted was 100% C, with a half-dozen comments added each
containing a Pascal keyword.

Calling the code an 'algorithm' is glorifying it a bit; the code is not too
demanding and looks more like a script. No-one knowing both languages would
have much of a problem translating, other than motivation... However it has
dependencies elsewhere which need to be sorted out too, assuming your aim
was to have working Pascal code which does the same job ....

Obviously I chose Pascal/P-code to represent the algorithm,
because it's the canonnical notation.

.... although it no longer sounds as though this was the case. It appears
more like you wanted a pseudo-coded, flowcharted, or English summary of what
the code was doing. So the Pascal was irrelevant.

 

[Nick Keighley]

You've paraphrased my sentence into two.

and so? Actually I corrected your statement.

static struct option long_options[] = {
        {"help",                         =      no_argument, 0, 'h'},
        {"version",                       =

    no_argument, 0, 'e'},

        {0, 0, 0, 0}};
! is this a RECORD containing an ARRAY OF <strings>?

it's an array of structs.
OK, an array of RECORDS - we must use the destination

you've buggered up the quoting. Please don't misquote me. It *isn't*
an array of records.

****

! is this a RECORD containing an ARRAY OF <strings>?

I replied:
***
it's an array of structs. Each struct seems to have a string (char*)
member, maybe two into and a char. If you want to know more about the
struct find the definition.
***

language's notation. Ie. RECORDS, not 'structures'.
Doesn't each RECORD contain:
  a string: eg "version";
  ?! wherewould <no_argument> be defined ?

no idea what you are talking about.If you want to omit the string you
could pass an empty string "" or a null pointer, NULL

  ?! if <"version"> is a string, what's <'e'> ?

'e' is a char literal.
That is typically it's a character (though it can also be regarded as
a small integer)

didn't you read this bit?

No, isn't it defined right here?

no. The struct isn't defined here. An array of structs is defined
here. This stuff shouldn't be difficult for a Pascal programmer.

void readConfigFile(const char *configFilename)
OK, is this one arg:
yes...

 <a pointer to a string> ?

nope. A pointer to a char. Because of C's loosness about pointers and
arrays. An array of strings can be passed as an argment (which then
gets converted to a pointer to the first element of the array). A
string in C is a nul (that is, zero) terminated array of chars.
Effectivly the argument is a string.

 What does the 'const' mean?

constant. The body of the function cannot modify the thing pointed to.
This can enable optimisations and generally it's a good idea to give
the compiler as much information about your intents as possible.

<snip>

 

[John Bode]

Below is my attempted translation of a C-source to Pascal/Oberon.
My added lines start with "!".
Please add your contributions. Pseudo-code is OK too.
I'll clean-up and integrate all contributions.

You're in for a world of pain, here. What is the driving need to
convert this code to Pascal or Oberon? Why is it not sufficient in
its current form?

Just blapping up 1400 lines of C code and saying "how would I convert
this to Pascal" isn't going to net much enthusiasm (*especially* when
your attempted translation consists of lines like "various imports"
and "various declarations"). You would probably get better (and more
comprehensive) help if you posted a few representative lines of code
you didn't understand and ask about them specifically.

For example, you ask

! all the above PROC calls, initialies their 2nd arg, which is a global-var.
! configFilename is variably:
! but `readConfigFile` is only called from one place:
! readConfigFile(optarg)
! with ONE arg -- which doesn't match its declaration: of 2 args ?

The declaration of readConfigFile is

void readConfigFile(const char *configFilename)

which means it takes a single argument of type `const char *` (pointer
to const char). The value of the argument is the address of the first
in a sequence of characters (terminated by a 0-valued character), and
the `const` qualifier means that the function may not modify any of
the characters in that sequence.

You might want to invest in a good C language reference and take some
time to study it if you're serious about this (not to mention figuring
out *exactly* what this code is supposed to do and how it does it).

 

[John Bode]

On Sep 19, 6:53 pm, (e-mail address removed) wrote:

[snip]

For this specific task, I actually want the algorithm, which I suspect
is rather simple, like:
* get the device's ID & get the corresponding driver; if any;
* otherwise try something from the heuristics-list based on the ID;
* otherwise send an evolving sequence of bytes to the device, while
  monitoring it till is reracts as required.

Then why didn't you ask for that in the first place instead of saying
"convert this code to Pascal"?

Finding out if the C-boys could 'extract' the algorithm from my
description, plus the actual C-code, was an extra aim; which I
succeeded in doing: they can't.

The code, while not the best in the world, is reasonably
straightforward, and a lot of the operations are fairly clear from
context. Just reading the debugging statements tells you what each
function is trying to do.

I'm not going to slog through 1000+ lines of code just to tell you
what you should be able to figure out with a couple of hours' study.