why not use more functionality from the posix standardd libc ?

classic Classic list List threaded Threaded
6 messages Options
Jim
Reply | Threaded
Open this post in threaded view
|

why not use more functionality from the posix standardd libc ?

Jim
On 10/3/18, Sean Conner <[hidden email]> wrote:
> it was not about using in the first place. it was just an example of what other
> small embedding languages can do/provide. the point here was that such
> functionality could be added to Lua aswell without too much work
> (in that case it was Squirrel's builtin regex lib wich provides pattern alternatives
> using the '|' OR regex operator).

in this case Suirrel's author provides such a lib that could be used
directly by Lua
if adding such a regex operator is turns out to be too much work.
another solution would be using the builtin Squirrel regex lib's code directly,
it is written in C++ though, but i a very procedural style that does
not use much
(if any) OO features, so translating it to C should be not much work
(i don't know why C++ is used here at all, seems like a Windows thing, where
C++ was promoted since plain C was declared "obsolote" by M$.).
the code can directly work on unicode strings.

> In some respects yes.  In other respects no.
> On Linux you need to link with pthreads of you use that;
> not so on other systems. On Solaris you need
> to link with nt if you want to use the network API
> (socket(), bind(), accept(), etc) but no so with other Unix systems.

i was merely talking about basic functionality (mostly found in <unistd.h>)
like get(ugp)id, chdir (!!!!!), chmod, chown and the like which are wrappers
around kernel syscalls in the libc and require no libs other than libc
(which is used by lua anyway, so way not exploiting that a bit more ?).

but as we are at it:
if Lua is build on Linux, BSD, Solaris etc the platform is know at build time
(via feature test macros and makefile rules, see below), so one could indeed
build in socket/thread support and use other platform specifics which are
provided by default vendor libs.

> On Windows, POSIX isn't part of the C library
> (although I could be wrong, but I would find it surprising).

but even M$ provides some limited POSIX functionality.
but this is not much of a problem, see below.

sounds a bit like you don't use their nice products anyway. :D
maybe even if you were paid for doing so, who knows ? ;-)

> Okay, round two.  If I have a program that makes use of pthreads, on
> Solaris it comes "for free" (your terms) in libc.  On Linux, the pthreads
> API is NOT in libc, so it's not "for free" in that reguard
> -- you have to link with libpthread.

> if I have a program that uses socket(), bind(), accept(), listen(), etc.
> (the Berkeley sockets API), those calls come "for free" on
> Linux --they're part of libc.
> On Solaris, they are not "for free" --they are not part of
> libc and you are required to link against libnt.

but we can easily figure out where we are compiling and react accordingly.

> On Windows, you don't even get get*id(), umask(), fork() or wait() AT ALL!
> Windows does not natively support POSIX.

dunno, don't use it. but i am sure it can be detected by feature test macros
(OS and compiler ("Visual Sudio" ?)).
in the case of POSIX functionality POSIX macros HAVE to be #defined.

when building the OS information is provided by the make call as in
"make linux", "make solaris" etc. so we know the OS without such preprocessor
macros anyway.

> I don't know which Unix you are using, but the ones I've had
> experience with never came with regex "for free" (as part of libc).

Linux with glibc and musl (the latter uses the TRE lib.
i am sure ulibc has that as well). ever used that ?
when trying it out have a look at /usr/include/regex*.h and man 3 regex.
same for the BSDs and of course macOS, Solaris, AIX, and HP-UX since they are
certified (and marketed) as conforming to POSIX standards.

>> well posix requires regex to be found in <regex.h>, so every unix has
>> them, from aix to the bsds, its in the libc that one has to use anyway.
>> so its there for FREE on all relevant unix platforms.

> Again, not always so in my exerience.

what non POSIX OS do you use ?
the major one is Windows and even that provides some limited POSIX support.

Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality from the posix standard libc ?

Jim-2
On Thu, May 09, 2019 at 04:15:24AM +0200, Jim wrote:
> but we can easily figure out where we are compiling and react
> accordingly.  when building the OS information is provided by the make
> call as in "make linux", "make solaris" etc. so we know the OS without
> such preprocessor macros anyway.

indeed.

the posix target in the Lua makefile should just run the uname(1)
utility to figure out the build platform and act accordingly (by passing
the correct -(D,I,L) options to the compiler) on its own.

