LIBC vs. IPC constants

[Snify]

Many of you may know know by now, that I am trying to port a huge project from Kylix to Freepascal.
I came across some differences, which is not quite clear to me.
For example, (some) constant values in the libc unit are different from the ipc unit.

In the file bshmh.inc (from the libc unit), there are shared memory constants like SHM_R, SHM_W, etc.
These values differ from the libc unit.

Is this an intentionally approach?
Does this mean, that I need the libc and the ipc unit together, in order to gain good compatibility?

Why are the values different? Which one do I really need if the project has been compiled with Kylix before?

Kylix (libc):

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

1. const
2. { Permission flag for shmget.  }
3.   SHM_R         = $100;           { or S_IRUGO from <linux/stat.h> }
4.   {$EXTERNALSYM SHM_R}
5.   SHM_W         = $80;            { or S_IWUGO from <linux/stat.h> }
6.   {$EXTERNALSYM SHM_W}
7.  

FPC (libc/bshmh.inc):

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

1. const
2.    SHM_R = 0400;
3.    SHM_W = 0200;      
4.  

FPC (ipc):

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

1.      SHM_R      = 4 shl 6;
2.      SHM_W      = 2 shl 6;    
3.  

Thank you for your answers

Edit: I use "shmget" with these constants

[PascalDragon]

Does this mean, that I need the libc and the ipc unit together, in order to gain good compatibility?

In general: best don't use the libc unit at all, because it's i386-linux only.

Why are the values different? Which one do I really need if the project has been compiled with Kylix before?

They aren't that different if you know how to interpret them.

FPC (libc/bshmh.inc):

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

1. const
2.    SHM_R = 0400;
3.    SHM_W = 0200;      
4.  

These look like a bug. I think someone simply copied the octal notation from some C header and forgot that in FPC octal values start with & instead of 0, cause &400 in octal is $100 in hex and &200 in octal is $80 in hex. So they would be the correct values if someone hadn't messed up...

FPC (ipc):

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

1.      SHM_R      = 4 shl 6;
2.      SHM_W      = 2 shl 6;    
3.  

It's kinda a strange notation, but if you look at the bit patterns it makes sense:

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

1.   SHM_R = %100 shl 6; // = %1 0000 0000 = $100
2.   SHM_W = %010 shl 6; // = %0 1000 0000 = $80
3.  

[Snify]

Does this mean, that I need the libc and the ipc unit together, in order to gain good compatibility?

In general: best don't use the libc unit at all, because it's i386-linux only.

Why are the values different? Which one do I really need if the project has been compiled with Kylix before?

They aren't that different if you know how to interpret them.

FPC (libc/bshmh.inc):

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

1. const
2.    SHM_R = 0400;
3.    SHM_W = 0200;      
4.  

These look like a bug. I think someone simply copied the octal notation from some C header and forgot that in FPC octal values start with & instead of 0, cause &400 in octal is $100 in hex and &200 in octal is $80 in hex. So they would be the correct values if someone hadn't messed up...

FPC (ipc):

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

1.      SHM_R      = 4 shl 6;
2.      SHM_W      = 2 shl 6;    
3.  

It's kinda a strange notation, but if you look at the bit patterns it makes sense:

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

1.   SHM_R = %100 shl 6; // = %1 0000 0000 = $100
2.   SHM_W = %010 shl 6; // = %0 1000 0000 = $80
3.  

Thank you very much for your answer! This is great news to hear!
Not sure on how to implement this properly now, without copying/editing the og libc unit, etc.

I just wasn't sure if values had changed or something.

I sadly need to use the libc unit for now.
Once everything works and is set up, I can finally start working to get rid of libc.

[PascalDragon]

FPC (libc/bshmh.inc):

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

1. const
2.    SHM_R = 0400;
3.    SHM_W = 0200;      
4.  

These look like a bug. I think someone simply copied the octal notation from some C header and forgot that in FPC octal values start with & instead of 0, cause &400 in octal is $100 in hex and &200 in octal is $80 in hex. So they would be the correct values if someone hadn't messed up...

Fixed in b876a02d. Maybe we'll merge that to 3.2.3 as well so that 3.2.4 will have that corrected...

[Snify]

FPC (libc/bshmh.inc):

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

1. const
2.    SHM_R = 0400;
3.    SHM_W = 0200;      
4.  

These look like a bug. I think someone simply copied the octal notation from some C header and forgot that in FPC octal values start with & instead of 0, cause &400 in octal is $100 in hex and &200 in octal is $80 in hex. So they would be the correct values if someone hadn't messed up...

Fixed in b876a02d. Maybe we'll merge that to 3.2.3 as well so that 3.2.4 will have that corrected...

Thank you very much for this!
I hope, that other constants are not affected as well.

[PascalDragon]

I hope, that other constants are not affected as well.

No guarantee for unit libc. Those in the other units should be okay, cause they're actively used as they're cross platform units (for the *nix based platforms).

[Snify]

I hope, that other constants are not affected as well.

No guarantee for unit libc. Those in the other units should be okay, cause they're actively used as they're cross platform units (for the *nix based platforms).

Alright thank you.
In case of doubt, I will look into Kylix's libc unit (at least for the constants).
If I stumble across another thing like that, I will let you know