How to translate typedef void * to Pascal?

[Warfley]

You mean void, not void*. The * in the example is simply the notation for function pointer. A function pointer to a function returning a void* would be void* *func().

No, because of the bracketing it is referring to void* ... not to void (*...
To quote the C 2011 standard (page 134): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

EXAMPLE 1 The declaration
int f(void), *fip(), (*pfi)();
[...]
The binding  of *fip() is *(fip()), so that  the declaration  suggests,  and  the  same  construction  in  an  expression  requires,  the  calling  of  a  function fip, [...].  In  the  declarator (*pfi)(),  the extra parentheses are necessary to indicate that indirection through a pointer to a function yields a function designator [...]

[tetrastes]

These are not function pointers, but function declarations. You have a function pointer if you either have a typedef

You are wrong. See post of Warfley. If you need function pointer, you need explicitly use brackets, with or without typedef.

Your function declaration from earlier is essentially parsed like this:

Code: C  [Select][+][-]

1. char* strcpy(...);

A function pointer to a strcpy compatible function would look like this:

Code: C  [Select][+][-]

1. typedef char* (*StrCpyFunc)(...);

Yes, but typedef does not make from

Code: C  [Select][+][-]

1. char* func(...);

neither

Code: C  [Select][+][-]

1. char* (*func)(...);

nor

Code: C  [Select][+][-]

1. char (*func)(...);

as you write in yor previous post.

I mean that the code without pointer

Code: C  [Select][+][-]

1. typedef void my_annoying_c_function(size_t sz);
2.  
3. my_annoying_c_function func;

is absolutely legal.

Yes, but you can't do anything with it:

Yes, of cause,it is only another way to declare

Code: C  [Select][+][-]

1. void func(size_t sz);
2.  

And now change your code as you believe it will work:

Code: C  [Select][+][-]

1. int somefunc()
2. {
3.    return 42;
4. }
5.  
6. typedef int *IntFunc();   //  ADD * HERE
7.  
8. int main()
9. {
10.    IntFunc func1 = somefunc;
11.    IntFunc func2 = &somefunc;
12.    IntFunc func;
13.    
14.    func = somefunc;
15.    func = &somefunc;
16.  
17.    return func();
18. }

Code: Bash  [Select][+][-]

1. $ gcc test.c
2. test.c: In function 'main':
3. test.c:10:4: error: function 'func1' is initialized like a variable
4.    10 |    IntFunc func1 = somefunc;
5.       |    ^~~~~~~
6. test.c:11:4: error: function 'func2' is initialized like a variable
7.    11 |    IntFunc func2 = &somefunc;
8.       |    ^~~~~~~
9. test.c:14:9: error: lvalue required as left operand of assignment
10.    14 |    func = somefunc;
11.       |         ^
12. test.c:15:9: error: lvalue required as left operand of assignment
13.    15 |    func = &somefunc;
14.       |         ^
15. test.c:17:11: warning: returning 'int *' from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion]
16.    17 |    return func();
17.       |           ^~~~~~
18.  
19.  

[jiaxing2]

C sucks. I hate C 

[jamie]

na, C is just fine... I have no issues with it...

Your problem is you are getting confused from all this advice you are getting that is just talking you in all four directions..

 How to tell who's advice and who's theories you want to believe!

 

[Warfley]

Well function pointers in C are simply pretty bad. I mean the best indicator how bad they are is that C++ introduced a new type (std::function) so you never have to use that awful C-syntax anymore.

There are only a few things where C++ decided to "replace" C features (of course C is still a subset of C++, but there are things you should not be using in C++ that are just there for C compatibility) like NULL-pointer, C-Strings or function pointers. Because C screwed that up really hard.

I mean simply the fact that there is so much confusion about such an essential language feature as function pointers shows that they are not simple

[PascalDragon]

These are not function pointers, but function declarations. You have a function pointer if you either have a typedef

You are wrong. See post of Warfley. If you need function pointer, you need explicitly use brackets, with or without typedef.

Whatever.

