Ticket #52 (closed bug: fixed)

Opened 7 years ago

Last modified 7 years ago

Parrot can't read from stdin

Reported by: rgrjr Owned by:
Priority: normal Milestone:
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


Copying this test code:

.sub test :main
	## Test reading five characters from stdin.
	.local string input_string
	.local int len
	input_string = read 5
	len = length input_string
	print "[read '"
	print input_string
	print "' len "
	print len
	print "]\n"

into read-stdin.pir and running it in r33938 produces the following result:

rogers@rgr> ./parrot read-stdin.pir < read-stdin.pir 
[read '^@^@^@^@^@' len 5]

We've told Parrot to read five characters, but the five characters it reports are ASCII nuls (which I've replaced with '^@' to make them readable), rather than the expected ".sub ". Terminal input has the same problem.

I've tracked this to somewhere between Parrot_io_read_buffer and Parrot_io_read_unix, which is called in the "if (len >= Parrot_io_get_buffer_size(interp, filehandle)) { ... }" case. I do not understand why Parrot_io_read_unix calls Parrot_io_make_string on the passed buffer arg; doesn't that just reallocate strstart?

FWIW, the logic in Parrot_io_read_win32 is somewhat different, so the bug might not be present on Windows; I can't check that.

-- Bob Rogers,  http://www.rgrjr.com/

Change History

Changed 7 years ago by allison

I can't reproduce this on Ubuntu 8.10 64-bit, or Mac OS 10.5.6, at r36078. What platform are you running on? Or, has this issue been resolved by other I/O fixes made since the report?

Changed 7 years ago by chromatic

  • status changed from new to closed
  • resolution set to fixed

I used to be able to reproduce this with Bob's code, but I can't anymore. I think we've fixed it. Bob, if you can reproduce this, please reopen.

Note: See TracTickets for help on using tickets.