Ruby/dl question

Ruby
1

if one has:

struct flock {
…
short l_type; /* Type of lock: F_RDLCK,
F_WRLCK, F_UNLCK /
short l_whence; / How to interpret l_start:
SEEK_SET, SEEK_CUR, SEEK_END /
off_t l_start; / Starting offset for lock /
off_t l_len; / Number of bytes to lock /
pid_t l_pid; / PID of process blocking our lock
(F_GETLK only) */
…
};

can this structure be desribed using ruby/dl? i’m worried that the
struct
method assumes the fields are in order which, in the case of the flock
structure, they may not be.

regards.

-a

2

[email protected] wrote:

 off_t l_start;   /* Starting offset for lock */
 off_t l_len;     /* Number of bytes to lock */
 pid_t l_pid;     /* PID of process blocking our lock
                     (F_GETLK only) */
 ...

};

can this structure be desribed using ruby/dl? i’m worried that the struct
method assumes the fields are in order which, in the case of the flock
structure, they may not be.

I don’t understand. If the flock struct fields are not in a predictable
order, how do you access them in C?

3

On Sun, 12 Feb 2006, Joel VanderWerf wrote:

                     SEEK_SET, SEEK_CUR, SEEK_END */

I don’t understand. If the flock struct fields are not in a predictable
order, how do you access them in C?

that’s what to compiler does - it’s why one must say

sizeof(mystruct)

vs.

sizeof(int) + sizeof(float)

assuming

struct mystruct { int i; float f; };

i recently learned of the offsetof macro which tells you this info.

regards.

-a

4

[email protected] wrote:

On Sun, 12 Feb 2006, Joel VanderWerf wrote:
…

I don’t understand. If the flock struct fields are not in a predictable
order, how do you access them in C?

that’s what to compiler does - it’s why one must say

sizeof(mystruct)

vs.

sizeof(int) + sizeof(float)

Ah I see. It isn’t that the data structure itself is unpredictable (I
thought maybe you had to read one of the fields to know how the others
are laid out). It’s rather that you don’t know what the compiler is
doing with it.

Since there are a variety of alignment and packing options in any
compiler, I don’t see how DL could guess what the correct ones are.
Maybe it assumes longword alignment?

On further digging… in dl.h the extra space taken to align a short,
for example, is computed by…

typedef struct { char c; short x; } s_short;
#define ALIGN_SHORT (sizeof(s_short) - sizeof(short))
#define SHORT_ALIGN ALIGN_SHORT

…and this is used by the following macro, which advances the offset
var to the next aligned position…

#define DLALIGN(ptr,offset,align) {
while( (((unsigned long)((char *)ptr + offset)) % align) != 0 )
offset++;
}

…to calculate the struct size in dlsizeof() in dl.c:

case 'H':
  DLALIGN(0,size,SHORT_ALIGN);
case 'h':
  size += sizeof(short) * n;
  break;

So I guess if you use ‘H’, you get aligned shorts (according to whatever
compiler flags ruby and its extensions were compiled with), and if you
use ‘h’ you get packed shorts.

Don’t get your shorts out of alignment! :wink:

5

Joel VanderWerf wrote:

doing with it.
#define SHORT_ALIGN ALIGN_SHORT
case ‘H’:
Don’t get your shorts out of alignment! :wink:
And, for what it’s worth, both gcc 3.4.4 and VC++ 13.10 pack the two
shorts together
into the same word on x86.

6

On Sun, 12 Feb 2006, Joel VanderWerf wrote:

Don’t get your shorts out of alignment! :wink:

lol!

-a

7

On Feb 10, 2006, at 7:30 PM, [email protected] wrote:

 pid_t l_pid;     /* PID of process blocking our lock
                     (F_GETLK only) */
 ...

};

can this structure be desribed using ruby/dl? i’m worried that the
struct
method assumes the fields are in order which, in the case of the flock
structure, they may not be.

You have a bigger problem, off_t is usually 8 bytes and the built-in
dl can only handle 4 byte types. (Or, if it can handle 8 byte types,
I couldn’t figure out how.)

–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

8

On Sun, 12 Feb 2006, Eric H. wrote:

 off_t l_start;   /* Starting offset for lock */

You have a bigger problem, off_t is usually 8 bytes and the built-in dl can
only handle 4 byte types. (Or, if it can handle 8 byte types, I couldn’t
figure out how.)

i can pack my own struct easily enough… but knowing the layout is
impossible.

right now i’m considering a ‘configure’ setup to my install that
requires the
compiler to determine the layout of the flock struct and generate ruby
code to
describe it. that way, if your arch is standard you can use the dl
binding
with requiring a compiler and you only need one to determine struct
layout if
it’s not.

might be too much work though… an extension is what i’ve already done
anyhow (posixlock) but i’d just like to hook into the existing IO::fcntl
call
with the ability to apply posixlocking.

regards.

-a

9

Eric H. wrote:

 off_t l_start;   /* Starting offset for lock */

You have a bigger problem, off_t is usually 8 bytes and the built-in dl
can only handle 4 byte types. (Or, if it can handle 8 byte types, I
couldn’t figure out how.)

good pickup.
I would expect the higher-order word to be 0 in 99% of cases.
You could treat an 8-byte off_t field as two separate unsigned longs and
extract the two longs separately and then add them together
if the higher-order word is indeed anything but 0.