Recent

Author Topic: rtl/linux/ostypes.inc  (Read 2456 times)

Чебурашка

  • Hero Member
  • *****
  • Posts: 586
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
rtl/linux/ostypes.inc
« on: December 30, 2022, 10:03:56 am »
I rephrase the question:

Since we already have S_IRWXU, S_IRWXG, S_IRWXO which are compositions of the basic bits,
would it make sense adding the following constants (also other names, but with these values)?

Code: Pascal  [Select][+][-]
  1.     S_IRWU =  S_IRUSR or S_IWUSR;
  2.     S_IRWG =  S_IRGRP or S_IWGRP;
  3.     S_IRWUG_RO =  S_IRWU or S_IRWG or S_IROTH;
  4.  
  5.  
  6.     S_IRXO =  S_IROTH or S_IXOTH;
  7.     S_IRWXUG_RXO =  S_IRWXU or S_IRWXG or S_IRXO;
  8.  
  9.  

In most cases non exes are S_IRWUG_RO, and exes S_IRWXUG_RXO.
« Last Edit: December 30, 2022, 10:40:25 am by tt »
FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

Thaddy

  • Hero Member
  • *****
  • Posts: 16156
  • Censorship about opinions does not belong here.
Re: rtl/linux/ostypes.inc
« Reply #1 on: December 30, 2022, 10:25:17 am »
No.
If I smell bad code it usually is bad code and that includes my own code.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8013
Re: rtl/linux/ostypes.inc
« Reply #2 on: December 30, 2022, 10:39:06 am »
Would it make sense adding the following constants (also other names, but with these values)?

Applicable to what part of the rather large Linux API?

Tell us what you're proposing and why and you might get more than a single-word response out of Thaddy :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 16156
  • Censorship about opinions does not belong here.
Re: rtl/linux/ostypes.inc
« Reply #3 on: December 30, 2022, 10:43:12 am »
Such proposal duplicates functionalty already present, so hence NO.
If I smell bad code it usually is bad code and that includes my own code.

Чебурашка

  • Hero Member
  • *****
  • Posts: 586
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
Re: rtl/linux/ostypes.inc
« Reply #4 on: December 30, 2022, 10:43:35 am »
Would it make sense adding the following constants (also other names, but with these values)?

Applicable to what part of the rather large Linux API?

Tell us what you're proposing and why and you might get more than a single-word response out of Thaddy :-)

MarkMLl

I was thinking to the situations in which you create a file and you want to impose the permissions, in many cases is either 664 or 775.
Since there are already the S_IRWXU, S_IRWXG, S_IRWXO, I was wondering if also this constants can be useful, otherwise one needs always creating a local composition. If so, one could do also for the S_IRWXU, S_IRWXG, S_IRWXO and not have them in the rtl.

I rephrased the question becuase I forgot to mention the existence of S_IRWXU, S_IRWXG, S_IRWXO (sorry Thaddy)
« Last Edit: December 30, 2022, 10:45:41 am by tt »
FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

MarkMLl

  • Hero Member
  • *****
  • Posts: 8013
Re: rtl/linux/ostypes.inc
« Reply #5 on: December 30, 2022, 10:51:21 am »
Right, so it's applicable to filemodes.

It's probably not applicable to put them in ostypes.inc, but it might be worth considering adding them to the Unix package (i.e. outside the lowest levels of the RTL) if they really are a POSIX thing.

Even there, the simplicity of deriving the composite values and the fact that- strictly speaking- you'd need to account for the "sticky bit" and various setuid/setgid usage makes it of dubious advantage: industry standard usage is to add together the numeric constants as needed at the application level.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Чебурашка

  • Hero Member
  • *****
  • Posts: 586
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
Re: rtl/linux/ostypes.inc
« Reply #6 on: December 30, 2022, 11:19:54 am »
Right, so it's applicable to filemodes.

It's probably not applicable to put them in ostypes.inc, but it might be worth considering adding them to the Unix package (i.e. outside the lowest levels of the RTL) if they really are a POSIX thing.

Even there, the simplicity of deriving the composite values and the fact that- strictly speaking- you'd need to account for the "sticky bit" and various setuid/setgid usage makes it of dubious advantage: industry standard usage is to add together the numeric constants as needed at the application level.

MarkMLl

Okay. I understand the point.

Then why S_IRWXU, S_IRWXG, S_IRWXO are in ostypes.inc? This is a local grepping:

