On Friday, 11 December 2020 at 18:18:35 UTC, kdevel wrote:
On Friday, 11 December 2020 at 16:49:18 UTC, Adam D. Ruppe
wrote:
libc-2.30.so
The bug was fixed in 2.28 IIRC.
so i guess i have the fixed libc. Can you confirm what version
you have?
Various. I tested the code on a machine
On Friday, 11 December 2020 at 16:49:18 UTC, Adam D. Ruppe wrote:
libc-2.30.so
The bug was fixed in 2.28 IIRC.
so i guess i have the fixed libc. Can you confirm what version
you have?
Various. I tested the code on a machine running the yet EOL
CENTOS-6
having glibc 2.12.
On Friday, 11 December 2020 at 16:37:42 UTC, kdevel wrote:
expected: program ends
found: program still reading
works for me looks like i have
libc-2.30.so
so i guess i have the fixed libc. Can you confirm what version
you have? I did `ls /lib/libc*` to pick that out but it might be
not POSIX
compliant
[2]
https://unix.stackexchange.com/questions/517064/why-does-hexdump-try-to-read-through-eof
[3]
https://stackoverflow.com/questions/52674057/why-does-an-fread-loop-require-an-extra-ctrld-to-signal-eof-with-glibc
On Friday, 11 December 2020 at 12:34:19 UTC, kdevel wrote:
My code cannot do that because the function byChunk has control
over the
file descriptor.
What do you mean by control? It just has the file handle, why do
you cannot call eof() on the file handle struct?
You should not check
ur here if you use a buffer of length 4.
I don't know what you want to achieve here.
Read till EOF.
If you want to stop reading from stdin, you should check for
eof() instead.
My code cannot do that because the function byChunk has control
over the
file descriptor. The OS reports EOF
t you want to achieve here. If you want to stop
reading from stdin, you should check for eof() instead. You
should not check yourself for the character. eof() can be lock in
by multiple ways and it is the only correct way to handle all of
them.
Currently as a workaround I read all the chars from stdin with
import std.file;
auto s = cast (string) read("/dev/fd/0");
after I found that you can't read from stdin. This is of course
non-portable Linux only code. In perl I frequently use the idiom
$s = join ('', <>);
that
On 12/16/2017 05:21 PM, Unazed Spectaculum wrote:
> 1) Starting program
> unazed@unazed /home/d/storage-server dmd -debug -run app.d
Although I don't normally use the -run switch, as expected, it works
with -run as well. (More below.)
> Listening: 0.0.0.0:6969
>
> 2) telnet to the server
On Thursday, 14 December 2017 at 20:27:36 UTC, Ali Çehreli wrote:
On 12/14/2017 11:55 AM, Unazed Spectaculum wrote:
This is the only function which has a call to `receiveAll`
I marked my changes with [Ali]:
import std.stdio;
import std.socket;
import std.conv;
import std.json;
ubyte[]
On 12/14/2017 11:55 AM, Unazed Spectaculum wrote:
This is the only function which has a call to `receiveAll`
I marked my changes with [Ali]:
import std.stdio;
import std.socket;
import std.conv;
import std.json;
ubyte[] receiveBytes(T)(T socket, size_t receiveCount)
{
ubyte[] buffer =
On Thursday, 14 December 2017 at 00:09:39 UTC, Ali Çehreli wrote:
On 12/13/2017 11:39 AM, Unazed Spectaculum wrote:
> ubyte[] receiveBytes(T)(T socket, size_t receiveCount)
> {
> ubyte[] buffer = new ubyte[receiveCount];
> size_t count = socket.receive(buffer);
Don't trust code you
On 12/13/2017 11:39 AM, Unazed Spectaculum wrote:
> ubyte[] receiveBytes(T)(T socket, size_t receiveCount)
> {
> ubyte[] buffer = new ubyte[receiveCount];
> size_t count = socket.receive(buffer);
Don't trust code you find on newsgroups. :o) You have to check the
returned value first.
ubyte[] receiveBytes(T)(T socket, size_t receiveCount)
{
ubyte[] buffer = new ubyte[receiveCount];
size_t count = socket.receive(buffer);
return buffer[0 .. count];
}
string receiveAll(T)(T socket, size_t segmentSize = 1024)
{
ubyte[][] data;
size_t count
On Wednesday, 26 June 2013 at 04:46:32 UTC, Ali Çehreli wrote:
On 06/25/2013 09:26 PM, lx wrote:
Ctrl+z seems close the stream.So,if I want
to input another batch of data,it became impossilbe.So,how to
reopen the
stream again to allow me to input another batch of data?
Making a copy of
On Wednesday, 26 June 2013 at 13:45:41 UTC, lx wrote:
On Wednesday, 26 June 2013 at 04:46:32 UTC, Ali Çehreli wrote:
On 06/25/2013 09:26 PM, lx wrote:
Ctrl+z seems close the stream.So,if I want
to input another batch of data,it became impossilbe.So,how to
reopen the
stream again to allow me
On Monday, 24 June 2013 at 21:13:31 UTC, bearophile wrote:
I am very confused that ctrl+z didn't teminate the input of
console,it result in a dead loop.
I think this is a library bug, I noticed it some times, but I
didn't file it. Maybe it's worth filing in Bugzilla.
I have added this bug
On 06/25/2013 09:26 PM, lx wrote:
Ctrl+z seems close the stream.So,if I want
to input another batch of data,it became impossilbe.So,how to reopen the
stream again to allow me to input another batch of data?
Making a copy of stdin works on Linux (where the stream is terminated by
Ctrl-D in
On 06/25/2013 09:26 PM, lx wrote:
I input ctrl+c,the code will terminate
abnormally.Why this happened?
Ctrl-C appears as SIGINT under POSIX systems. You need to register a
handler for that signal:
import std.stdio;
import std.string;
import core.sys.posix.signal;
bool isDone = false;
Hi,everyone,
I am learning D.I installed a plugin-visusl D to visual studio
2008.I am very confused that ctrl+z didn't teminate the input of
console,it result in a dead loop.When reading from a txt file,a
extra line will be read and usually it result in a wrong
result.Is there anyone who has
lx:
I am very confused that ctrl+z didn't teminate the input of
console,it result in a dead loop.
I think this is a library bug, I noticed it some times, but I
didn't file it. Maybe it's worth filing in Bugzilla.
When reading from a txt file,a extra line will be read and
usually it
I am very confused that ctrl+z didn't teminate the input of
console,it result in a dead loop.
I think this is a library bug, I noticed it some times, but I
didn't file it. Maybe it's worth filing in Bugzilla.
I have added this bug report, is this the issue you are
seeing/having?
/eof/error'd
stdin, it will just loop...
This FAQ link explains it pretty well for C++, which is pretty
much the same thing as in D:
http://www.parashift.com/c++-faq/stream-input-failure.html
(the next few points are relevant too).
We could argue the design isn't optimal, yes, but it's
monarch_dodra:
I don't think this is a bug
I see. Then lx will have to explain the problem better.
(I replied on the bug report):
I have given an answer, comparing to Python. I think the current
Phobos behavour is bad.
Bye,
bearophile
I'm using the following to read arrays from the command line (or
redirected file) but am having some issues that I have not been
able to solve on my own. Would appreciate if a little guidance.
void f(T)(ref T a)if(isArray!T)
{
a.length = 100;
int i;
while(readf( %s, a[i++])) // #1
On 3/22/12, Tyro[17] nos...@home.com wrote:
issue #2
how do i read a string[] such that whitespace (all or one of
my choosing) delineate the string boundary?
Jesse Phillips has a cmdln.interact library that I think would work by using:
string[] result = userInput!(string[])(Enter
Nobody knows how to solve that problem? I tried some other solutions where I
ran into the same problem:
/* Works as long as bytes available and the length of my buffer is 1 -
doesn't work if the file-size (which
is unknown) has a size which is a multiple of the buffer size... for ex. if the
Hey guys,
is there any way to find the end a socketstream? When I use:
MemoryStream ms = new MemoryStream();
while (s.socket().isAlive()) ms.write(s.getc());
I run into an endless loop. The socket doesn't send the size of the data, so I
need to know when I received all the data. How can I
28 matches
Mail list logo
