Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

and i wrote:
  ...
 |The POSIX standard says that the error condition shall be set if
 |a read or write error occurs only, but this should not be the case
 |here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
 |(note my machine is not strong enough to compile any compiler (but
 |pcc, tcc) or even operating systems, i cannot verify) there is
 |only one condition where the stream error indicator is set, after
 |the dumb: label.
 |
 |I would expect the error indicator for a failing __srefill() or
 |__sflush() (only: not following branches), but _here_ it is set
 |for a "long overflow" check failure.  This looks wrong to me, but
 |of course: without having any idea nor test possibilities.  Also
 |note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
 |sees enters 64-bit range?  That also feels wrong, for /dev/null
 |anyway, where it should not matter and simply succeed.  (The
 |tested OpenBSD was 32-bit, too.)

Also, the return of fseek(3) is "int", so testing LONG_MAX looks
a bit odd as such, from my point of view?

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

i wrote:
 |Bryan Drewery  wrote:
 ||On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 ||> I can open a file with "a+", which, for this software, means
 ||> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 ||> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 | ...
 ||> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,037625\
 ||> 2\
 ||> 0) = 3 (0x3)
 ||
 ||Seems to work fine.
 ..
 |locking, so i thought ...  Hmm, this is even more complicated than
 |i thought, wait, i have to debug that.  And: it turns out that
 |a fseek(3) on the descriptor opened not only fails but sets the
 |ferror(3) state of the FILE!  I would need to look into the
 |standard whether this behaviour is correct, but in any case we are
 |not prepared for that, and neither of Linux, Solaris nor OpenBSD
 |enter this condition.

The POSIX standard says that the error condition shall be set if
a read or write error occurs only, but this should not be the case
here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
(note my machine is not strong enough to compile any compiler (but
pcc, tcc) or even operating systems, i cannot verify) there is
only one condition where the stream error indicator is set, after
the dumb: label.

I would expect the error indicator for a failing __srefill() or
__sflush() (only: not following branches), but _here_ it is set
for a "long overflow" check failure.  This looks wrong to me, but
of course: without having any idea nor test possibilities.  Also
note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
sees enters 64-bit range?  That also feels wrong, for /dev/null
anyway, where it should not matter and simply succeed.  (The
tested OpenBSD was 32-bit, too.)

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

Good evening.

Bryan Drewery  wrote:
 |On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 |> I can open a file with "a+", which, for this software, means
 |> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 |> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 ...
 |> # cat uh.c
 |> #include 
 |> #include 
 |> 
 |> int main() {
 |> int fd;
 |> 
 |> fd = open("/dev/null", O_RDWR | O_APPEND | O_CREAT | O_NOFOLLOW);
 |> if (fd == -1)
 |> err(1, "open");
 |> return 0;
 |>}
 |
 |> # truss ./uh
 |...
 |> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,0376252\
 |> 0) = 3 (0x3)
 |
 |Seems to work fine.

Puh. ...  I really looked, logically this codepath should not use
locking, so i thought ...  Hmm, this is even more complicated than
i thought, wait, i have to debug that.  And: it turns out that
a fseek(3) on the descriptor opened not only fails but sets the
ferror(3) state of the FILE!  I would need to look into the
standard whether this behaviour is correct, but in any case we are
not prepared for that, and neither of Linux, Solaris nor OpenBSD
enter this condition.

(What i did is with the MUA i maintain use the rather useless
`write' command which by default writes to /dev/null, this stacks
over c_write()[1] over to save1()[2] which does a lot of stuff,
anyway /dev/null opened via n_fopen_any()[3] to MBOX preparation
call n_folder_mbox_prepare_append()[4] which is defined here[5].
This never made problems yet, but of course i admit it is
a generalization (of several instances of rather identical code in
former versions of this MUA) which is truly bad and will,
hopefully, in a distant future be replaced by a "Mailbox" object
which then has some kind of Mailbox::append() (or prepare_append()
first if anything else fails), and that could act better for some
special files.  Anyway, that not today.)

  [1] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n380
  [2] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n56
  [3] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n145
  [4] https://git.sdaoden.eu/cgit/s-nail.git/tree/cmd-write.c#n168
  [5] https://git.sdaoden.eu/cgit/s-nail.git/tree/folder.c#n900

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Would O_APPEND for /dev/null be possible?

[Bryan Drewery]

On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
> I can open a file with "a+", which, for this software, means
> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
> think only because the VM does not survive resumes and other
> pauses here, which frustrated me over time.  It is old VM.)
> I mean, it seems i have to sprinkle more /dev/null string
> comparisons all over the place, but i wonder whether that really
> belongs there.. for /dev/null?

> # cat uh.c
> #include 
> #include 
> 
> int main() {
> int fd;
> 
> fd = open("/dev/null", O_RDWR | O_APPEND | O_CREAT | O_NOFOLLOW);
> if (fd == -1)
> err(1, "open");
> return 0;
> }

> # truss ./uh
...
> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,03762520) 
> = 3 (0x3)

Seems to work fine.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Would O_APPEND for /dev/null be possible?

[Steffen Nurpmeso]

I can open a file with "a+", which, for this software, means
"O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
think only because the VM does not survive resumes and other
pauses here, which frustrated me over time.  It is old VM.)
I mean, it seems i have to sprinkle more /dev/null string
comparisons all over the place, but i wonder whether that really
belongs there.. for /dev/null?

Well, now that i am here.  I have installed pcc and tcc ports
because clang is much too slow, especially in VM, but they cannot
be used because of mysterious attributes in some system header.
I usually compile them on my own, but that did not help on FreeBSD
too, at least not last time i tried.  This is a bit of a pity,
i have not tried it myself but one of the core developers of the
tiny CC, who was part of ELF development, said, once that
happened, that he made it compile the Linux kernel (!) again and
"that seems to work", so it is a *real* pity that not even rather
primitive C89 user programs can be compiled (with those
compilers).  That on v11.1, and with pkg stuff.

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"