The point I was trying to make is that the following does not have a direct representation in Pascal and isn't really useable without a pointer to it in C either:

Code: C  [Select][+][-]

1. typedef int SomeFunc();

So in Pascal always a function or procedure variable needs to be used for this.

[tetrastes]

The point I was trying to make is that the following does not have a direct representation in Pascal and isn't really useable without a pointer to it in C either:

Code: C  [Select][+][-]

1. typedef int SomeFunc();

So in Pascal always a function or procedure variable needs to be used for this.

So the code from the first question

Code: C  [Select][+][-]

1. typedef void *my_annoying_c_function(size_t sz);

also does not have a direct representation in Pascal.

[PascalDragon]

The point I was trying to make is that the following does not have a direct representation in Pascal and isn't really useable without a pointer to it in C either:

Code: C  [Select][+][-]

1. typedef int SomeFunc();

So in Pascal always a function or procedure variable needs to be used for this.

So the code from the first question

Code: C  [Select][+][-]

1. typedef void *my_annoying_c_function(size_t sz);

also does not have a direct representation in Pascal.

Yes, you're right. But as long as it is used as my_annoying_c_function *somevar translating it as a function pointer is legitimate.

[BrunoK]

Would that be relevant for typing and use ?

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. type
4.   // typedef void my_annoying_c_function(size_t sz)
5.   TMy_annoying_c_function = function(sz: size_t): {void} intptr;
6.  
7. function my_annoying_c_func(sz: size_t): intptr;
8. begin
9.   Result := sz;
10. end;
11.  
12. const
13.   my_annoying_c_function: TMy_annoying_c_function = @my_annoying_c_func;
14.  
15. begin
16.   writeln(my_annoying_c_func(5));
17.   readln;
18. end.
19.  

Edit :
Replace 

Code: [Select]

  writeln(my_annoying_c_func(5));with

Code: [Select]

  writeln(my_annoying_c_function(5));

[tetrastes]

Code: C  [Select][+][-]

1. #include <stdio.h>
2.  
3. typedef long long (*Tmy_annoying_c_function)(size_t sz);
4.  
5. long long my_annoying_c_func(size_t sz)
6. {
7.   return sz;
8. }
9.  
10. const
11.   Tmy_annoying_c_function my_annoying_c_function = my_annoying_c_func;
12.  
13. void main(void)
14. {
15.   printf("%d\n", my_annoying_c_function(5));
16.   scanf("%*c");
17. }
18.  

[Warfley]

[...]

Except "long long int" is not IntPtr, the corresponding c type would be intptr_t from stdint.h and printf does not replace WriteLn, which can be seen quite good here because your format string is broken (%d prints an int, to print long long int you need to use lld or lli. when you would be using intptr_t you would need to distinguish between 32 and 64 bit and use ld and lld respectively), which is not possible with WriteLn because there the compiler takes care of such things.

Not all Pascal programs have a perfect C representation, as pretty well seen by your example. The other direction is much better (i.e. C to pascal) because nearly all C constructs have a representation in pascal and you can use the libc in pascal (while you can't use the RTL in C).

That said, these are two different languages and not everything has a 1-1 translation and some problems are simply to be expected when trying to convert from one language to the other. But your chances are better when trying to convert C to Pascal than the other way around

[tetrastes]

On my system IntPtr and intptr_t are long long , though in general you are right. But in more general you are not right:
To quote the C 2011 standard (page 291) from your link: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

7.20.1.4 Integer types capable of holding object pointers
1 The following type designates a signed integer type with the property that any valid
pointer to void can be converted to this type, then converted back to pointer to void,
and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type with the property that any valid
pointer to void can be converted to this type, then converted back to pointer to void,
and the result will compare equal to the original pointer:
uintptr_t
These types are optional.

Note the last line. So you may not only not find intptr_t in stdint.h (for example at gcc it is defined in crtdefs.h), but not find it at all.

As for printf, you are right again in general, but in this specific example printf prints "5" and nothing else, and %d do it quite well, so you need not %lld here.

And of cause I agree that "Not all Pascal programs have a perfect C representation" and with all other clever words.