I'm using 'udhcpc' on my ARM64 platform with the following scenario: I have one
'eth0' interface that has a static ip address and the 'udhcpc' client on the
same interface. That leads to low data transmission performace on that
interface.
Most people use udhcpc when they *don't* have a static
|IIRC writing to /dev/urandom doesn't do what you want it to do.
|You have to use an ioctl() to actually set entropy.
And that is the sad point about it.
Kernel hackers should stand up to allow it again!
As Ted Ts'o said[1], and Donenfeld agreed[2], the problem is that
any user can write
Oh boy. Is it that time of the year again already?
In case the /dev/urandom initialisation is a necessity (or a best
practice), does it make sense to add it into busybox as an option or
as an application?
So, there are two different things to address here:
1. the way to add entropy to
You miss the point. CLOCK_MONOTONIC may simply be too granular
on some hardware - returning the same value for the duration of
several milliseconds.
Wait, what? Is that a thing? Is there actual hardware where
CLOCK_MONOTONIC stalls for a noticeable period of time?
That does not sound
# su userx
# id
uid=203(userx) gid=203(userx) euid=0(root)
Is this expected behaviour? From source I can see it does setuid()
which should also modify euid. If not then what could be the issue?
As is often the case, the best debug tool here is strace :)
What does "strace su userx id"
Busybox's ash built-in commands -e.g. echo, printf, cd- returns an error
if the stdout/stderr device is not available. In particular, I reached
this behavior while debugging a Debian initramfs, where ash built-in
commands are run during boot, before the console is available.
POSIX mandates
You're right. I am a part of a community distro which uses busybox by
default, and we need something to be able to change privileges to an
arbitrary user, but it is not portable to expect a tool to print all of
a username longer than 8 characters. Using the UID is more reliable.
There is no
/* We want to create a grandchild which will watch
* and kill the grandparent. Other methods:
* making parent watch child disrupts parent<->child link
* (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" -
* it's better if service_prog is a child of tcpsvd!),
* making child watch parent
A stock Linux system will happily slaughter your system services with the OOM
killer before malloc ever returns NULL.
Only if overcommit is activated, which is not a good idea in embedded
systems where busybox is likely to be used.
Also, resource limits are a thing, and proper administration
I'm not sure I completely understand though. Doesn't "exec" make it run
as PID 1?
Not if the script containing the "exec" does not run as pid 1 in the
first place.
When busybox init runs, it runs as pid 1, and stays there until
you shutdown the machine. Any script it spawns, even in your
Aha. We have CONFIG_EXTRA_LDLIBS. We just need to change the logic
so that it is not appended to LDLIBS, but treated separately,
with no elision.
That would be nice, thanks. Of course, they should be added to
the line *before* the LDLIBS, because they may depend on stuff like
-lpthread
Greetings,
busybox is linked via the scripts/trylink shell script. I have
found a couple issues with trylink's management of additional libraries:
1. https://git.busybox.net/busybox/tree/scripts/trylink#n123
This "sanitization" phase changes the semantics of the LDLIBS list.
When you
In current implementation of busybox timeout utility, when a signal
is sent to the process that needs to timeout, it does not affect the
children. To fix this we set the process group id of the process that
the signal is sent, same as it's pid, making it the process group
leader. When sending
The param should be marked with the nonnull attribute, just like the
libc string functions. Then the compiler will warn you if you try to
pass NULL (may need higher optimization, warning levels, or the
analyzer mode in complex cases).
Indeed.
A function that takes a pointer that *cannot* be
This is not a general condemnation on implementing a busybox binary that
you've just arbitrarily decided "shall not be accepted" simply by fiat,
without provided rationale and without being the project maintainer who
actually has the right to arbitrarily decide things.
But I did provide a
Laurent
you've put effort and heart to write that "funny" sketch
Oh please, stop the flattery. I didn't proofread, I left in a few typos
and grammar errors, and didn't even linewrap to 72 so it looks goofy in
the archive.
No, I put in the exact amount of effort that this thread is worth, i.e.
Hey folks,
I just had an idea today while crossing the street (please don't do
this,
it's dangerous, you may be hit by a car. It almost happened to me. It's
a
a good thing that I don't often have ideas!)
I thought that I've always needed a small applet that takes user input
from
Overcommit is disabled:
/ # cat /proc/sys/vm/overcommit_memory
2
That doesn't mean overcommit is disabled. That means it's enabled with
a hard limit. What was overcommit_ratio?
--
Laurent
___
busybox mailing list
busybox@busybox.net
The socket receive buffer turned out to be too small for real world
systems. Use the same size as udevd to be on the safe side. As this is
just a limit and the memory is not allocated by the kernel until really
needed there is actually no memory wasted.
Is it also the case when overcommit is
OTOH udevd seems to use a whooping 128MiB for the netlink socket receive
buffer. And the ENOBUFS error is exactly what should be returned if the
receive buffer overflows.
From experiments I made when writing mdevd (which is a standalone
replacement for mdev), the netlink socket buffer needs
The busybox mailing-list has managed, for the most part, to stay clear
of language flamewars during all these years.
Of course, blips happen now and then. A few years ago, the fashionable
language was Go, so inevitably, someone wrote "Gobox", because of course
they did. For the most part, we
If mdev is used as kernel hotplug helper and the system generates many
hotplug events it will quickly consume considerable resources because a
process is forked for each event and, if the mdev.seq feature is used,
they must also coordinate among each other. While the uevent applet
mitigates
If it was built with dynamically linked glibc, though, would it really
matter? busybox has no external dependencies other than, if dynlinked, a
couple of standard support libraries (libc, libm, libresolv, libcrypt),
so it should still work everywhere that has a more recent version of
glibc than
Using busybox nslookup failed due to one of the libraries I had removed
not
being there? libnss_dns and libnss_files. ldd busybox doesn't report
these
libraries are used? Once I put those libraries back, the nslookup
resolves.
That's because those shared libraries are not used at build
Not all systems have SA_RESTART, but signal_SA_RESTART_empty_mask() is
required to build busybox. This at least allows you to build on systems
without SA_RESTART.
SA_RESTART is POSIX, and supported at the very least on Linux,
Free/Open/NetBSD, MacOS and Solaris. What system is there that
When PID=0 in early kernel_init, PID=1 has a skeleton running, this
detection is not
the Busybox /sbin/init, but a place holder for when the real Busybox
/sbin/init is do_execve'd
Are you saying the kernel could spawn a /sbin/reboot process *before*
kernel_init execs into the userspace
Even when process=1 is started, it still leaves a window when the
signal handler setup has not been completed.
Yes, but you can still use kill(pid, 0) to check whether init is
ready to receive signals: doublefork a zombie and repeatedly kill it
with signal 0. When you get -1 ESRCH, it means
+ fdrc = connect(fdBB2,
+ (struct sockaddr *)_addr2,
+ sizeof(sa_family_t) +
+ BB_SIGNALS_SOCKET_STR_LEN);
+
Zombies will _always_ be observable, even if you try to reap
immediately.
Of course. I used "observable" in the broad sense, meaning there is a
nonzero amount of time where init is not runnable, won't be scheduled,
and won't immediately reap zombies. This makes zombie observation
literally
How about this:
IIUC, this changes init's behaviour to only sleep after it has just
started a direct child, so as long as the /etc/inittab processes are
stable, it will always reap distant orphans instantly; but it will
still wait for 1 second before reaping a batch of processes that died
at
It depends whether you consider init to be required to reap zombies
as fast as possible.
I don't see that as a requirement (so far, feel free to convince
me otherwise).
I don't see it as a hard requirement either; I don't really mind having
zombies around for a few seconds, provided they
Without this fix it will create zombies that might cause deadlocks
No.
On December 23rd, when you sent a message to the list describing your
issue, I sent a reply, the first reply you received, explaining what
was happening to you.
Did you read it?
Did ANYONE read it? Or is the thought of
What is the rationale behind not reaping the children when the program
exists? i run it from inittab as a respawn process and I get zombies
when killing it when not reaping children alas the fix was pretty
simple.
Unless you're running runsvdir as process 1, there's no reason to do
so,
Hello,
About two years ago, there was some talk on the Busybox mailing-list
about the need for a version of "mdev" that would not use a separate
process for every uevent (as a hotplug manager does) but that would act
as a daemon, able to handle a series of uevents - typically read from
the
That's OK, as the helper (/sbin/poweroff) has the opportunity to retry
if the connect() fails (because init hasn't established the listening
socket yet). The main difference is that the sender can detect failure,
and retry if necessary.
AF_UNIX sockets in the abstract namespace don't require a
There's the sigqueue() mechanism out there. From the man page, it
seems it's essentially dedicated to send data together with the signal,
but it also has a queueing mechanism implemented in the kernel. Wether
this allows the message to be kept in the queue until the destination
process
- using a synchronous channel to send the shutdown/reboot message
between the poweroff/reboot helpers, rather than an asynchronous
signal. Say, have init listening on a socket, allowing the poweroff
binary to wait and/or retry.
That would not work either: you could receive the event
(replying to myself because for some reason the busybox ML manager
does not send me the mails in a whole thread if I've been Cc:ed in
one of the messages in the thread. So now I need the Cc: every time.
ISTR it's a classic misfeature of Mailman.)
Xabier Oneca:
> Shouldn't "--color" be guarded
Declaration of ls_longopts and initialization of applet_long_options
were incorrectly guarded with ENABLE_FEATURE_LS_COLOR; that yielded a
"ls: NO_OPT: \xff" error message when long options were selected and
color support was not. This patch ensures long options are
initialized separately from
https://www.freebsd.org/cgi/man.cgi?query=inetd
"Theserver program isinvokedwith the service socket
as its standardinput, output and error descriptors"
Show me an implementation of inetd which does not do this.
Oh, I'm not pretending wikipedia is wrong. I was just
Unless they do want _remote user_ to see the message.
For example, if you start a shell over a tcp connection
("poor man's telnet"), you do want to see shell error messages
when you work in that shell, right?
IOW: inetd can't know which behavior is desirable, since both make
sense.
So the
inetd is tying stdout and stderr together.
Personally I think this is wrong since it generally means that
inetd services must be careful never to write to stderr.
Use tcpserver instead of inetd. It allows you to use the "inetd mode"
in applets, and does not exhibit the problems that inetd
not sure what the DGRAM socket corresponds to… On Linux /dev/log is
normally implemented as a SOCK_STREAM socket, so I suspect it’s not
that.
It is likely that. There is no standard at all for the nature of
/dev/log,
it all depends on your syslogd. Old versions of syslogd created /dev/log
When httpd proxies a request to another server, it first creates
an AF_INET socket, then resolves the server name to a sockaddr,
then connects to it. This fails if the server name resolves to
an IPv6 address.
This patch ensures that the socket is created with the correct
address family (AF_INET6
I was more or less surprised by the fact that the default method was
to put false information in the passwd file and was clarifying if this
was appropriate. As I've stated numerous times, I can't see a
circumstance where this would be advised.
It's very traditional to put nonsense information
Here's my suggested fix - as unintrusive as possible.
--
Laurent
0001-Only-use-nonstandard-unlocked-line-ops-when-we-re-ce.patch
Description: Binary data
___
busybox mailing list
busybox@busybox.net
A full gdb output is available here: http://pastebin.com/3k6SENiX
The issue comes from the fact that fflush(stream) is #define'd as
fflush_unlocked(stream), so fflush(0) actually runs
fflush_unlocked(0), which segfaults with the current version of
musl (but not glibc).
fflush_unlocked() and
On 15/09/2016 13:55, Denys Vlasenko wrote:
Works for me...
I can reproducibly segfault when wgetting a page twice (i.e. the file
already exists).
I can also reproducibly segfault when using busybox vi, for instance
on the index.html file downloaded with "wget http://skarnet.org/;
I have
Hello,
The current git HEAD of busybox (1.26.0.git today) segfaults when some
applets are invoked; at least wget and vi are impacted.
The failing config is here: http://skarnet.org/tmp/bbconfig.txt
I don't have time right now to look for the problematic commit, but
a version from last April
On 06/09/2016 20:59, Deweloper wrote:
My proposal is to change the interpretation of chpst's -u option a bit:
This would deviate from upstream runit's semantics. Your idea is valid,
but I think you should submit it to upstream runit first, because creating
incompatibilities between the
On 06/09/2016 04:04, Kang-Che Sung wrote:
Um, excuse me, but may I suggest a more informative message than "short write"?
"Short write" is a little bit unclear.
"Short write" is the standard technical denomination for that issue;
using another term would be confusing.
--
Laurent
On 04/09/2016 12:11, Lauri Kasanen wrote:
Over at TinyCore, we receive a huge number of questions of the type "I
got "short write", what does it mean?". Mostly for the rpi port and when
using bb wget. The attached patch makes the message more informative,
and hopefully lets more people know
On 26/08/2016 18:53, Denys Vlasenko wrote:
However, a more robust solution is to have process babysitter
to run some cleanup script. Imagine that udhcpc is killed with SIGKILL.
Can't handle that easily inside udhcpc...
Does the cleanup script need to be run every time udhcpc dies?
A process
Kbuild, be it the kernel's or busybox, assumes that ncurses is available
in /usr or /usr/local, and nowhere else. To override those assumptions if
your ncurses package isn't installed in a "standard" location, you need
a few workarounds, as in manual make variables.
My hand-built ncurses is
On 12/07/2016 23:53, Rich Felker wrote:
There are very good reasons it's a syscall rather than a device: many
use cases require a never-fails entropy source, and with the device
node approach they're vulnerable to fd-exhaustion attacks. Most
existing bad code, when faced with such a situation,
My unpopular but firm opinion is that existing supervision suites
(be it runit, s6, perp or even daemontools(-encore)) are already lightweight
enough, and easy to build and install on embedded environments for people who
want them, and that reimplementing them is more trouble than it's worth
We could say that waiting 6 minutes (using /dev/random) instead of 3
minutes (using getrandom()) is acceptable, but now what if you have 10
soft wanting to do that, /dev/random might block again
This thread is a dialogue of the deaf and a strawman burning fest, and if
you keep thinking the
On 30/06/2016 13:24, Robert Schiele wrote:
- off_t target;
+ off64_t target;
http://stackoverflow.com/a/3221920
If you need 64-bit types, compile your programs with -D_FILE_OFFSET_BITS=64,
which should be the default on reasonable systems (not sure how common
reasonable systems
On 29/06/2016 00:37, Etienne Champetier wrote:
Or everyone can switch to getrandom() because that's the right way
The solution I am suggesting:
- works today and is extremely easy to implement.
- does not require patching busybox.
- will work on every Linux kernel on the planet, not only
On 29/06/2016 00:10, Etienne CHAMPETIER wrote:
first user of this applet will be LEDE (OpenWrt) to save an urandom seed
using getrandom() (so we are sure /dev/urandom pool is initialized)
That, or you could simply "dd if=/dev/random of=/dev/urandom bs=1 count=$blah"
at boot time, in the
On 28/06/2016 20:19, KP.Kirchdoerfer wrote:
With busybox 1.24 ntpd fails to start and the boot process continues up to a
shell login - allowing me to configure, start diagnostics and resolve errors.
With busybox 1.25 ntpd seems to loop forever if now NTP servers are found,
blocking the boot
The lookup hash isn't collision-free: more than one input string
points to the same applet. Normally invalid applet names might
cause an unexpected one to run
And this should be a GoodThing (TM) ?
I'm inclined to vote against this change, because even if the risk
is minimal, and even if
On 08/04/2016 05:59, Mike Frysinger wrote:
keep in mind that PKG_CONFIG is a tool for the *host*, not for the *build*.
so mixing it in this way is almost assuredly wrong. much like there is a
HOSTCC var, you'll probably want to introduce a HOST_PKG_CONFIG var, and
then change these files to
On 11/02/2016 13:34, Bastian Bittorf wrote:
with OpenWrt there is a feature where you have a "protected" area
in RAM which is not lost during reboot and used for having a crashlog
safed over a reboot. ("crashlog.o") see e.g:
On 11/02/2016 12:44, Denys Vlasenko wrote:
In practice it is impossible to make daemons 100% robust.
Because of this, we have several generations of babysitting tools
which restart daemons on exit.
I don't think it's the correct argument. Supervision tools should not
be an excuse to be
On 01/02/2016 08:12, dietmar.schind...@manroland-web.com wrote:
Anyone doing engineering work should come up with a better reason
than something like "that's always been done that way".
Oh, definitely. But I'm not the one engineering something here,
I'm the bad guy saying I don't like the
On 29/01/2016 08:27, Nicolas CARRIER wrote:
Even if I'm using linux, I want the solution to work in the context
of init being launched as a pid 1 of a pid namespace, which is my
main use case. In this situation, the kernel's command line can't be
changed as it's the one of the host PC.
But
On 29/01/2016 17:50, Nicolas CARRIER wrote:
I quite agree with dietmar, concerning uglyness...
That doesn't change the fact that it's the behaviour of every
init binary since 1970 and that you should come with a better reason if
you want to change it, especially since it's so easy to
The technical impact of Denys's change was actually extremely small,
which is the main reason why it was not discussed (much) on the list.
The change was meant to send a political message, and it has done so
quite successfully. The message is: Busybox will not yield to
aggressive
On 05/11/2015 06:33, Tycho Andersen wrote:
I'm experiencing some confusing behavior with busybox when running it
in an LXC container. In particular, this means that stdin, stdout, and
stderr are all /dev/null when busybox is exec()'d as init.
The relevant function is console_init() in
On 20/10/2015 13:17, Denys Vlasenko wrote:
inotifyd syntax is "inotifyd PROG FILE1[:MASK]...",
and PROG is run with
PROG ACTUAL_EVENTS FILEn [SUBFILE]
This severely limits the number of unmodified PROGs you can run
to achieve some useful result. (...)
IOW: in practice, you always need a
On 16/10/2015 20:29, Denys Vlasenko wrote:
I think killing $PPID from children is a completely legitimate approach.
FWIW, I dislike parricide. The flow of information is backwards; it
forces the child to know in what context it is run.
I agree with Bartosz in that it is much cleaner to
On 14/10/2015 08:37, Natanael Copa wrote:
using a screen and keyboard or via serial cable. he logs in as root,
but is not asked for password or just press when asked for
password.
What companies usually do in this case (typically ISPs with modems
they ship to users) is set a trivial root
On 13/08/2015 12:36, Bastian Bittorf wrote:
maybe this is a race?
root@box:~ rm -fR /tmp/dbcache
rm: can't remove '/tmp/dbcache': Directory not empty
root@box:~ echo $?
1
Most likely a race. It's impossible to atomically remove
a directory with Unix.
(There's a way to emulate that: first
On 13/08/2015 15:57, Bartosz Golaszewski wrote:
Implement daemon mode for readahead.
Please at least add a config guard so it can be deactivated at compile time
(no matter what the default setting for the readahead applet selection is).
This is feature creep and makes me quite
On 13/08/2015 15:57, Bartosz Golaszewski wrote:
Fanotify syscalls are not supported in uClibc. Add a new include
file - missing_syscalls.h - implementing the syscalls directly in
busybox.
It's not a good idea to start fixing libc problems in applications.
If you want to use a system call that
On 27/07/2015 17:03, walter harms wrote:
Interestingly it seems a bit complicated to have a system without syslogd.
Without syslog, i.e. the client part.
A quick grep in the source shows that at first sight, FEATURE_SYSLOG is
only used in two places, libbb/verror_msg.c and libbb/info_msg.c,
On 22/07/2015 13:46, Xabier Oneca -- xOneca wrote:
I've read alloca is not portable anyways...
It's probably portable on every platform busybox is running on.
(I'm not advertising its use, just saying I don't think it's the
right argument for not using it.)
I'm not an expert, but why not
X-Greylist: delayed 00:06:59 by SQLgrey-1.7.6
(For the record, I read the headers wrong, and it's osuosl.org
that actually performs that greylisting. My apologies to Numericable,
for once I accused them wrongly.
Now to understand what that greylisting does for osuosl.org...
if they're using
Hello,
The latest message I sent to the list was blocked by the busybox.net MX
because my IP was listed in the SpamHaus PBL - that means it is a dynamic
address provided by my ISP, which it indeed is. Mail servers that
reject mail based on a PBL listing basically enforce the use of the
On 03/07/2015 13:53, john smith wrote:
I wonder then where does this text come from? It may be specific to
NOOBS but I am not sure.
When syslogd is not running, syslog() will send its output to
/dev/console, which is what you are observing.
--
Laurent
On 09/06/2015 16:57, Isaac Dunham wrote:
Or is blanking the root password completely wrong?
I wouldn't say it's wrong, but it can be easily avoided.
You can always use a trivial password such as root or admin
for an initial machine setup.
--
Laurent
On 09/06/2015 21:44, Natanael Copa wrote:
It is an interesting dilemma. What is worse, blank root password or
weak/default root password (eg 'root' or similar)?
I'll suggest that it doesn't matter in the slightest, because a
machine should only be in either state when it's on a trusted
On 19/04/2015 18:57, Denys Vlasenko wrote:
# !: do not create device node
Ah, I missed the major = -2 trick. Sorry for giving out
wrong information... I should check for all the available
documentation before diving into the source (and verifying
that the documentation is correct) .
--
On 18/04/2015 17:05, Floris Bos wrote:
I tried enabling waiting for sequence numbers by echoing a newline to
/dev/mdev.seq, however I noticed there are situations where that does
not work properly either.
Yes, it's the classic sequentiality problem. The userspace cannot
guarantee that mdev
On 18/04/2015 18:00, Floris Bos wrote:
Simply letting devtmpfs instead of mdev handle the removal of the actual device
node files wouldn't be an option?
I don't think I have a real need for sequentiality on any other operation.
I'm not sure whether devtmpfs handles device node removal
On 15/04/2015 18:46, Denys Vlasenko wrote:
How about the following applet, which would listen to netlink and spawn a helper
for every new message?
There are arguments for it and against it. We addressed that in the
giant thread that happened last month. Grep your mailbox for
mdev -i. The
On 13/04/2015 12:54, Leonid Fedorenchik wrote:
opendir();
do {
unlinked_files = 0;
while (readdir()) {
unlink();
unlinked_files = 1;
}
if (unlinked_files)
On 13/04/2015 13:38, Laurent Bercot wrote:
Which means that it is very possible for readdir() to keep returning
NULL after a rewinddir() even if files have been added to the directory
in the meantime.
Sorry, I was wrong about that. rewinddir() actually sets the directory
in the same state
Well, I've poked at this a little this evening.
See
https://github.com/idunham/busybox
(in branch mdev) if you're curious about details.
Hi Isaac,
Nice job!
A few comments:
- Original mdev relies on getenv/putenv to handle environment
variables; that's okay, because it's a short-lived
On 20/03/2015 17:47, Isaac Dunham wrote:
I'm not sure I follow you on the malloc/free/realloc bit:
-as far as I know, getenv() does not malloc() anything, but returns
the numeric value of a pointer within char ** environ
getenv() is not a problem indeed. (Reading is rarely a problem,
it's
On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
I skim over that discussion (because I don't agree with the design) so
I can't make any substantial
On 15/03/2015 14:29, Natanael Copa wrote:
It should be possible to solve the hotplug problem by setting up
netlink listener, wait for event, when event arrives fork helper and
just hand over the netlink socket filedescriptor to the child. That way
we avoid pipes/fifos alltogehter. And we avoid
On 15/03/2015 15:52, Natanael Copa wrote:
I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out the pipe and remove the need
of any micro protocol.
As I wrote in another message,
On 15/03/2015 19:39, Harald Becker wrote:
On most systems it is perfectly possible to have multiple readers on
a pipe, when all readers and writers be so polite to use the same
message size (= PIPE_BUF). On most (but not all Unix systems) the
kernel guaranties not only atomicity for write
On 15/03/2015 20:41, James Bowlin wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html :
^
For goodness sake. This appears to be an argument merely for the
sake of having an argument.
This is POSIX.1-2008, the very specification that
On 15/03/2015 23:44, Harald Becker wrote:
There are to many stupid programmers out there, who would try to add
something like that into system management related programs. Couldn't
go worser. Even if it works, at the first glance, it is error prone,
and the next who change message size of one
On 15/03/2015 21:54, Harald Becker wrote:
My lead in was: just for curiosity, and that's it, it works on many systems.
... but I never proposed, doing something like that. It's what my lead in says:
curiosity.
Okay, fair enough. Please let's not do it then. :)
--
Laurent
On 14/03/2015 20:23, Rich Felker wrote:
Could you elaborate on how you measure that? With musl only the parts
of stdio you actually use will be linked, and use of exit does not
result in linking of any additional code, since the startup code has
to call exit(main(...)) anyway. In any case exit
On 13/03/2015 21:32, Michael Conrad wrote:
I stand corrected. I thought there would be a partial write if the
pipe was mostly full, but indeed, it blocks.
Except you have to make the writes blocking, which severely limits
what the writers can do - no asynchronous event loop. For a simple
1 - 100 of 292 matches
Mail list logo