this could obsolete the more specific rules (linux, freebsd, bsd, aix
etc) so that only the non-posix platform rules would remain
(do non-posix platform toolchains use makefiles at all ?).

enabling readline support by default on Linux is no good idea btw since
many distros do not install the needed headers/libs in the default install.


Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality from the posix standard libc ?

Gé Weijers


On Wed, May 8, 2019 at 9:08 PM Bob <[hidden email]> wrote:

enabling readline support by default on Linux is no good idea btw since
many distros do not install the needed headers/libs in the default install.


Many distros don't install the C compiler by default, for that matter, so you have to do some basic system administration anyway. It gets even more interesting on Windows.

I don't think Lua was intended as a "batteries included" general purpose scripting language like Python, but more as an extension language for people to use in building tools, so it assumes a bit more system administration and/or programming knowledge to get the code built.


--
--

Jim
Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality from the posix standard libc ?

Jim
On 5/9/19, Gé Weijers <[hidden email]> wrote:
> It gets even more interesting on Windows.

:-(((((

> I don't think Lua was intended as a "batteries included" general purpose
> scripting language like Python, but more as an extension language for
> people to use in building tools, so it assumes a bit more system
> administration and/or programming knowledge to get the code built.

but introducing an extra lib/header dependency by default (readline)
without using important basic functions (like chdir, rmdir, chmod, ...)
provided by libc (that gets linked in anyway) seems pretty odd to me.
especially since the platform can be detected easily.

Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality from the posix standardd libc ?

Sean Conner
In reply to this post by Jim
It was thus said that the Great Jim once stated:
> On 10/3/18, Sean Conner <[hidden email]> wrote:
> > On Windows, POSIX isn't part of the C library
> > (although I could be wrong, but I would find it surprising).
>
> but even M$ provides some limited POSIX functionality.
> but this is not much of a problem, see below.
>
> sounds a bit like you don't use their nice products anyway. :D
> maybe even if you were paid for doing so, who knows ? ;-)

  The last (and only) time I did development under Windows was in 1996 when
I wrote a Java Applet for the company I was working for at the time.  I
haven't used Windows since.

> > I don't know which Unix you are using, but the ones I've had
> > experience with never came with regex "for free" (as part of libc).
>
> Linux with glibc and musl (the latter uses the TRE lib.
> i am sure ulibc has that as well). ever used that ?
> when trying it out have a look at /usr/include/regex*.h and man 3 regex.
> same for the BSDs and of course macOS, Solaris, AIX, and HP-UX since they are
> certified (and marketed) as conforming to POSIX standards.
>
> >> well posix requires regex to be found in <regex.h>, so every unix has
> >> them, from aix to the bsds, its in the libc that one has to use anyway.
> >> so its there for FREE on all relevant unix platforms.
>
> > Again, not always so in my exerience.
>
> what non POSIX OS do you use ?

  Well, MS-DOS and AmigaOS spring to mind.

  But I finally tracked down the source of my issues, and yes, I was
mistaken, regex *was* a part of the Unix system I was using at the time
(Linux) but it was a horrible experience in using it.

  I was never liked regex.  Ever.  I find them exceedingly hard to
understand as they devolve into line noise in my opinion.  Not only do I
find them hard to read, but you can't combine them (unlike LPEG, which you
can easily build up piecemeal and combine---very nice).

  Anyway, the *one* time I tried using them in a program I wrote made the
program *SLOWER* than the ad-hoc command line with multiple greps piped
together [1].  I ended up having to download an external regex library and
compile that because the system provided one was completely borked beyond
usability.

  Have I mentioned I really don't like regex?

  Anyway, I misremembered some details from 16 years ago.

  -spc (I really don't understand why you feel such functionality *has* to
        be included when it's available as third party code ... )

[1] For the gritty details:
        http://boston.conman.org/2003/01/12.1

Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality from the posix standard libc ?

Scott Morgan
In reply to this post by Jim
On 10/05/2019 04:16, Jim wrote:
> but introducing an extra lib/header dependency by default (readline)
> without using important basic functions (like chdir, rmdir, chmod, ...)
> provided by libc (that gets linked in anyway) seems pretty odd to me.
> especially since the platform can be detected easily.

readline is just for the (optional) stand-alone executable, not the
language itself, which needs to be as portable as possible (i.e. ANSI C
only)

Scott