const declaration

[freemind001]

I do not argue with you, I have understood that it is impossible after very few first posts, so I have just hardcoded the constants needed

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

1. const
2.   UI_SET_EVBIT = $40045564;
3.   UI_SET_KEYBIT = $40045565;
4.   UI_DEV_CREATE = $00005501;
5.   UI_DEV_DESTROY = $00005502;
6.   UI_DEV_SETUP = $405C5503;

But.
When one says "it is very simple" and "for real programmer", it sounds like a challenge.
I just want him to show the muscles.

[MarkMLl]

I do not argue with you, I have understood that it is impossible after very few first posts, so I have just hardcoded the constants needed

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

1. const
2.   UI_SET_EVBIT = $40045564;
3.   UI_SET_KEYBIT = $40045565;
4.   UI_DEV_CREATE = $00005501;
5.   UI_DEV_DESTROY = $00005502;
6.   UI_DEV_SETUP = $405C5503;

But.
When one says "it is very simple" and "for real programmer", it sounds like a challenge.
I just want him to show the muscles.

That's certainly one way of doing it, but you're at risk of getting screwed by changes in word size etc.: I speak from experience.

Look, I agree that Pascal's got a deficiency here. However in the case of FPC it's something that's baked in at a fairly low level: use the forum search facility to find previous discussion of parameterised macros and you'll find an explanation of e.g. why it's not really realistic for the compiler- as implemented- to call an external macro processor (there have been some written for Pascal, but they're pretty weird).

However the bottom line is that if you want to work at that level, the only really robust way to do it is to work in C: and not just any old C, but the same C that's being used to build the kernel. Saying that risks making me unpopular with certain other members of the community but it's a fact, and it's why so many low-level libraries are provided as an integral part of a Linux distro rather than being built on an ad-hoc basis.

Rust, IMO and provided that I understand things correctly, gets it more or less right: provide one kind of macro for text substitution (which is what C tries to do), and another for parameterised substitution where the type of each parameter must be defined in terms of the implementation of the language (i.e. a parameter can be a block of code, but it has to be a consistent and balanced block of code).

MarkMLl

[Thaddy]

Pointless and clueless.
Anyway defining the consts is a good approach.

Next time check your code, though. We will find out if you have actually tested it.

[freemind001]

You may want to check it yourself, to find out that the previous code is at least compilable

[BrunoK]

I do not argue with you, I have understood that it is impossible after very few first posts, so I have just hardcoded the constants needed
...
But.
When one says "it is very simple" and "for real programmer", it sounds like a challenge.
I just want him to show the muscles.

I'm not a specialist about this stuff, but you would be well inspired to examine the code in 

that shows how the desired values can be programmatically build.
The proposed functions can be inlined and nothing prevents you to build ONCE a var / const list of the values of interest at the start of your program.

Then, study / extract lines of interest from  the link mentionned in

Perhaps this might help.
https://github.com/LongDirtyAnimAlf/FPC-USB-HID/blob/a40a39cb854a1dbaebb04f2139bbb2a73438d49b/usblibs/linux/usbcontroller.pas#L229

specificcally unit usbcontroller.pas for the way of defining constants. That unit has its approach with TObject descendants that might be interesting, but if you want to do things in a classical procedural way pick the bits that are useful to you.

Good luck.

[MarkMLl]

specificcally unit usbcontroller.pas for the way of defining constants. That unit has its approach with TObject descendants that might be interesting, but if you want to do things in a classical procedural way pick the bits that are useful to you.

Although if I'm reading things correctly investigating the Linux input API (libevdev etc.) might be more useful.

MarkMLl

[BrunoK]

Although if I'm reading things correctly investigating the Linux input API (libevdev etc.) might be more useful.

MarkMLl

Sure, but if I read the initial post, the objective is how to make things work with FPC and OP'freemind001 seems to be starting with FPC. OP apparently has knowledge of C and Linux but is not fluent in FPC so proposing some kind of bridge learning with similarly named things is an encouragement for progression.

[PascalDragon]

purity does not directly imply static evaluation it's more like a contract. Then based on that contract it makes sense to statically evaluate calls to pure functions.

It does in the context of the proposed feature. Because some kind of keyword is required to denote a function that can be evaluated at compile time.

IOCTL macros are pure preprocessor stuff.  Not possible to convert.

Huh? These macros can be easily implemented using inline functions and the compiler will completely collapse them. I've done that already in the past.

[LV]

Can you please provide a snippet of code that implements

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

1. #define UI_DEV_CREATE           _IO(UINPUT_IOCTL_BASE, 1)

in pascal?

Why weren't you satisfied with reply #32? 

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

1. const
2.   UINPUT_IOCTL_BASE = Ord('U'); // Equivalent to #define UINPUT_IOCTL_BASE 'U'
3.   UI_DEV_CREATE = (UINPUT_IOCTL_BASE shl 8) or 1; // Equivalent to _IO(UINPUT_IOCTL_BASE, 1)
4.  

[MarkMLl]

Huh? These macros can be easily implemented using inline functions and the compiler will completely collapse them. I've done that already in the past.

If it obeys the inline directive.

MarkMLl

[PascalDragon]

Huh? These macros can be easily implemented using inline functions and the compiler will completely collapse them. I've done that already in the past.

If it obeys the inline directive.

The IOCTL macros are easy enough for that.

[marcov]

However the bottom line is that if you want to work at that level, the only really robust way to do it is to work in C: and not just any old C, but the same C that's being used to build the kernel. Saying that risks making me unpopular with certain other members of the community but it's a fact, and it's why so many low-level libraries are provided as an integral part of a Linux distro rather than being built on an ad-hoc basis.

The problem is not Pascal, the problem is Unix/Linux API being defined in essentially everything-goes-C. Even if you have macro functionality in a 3rd party language, you can still not interpret system provided C headers, it only makes conversion marginally easier, but doesn't auto adopt.

Therefore I think a autoconf like solution, automating querying and dumping the C compiler/libc combination would make more sense than trying to mimic C language/preprocessor capabilities. This basically is already how it is done, but on a more ad-hoc case to case basis.

But that is _IF_ you agree that something must be done in the first place, which is a very big IF.