Code: Text  [Select][+][-]
  1. user_tt@debian:~$ grep -r ostypes.inc /usr/share/fpcsrc/3.2.0/
  2. /usr/share/fpcsrc/3.2.0/rtl/aix/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  3. /usr/share/fpcsrc/3.2.0/rtl/aix/unxfunc.inc:{ should probably be defined in ostypes.inc for all OSes }
  4. /usr/share/fpcsrc/3.2.0/rtl/aix/Makefile.fpc:  ostypes.inc osmacro.inc $(UNIXINC)/gensigset.inc \
  5. /usr/share/fpcsrc/3.2.0/rtl/haiku/baseunix.pp:{$i ostypes.inc}
  6. /usr/share/fpcsrc/3.2.0/rtl/haiku/baseunix.pp:// MAP_ANON(YMOUS) is OS dependant but used in the RTL and in ostypes.inc
  7. /usr/share/fpcsrc/3.2.0/rtl/haiku/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  8. /usr/share/fpcsrc/3.2.0/rtl/dragonfly/Makefile.fpc:  $(BSDINC)/ostypes.inc $(BSDINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  9. /usr/share/fpcsrc/3.2.0/rtl/openbsd/ptypes.inc:    // set in ostypes.inc wordsinsigset   = 4;           // words in sigset_t
  10. /usr/share/fpcsrc/3.2.0/rtl/openbsd/Makefile.fpc:  $(BSDINC)/ostypes.inc $(BSDINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  11. /usr/share/fpcsrc/3.2.0/rtl/inc/exeinfo.pp:{$i ostypes.inc}
  12. /usr/share/fpcsrc/3.2.0/rtl/android/Makefile.fpc:  $(LINUXINC)/ostypes.inc $(LINUXINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  13. /usr/share/fpcsrc/3.2.0/rtl/netbsd/Makefile.fpc:  $(BSDINC)/ostypes.inc $(BSDINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  14. /usr/share/fpcsrc/3.2.0/rtl/solaris/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  15. /usr/share/fpcsrc/3.2.0/rtl/solaris/unxfunc.inc:{ should probably be defined in ostypes.inc for all OSes }
  16. /usr/share/fpcsrc/3.2.0/rtl/solaris/Makefile.fpc:  ostypes.inc osmacro.inc $(UNIXINC)/gensigset.inc \
  17. /usr/share/fpcsrc/3.2.0/rtl/unix/baseunix.pp:{$i ostypes.inc}
  18. /usr/share/fpcsrc/3.2.0/rtl/unix/baseunix.pp:// MAP_ANON(YMOUS) is OS dependant but used in the RTL and in ostypes.inc
  19. /usr/share/fpcsrc/3.2.0/rtl/freebsd/Makefile.fpc:  $(BSDINC)/ostypes.inc $(BSDINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  20. /usr/share/fpcsrc/3.2.0/rtl/linux/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  21. /usr/share/fpcsrc/3.2.0/rtl/linux/Makefile.fpc:  ostypes.inc osmacro.inc $(UNIXINC)/gensigset.inc \
  22. /usr/share/fpcsrc/3.2.0/rtl/beos/baseunix.pp:{$i ostypes.inc}
  23. /usr/share/fpcsrc/3.2.0/rtl/beos/baseunix.pp:// MAP_ANON(YMOUS) is OS dependant but used in the RTL and in ostypes.inc
  24. /usr/share/fpcsrc/3.2.0/rtl/beos/ossysc.inc:{$i ostypes.inc}
  25. /usr/share/fpcsrc/3.2.0/rtl/beos/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  26. /usr/share/fpcsrc/3.2.0/rtl/darwin/Makefile.fpc:  $(BSDINC)/ostypes.inc $(BSDINC)/osmacro.inc $(UNIXINC)/gensigset.inc \
  27. /usr/share/fpcsrc/3.2.0/rtl/fpmake.pp:          AddInclude('ostypes.inc',AllUnixOSes);
  28. /usr/share/fpcsrc/3.2.0/rtl/fpmake.pp:          AddInclude('ostypes.inc');
  29. /usr/share/fpcsrc/3.2.0/rtl/bsd/sysos.inc:{$I ostypes.inc}                        // c-types, unix base types, unix base structures
  30. user_tt@debian:~$ grep -r S_IRWXU /usr/share/fpcsrc/3.2.0/
  31. /usr/share/fpcsrc/3.2.0/rtl/linux/ostypes.inc:    S_IRWXU =  S_IRUSR or S_IWUSR or S_IXUSR;
  32. /usr/share/fpcsrc/3.2.0/rtl/netwlibc/libc.pp:     S_IRWXU = $01C0;
  33. /usr/share/fpcsrc/3.2.0/rtl/netwlibc/sysdir.inc:  Res := FpMkdir (pchar(s),S_IRWXU);
  34. /usr/share/fpcsrc/3.2.0/rtl/netware/nwserv.pp:   S_IRWXU = 0000700;
  35. /usr/share/fpcsrc/3.2.0/rtl/bsd/ostypes.inc:    S_IRWXU =  S_IRUSR or S_IWUSR or S_IXUSR;
  36. /usr/share/fpcsrc/3.2.0/packages/libmicrohttpd/examples/demo.pp:      FpMkdir(uc^.language, S_IRWXU);
  37. /usr/share/fpcsrc/3.2.0/packages/libmicrohttpd/examples/demo.pp:      FpMkdir(PAnsiChar(fn), S_IRWXU);
  38. /usr/share/fpcsrc/3.2.0/packages/libmicrohttpd/examples/demo_https.pp:      FpMkdir(uc^.language, S_IRWXU);
  39. /usr/share/fpcsrc/3.2.0/packages/libmicrohttpd/examples/demo_https.pp:      FpMkdir(PAnsiChar(fn), S_IRWXU);
  40. /usr/share/fpcsrc/3.2.0/packages/libc/src/sstath.inc:  S_IRWXU = (__S_IREAD or __S_IWRITE) or __S_IEXEC;
  41. /usr/share/fpcsrc/3.2.0/packages/libc/src/sstath.inc:  S_IRWXG = S_IRWXU shr 3;
  42. /usr/share/fpcsrc/3.2.0/packages/libc/src/sstath.inc:  ACCESSPERMS = (S_IRWXU or S_IRWXG) or S_IRWXO;
  43. /usr/share/fpcsrc/3.2.0/packages/libc/src/sstath.inc:  ALLPERMS = ((((S_ISUID or S_ISGID) or S_ISVTX) or S_IRWXU) or S_IRWXG) or S_IRWXO;
  44.  

FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

MarkMLl

  • Hero Member
  • *****
  • Posts: 8013
Re: rtl/linux/ostypes.inc
« Reply #7 on: December 30, 2022, 11:39:43 am »
Then why S_IRWXU, S_IRWXG, S_IRWXO are in ostypes.inc? This is a local grepping:

Presumably because they're needed for the compiler or the system unit.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Чебурашка

  • Hero Member
  • *****
  • Posts: 586
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
Re: rtl/linux/ostypes.inc
« Reply #8 on: December 30, 2022, 11:58:09 am »
Then why S_IRWXU, S_IRWXG, S_IRWXO are in ostypes.inc? This is a local grepping:

Presumably because they're needed for the compiler or the system unit.

MarkMLl

Ah ok, I thought compiler did not use rtl units.
« Last Edit: December 30, 2022, 12:07:24 pm by tt »
FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

MarkMLl

  • Hero Member
  • *****
  • Posts: 8013
Re: rtl/linux/ostypes.inc
« Reply #9 on: December 30, 2022, 12:20:20 pm »
Ah ok, I thought compiler did not use rtl units.

"It's complicated" :-)

The best thing I can do is give an example from ten years ago where I was trying to reconcile two different attempts to get a MIPS target going:

Code: Text  [Select][+][-]
  1. # Build a compiler which runs on the host but targets mipsel, note debug options which are needed later:
  2.  
  3. cd /usr/local/src/fpc-trunk
  4. export PP=
  5. make "OPT=-O- -g" -C compiler mipsel
  6. mv compiler/ppcmipsel compiler/ppcXmipsel
  7.  
  8. # Renaming the compiler prevents it from being deleted by make clean etc., consider extending that OPT setting with -dEXTDEBUG.
  9.  
  10. export PP=/usr/local/src/fpc-trunk/fpc/compiler/ppcXmipsel
  11. make CPU_TARGET=mipsel OS_TARGET=linux rtl
  12. make CPU_TARGET=mipsel OS_TARGET=linux compiler
  13.  
  14. # Move the newly-generated compiler and the RTL units to the target system, which should now be able to do a full build.
  15.  

There's obviously better- and in particular officially-sanctioned- explanations, but that's what I can easily lay hands on right now and I think it illustrates the important points.

There's obviously been "feature creep" over the years, but basically the non-package part of the RTL contains- /should/ /contain/- only the bits that the compiler and internal toolchain need. However in the case of unix (note lower-case name) that contains things like syscall numbers and the structure returned by the stat() syscall, and at that point it's reasonable to have some degree of naming for the file attribute bits but not necessarily all possible combinations.

MarkMLl

https://wiki.freepascal.org/Native_MIPS_Systems
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5752
  • Compiler Developer
Re: rtl/linux/ostypes.inc
« Reply #10 on: December 30, 2022, 04:27:23 pm »
Then why S_IRWXU, S_IRWXG, S_IRWXO are in ostypes.inc? This is a local grepping:

The ostypes.inc contains declarations needed to implement the cross platform functionality inside the RTL and is included by various units because the declarations are the same.

Ah ok, I thought compiler did not use rtl units.

Of course the compiler uses the RTL, it's an ordinary Object Pascal program after all.

 

TinyPortal © 2005-2018