"hard" skips and seeks (without lseek(3p)) are reported in the diagnostics
considerable refactoring
updated docs
+ dj(1) is now littered with assertions for future bug report help
+ fixes #112
+ "hard" skips and seeks (without lseek(3p)) are reported in the diagnostics
+ considerable refactoring
+ updated docs
trinity
added the bug label 2024-07-03 14:24:19 -06:00
I think this is the best dj(1) can be, at least until we spot another bug. #94 will let us move out that parse() routine which will be nice.
I'm happy with the code size, especially relative to functionality which is much improved. Many of the little nits have been picked.
I think this is the best dj(1) can be, at least until we spot another bug. #94 will let us move out that parse() routine which will be nice.
I'm happy with the code size, especially relative to functionality which is much improved. Many of the little nits have been picked.
No error message to alert the user that the device has no storage left. Please handle the error in writing to an output.
```
$ build/bin/dj -o /dev/full
meow meow meow
build/bin/dj: Partial read:
0100150010015-2
```
No error message to alert the user that the device has no storage left. Please handle the error in writing to an output.
On OpenBSD, write(2) doesn't error (by returning -1) on /dev/full - writing "meow\n" to /dev/full apparently succeeds, returning 5 (the expected number of bytes written).
dd(1) on OpenBSD exhibits the same behavior:
# printf 'meow\n' | dd of=/dev/full
0+1 records in
0+1 records out
5 bytes transferred in 0.000 secs (40922 bytes/sec)
I had to $ cat </dev/full to realize the pseudodevice doesn't exist on OpenBSD. It looks like the write succeeded on your system, too? What's your $ uname -a?
Please comment with the output with -H.
On OpenBSD, write(2) doesn't error (by returning -1) on /dev/full - writing "meow\n" to /dev/full apparently succeeds, returning 5 (the expected number of bytes written).
dd(1) on OpenBSD exhibits the same behavior:
```
# printf 'meow\n' | dd of=/dev/full
0+1 records in
0+1 records out
5 bytes transferred in 0.000 secs (40922 bytes/sec)
```
I had to `$ cat </dev/full` to realize the pseudodevice doesn't exist on OpenBSD. It looks like the write succeeded on your system, too? What's your `$ uname -a`?
Along these lines I did notice a bug in the write functionality that is now fixed. Judging from your dj(1) statistics it wasn't, but you may want to try again anyway.
Along these lines I did notice a bug in the write functionality that is now fixed. Judging from your dj(1) statistics it wasn't, but you may want to try again anyway.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
@emma could you verify #112 is fixed on this branch?
@@ -36,3 +36,3 @@When seeking or skipping to a byte, writing or reading starts at the byteimmediately subsequent to the specified byte.immediately subsequent to the specified byte. Seeks and skips aren\(cqt countedIsn’t this not the case anymore? I thought we write at the byte specified, now.
I think this is the best dj(1) can be, at least until we spot another bug. #94 will let us move out that parse() routine which will be nice.
I'm happy with the code size, especially relative to functionality which is much improved. Many of the little nits have been picked.
No error message to alert the user that the device has no storage left. Please handle the error in writing to an output.
Please comment with the output with -H.
On OpenBSD, write(2) doesn't error (by returning -1) on /dev/full - writing "meow\n" to /dev/full apparently succeeds, returning 5 (the expected number of bytes written).
dd(1) on OpenBSD exhibits the same behavior:
I had to
$ cat </dev/fullto realize the pseudodevice doesn't exist on OpenBSD. It looks like the write succeeded on your system, too? What's your$ uname -a?Along these lines I did notice a bug in the write functionality that is now fixed. Judging from your dj(1) statistics it wasn't, but you may want to try again anyway.
Give it another whirl.
Merged.
Pull request closed