return(system("make -j 16"));
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
return(system("make -j 16"));
The return value of system() is not in the same format as the return value >>of main().
Regardless, it suffices for a "success/failure" indication.
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
return(system("make -j 16"));
The return value of system() is not in the same format as the return value
of main().
On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
return(system("make -j 16"));
The return value of system() is not in the same format as the return >>>>value of main().
Regardless, it suffices for a "success/failure" indication.
Mostly. The only exception looks to be very rare: if no shell is
available, then system() returns 0.
Why does this need to go through a shell?
On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit :
return(system("make -j 16"));
The return value of system() is not in the same format as the return >>>value of main().
Regardless, it suffices for a "success/failure" indication.
Mostly. The only exception looks to be very rare: if no shell is
available, then system() returns 0.
The last time I tried that on an FFmpeg build, it brought my machine to
its knees. ;)
Mostly. The only exception looks to be very rare
Lawrence D'Oliveiro , dans le message <upeddh$1mjib$2@dont-email.me>, a
écrit :
On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:
$ make -j
The last time I tried that on an FFmpeg build, it brought my machine to
its knees. ;)
But at least, with FFmpeg's build system, parallel build works.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit : >>>>>> return(system("make -j 16"));
Why does this need to go through a shell?
Something needs to parse and execute the command line.
On Wed, 31 Jan 2024 21:46:34 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit : >>>>>>> return(system("make -j 16"));
Why does this need to go through a shell?
Something needs to parse and execute the command line.
There is no need to “parse†any command line.
<manpages.debian.org/3/exec.3.en.html>
On Thu, 01 Feb 2024 00:25:53 +0000, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 21:46:34 GMT, Scott Lurndal wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 31 Jan 2024 19:21:56 -0000 (UTC), Lew Pitcher wrote:
On Wed, 31 Jan 2024 19:15:22 +0000, Scott Lurndal wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
vallor , dans le message <updt7h$1jc8a$1@dont-email.me>, a écrit : >>>>>>>> return(system("make -j 16"));
Why does this need to go through a shell?
Something needs to parse and execute the command line.
There is no need to “parse†any command line.
<manpages.debian.org/3/exec.3.en.html>
Lawrence, you will note that, in the original call
return(system("make -j 16"));
the argument to system() is a single string.
The equivalent exec() call takes a larger number of
arguments, including
a) the path to the program to be executed (in this case
something like "/usr/bin/make")
b) an array (or, for some of the exec() family, a list)
of pointers to strings representing each of the
arguments given to the program to be executed.
In this case, something like "make", "-j", "16", NULL
c) in some of the exec family, an array of environment
variable strings.
Do you see any of those /individual/ strings in the OP's
given argument to system()? I don't.
Yes, the OP /could/ have coded a fork/exec/wait codepath
and "hand parsed" the commandline, /BUT/ the OP instead
chose to use a handy utility function that does all that
for the cost of invoking a shell to parse out and build
the arguments to exec().
Dude. Get a handle on it. You don't have to be so argumentative
about a simple choice like that. No one is saying that
system() is the only way to go in a case like this, and
you seem to be over-reacting to this simple piece of code.
On 31 Jan 2024 22:28:45 GMT, Nicolas George wrote:
Lawrence D'Oliveiro , dans le message <upeddh$1mjib$2@dont-email.me>, a
écrit :
On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor wrote:
$ make -j
The last time I tried that on an FFmpeg build, it brought my machine to
its knees. ;)
But at least, with FFmpeg's build system, parallel build works.
I still feel that the “-j†option is a bit dangerous: the fact that you >can specify it with an argument or without means it is too easy to tell it
to use unlimited numbers of processes.
Tip: I often use
make -j$(nproc)
though I’m told you may want to add 1 to this.
Lawrence, you will note that, in the original call
return(system("make -j 16"));
the argument to system() is a single string.
The equivalent exec() call takes a larger number of
arguments, including ...
Lew Pitcher , dans le message <upe6kk$1ikg6$1@dont-email.me>, a écrit :
Mostly. The only exception looks to be very rare
Only exception?
Upon normal completion, system() returns the exit code of the child process shifted left by 8 bits.
Only the 7 or 8 lower bits of the return value of main() end up in the exit code of the process.
The lower 8 bits of something shifted 8 bits to the left: do the math.
On Thu, 1 Feb 2024 04:55:24 -0000 (UTC), vallor wrote:
Oh, and sidenote: I "researched" (asked ChatGPT) about make(1) being
POSIX, and it says it isn't.
POSIX Issue 7
<http://www.open-std.org/jtc1/sc22/open/n4217.pdf>, page 2830 onwards.
Oh, and sidenote: I "researched" (asked ChatGPT) about make(1) being
POSIX, and it says it isn't.
That's not what my man page says:
* If all system calls succeed, then the return value is
the termination status of the child shell used to exâ€
ecute command. (The termination status of a shell is
the termination status of the last command it exeâ€
cutes.)
Oh, and sidenote: I "researched" (asked ChatGPT) about
On 31 Jan 2024 23:24:07 GMT, Nicolas George <nicolas$george@salle-s.org> >wrote in <65bad697$0$3250$426a74cc@news.free.fr>:
Lew Pitcher , dans le message <upe6kk$1ikg6$1@dont-email.me>, a écrit : >>> Mostly. The only exception looks to be very rare
Only exception?
Upon normal completion, system() returns the exit code of the child process >> shifted left by 8 bits.
Only the 7 or 8 lower bits of the return value of main() end up in the exit >> code of the process.
The lower 8 bits of something shifted 8 bits to the left: do the math.
That's not what my man page says:
* If all system calls succeed, then the return value is
the termination status of the child shell used to exâ€
ecute command. (The termination status of a shell is
the termination status of the last command it exeâ€
cutes.)
[...]
CONFORMING TO
POSIX.1-2001, POSIX.1-2008, C89, C99.
[...]
But it wasn't a serious program anyway, it was a silly little program whose >sole job was to make itself.
Why? Because Bart posted a "C" source file that used nothing
but his own pragmas to build a project.
(Hey: if he want's to re-invent the wheel, it shouldn't start
off square...)
Oh, and sidenote: I "researched" (asked ChatGPT) about
make(1) being POSIX, and it says it isn't. However,
make(1) IS part of the SUS.
vallor , dans le message <upf87s$1tvq1$1@dont-email.me>, a écrit :
That's not what my man page says:
* If all system calls succeed, then the return value is
the termination status of the child shell used to exâ€
ecute command. (The termination status of a shell is the
termination status of the last command it exeâ€
cutes.)
That IS what the man page says, you just read it wrong. Thankfully,
Single Unix decided to avoid the pitfall by making it more explicit:
“If command is not a null pointer, system() shall return the termination status of the command language interpreter in the format specified by waitpid().â€
But you did not have to rely on badly worded sentences in English, you
could have just tested for yourself. You should have tested for
yourself.
Oh, and sidenote: I "researched" (asked ChatGPT) about
make(1) being POSIX, and it says it isn't. However,
make(1) IS part of the SUS.
On 2024-02-01, vallor <vallor@cultnix.org> wrote:
Oh, and sidenote: I "researched" (asked ChatGPT) about
make(1) being POSIX, and it says it isn't. However,
make(1) IS part of the SUS.
"POSIX" and "Single Unix Specification" are one entity.
It's beeen that way for years now.
How would Unix have helped with that? It wouldn't.)The question how Unix would have helped on an 8 bit CP/M machine forty
years go isn't very interesting today. At that time, Unix probably ran
best on machines with at least perhaps five to ten times the resources
of that, or thereabouts.
Not true. First of all you need to download MSVC first
And MS marketing was able to foster a community who could easily be brainwashed to find it natural that SW is so buggy and unreliable.
 -bash: ./configure: /bin/sh^M: bad interpreter: No such file or
directory
Janis Papanagnou , dans le message <upqpko$aild$1@dont-email.me>, a
écrit :
And MS marketing was able to foster a community who could easily be
brainwashed to find it natural that SW is so buggy and unreliable.
Please do not rewrite history. Marketing and community has nothing to do
with it, the magic trick was to convince hardware vendors to ship the OS pre-installed and then trap them with exclusivity contracts and NDAs about the price.
The Glibc shared library loading mechanism doesn't implement the nice strategy of finding libraries in the same directory as the executable.
Kaz Kylheku , dans le message <20240205160715.244@kylheku.com>, a
écrit :
The Glibc shared library loading mechanism doesn't implement the nice
strategy of finding libraries in the same directory as the executable.
This is not true, you know?
[...]
[ I feel dirty posting this without any
actual C topics in comp.lang.c, so I've set
the followup to comp.unix.programmer... ]
vallor <vallor@cultnix.org> writes:
[...]
[ I feel dirty posting this without any actual C topics in comp.lang.c,
so I've set the followup to comp.unix.programmer... ]
If it doesn't have any actual C topics, it would have been better to
take comp.lang.c off the list when it was posted.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 129:38:29 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,157 |