Re: [9fans] weird print(2) problems...

[Dan Cross <cross@math.psu.edu>]

In article <20010905150808.1FC2619A32@mail.cse.psu.edu> you write:
>>>that if write(2) sees a zero length argument, it should consider that a
>>>nop and return.  But then it seems that that would break some weird
>>>semantic somewhere (``Any write will update a timestamp; except for
>>>zero length writes, which are ignored.'' ``Dude, that's broken.'')
>
>it isn't only the possible effect on time stamps; i think it
>should do a write 0 because it's what you said to do.

Yes, that's what I mean by ``breaking some weird semantic''  (although
the semantic isn't that weird).  The timestamp thing was just a contrived
example.

>to be fair, it's disguised by print, but even so,
>if i wanted nop() i'd use
>	;
>or
>	void nop(void){}
>but i wouldn't call write() or even print.  i'd call write() when i wanted
>to write, and i prefer systems that do what i tell it, so that if i say
>`write 0 bytes' i expect it to do that, rather than adding yet
>more special cases to remember.

I don't disagree, but the behavior I've observed is demonstrably broken.

I'm looking for a fix to the system so that the guy writing a program
doesn't have to worry if he's accidentally printing out a blank string;
that's the special case I want to avoid.

After all, if I write zero bytes, I don't expect the program on the
other end of my pipe to stop reading all of a sudden.

>  the effect of writing 0 bytes
>is determined by the device, but that's true of writing 1 byte or many,
>so there's no difference there.

Yes there is.  When the program I'm piping to reads zero bytes, it stops
reading.  If it reads n > 0 bytes, it does not.

>on the other hand, i'd probably write
>	if(*str)
>		print("%s", str);
>if that's what i wanted.

Sure, that's how I fixed the program at hand (which generates morse
code, btw).

But isn't this also a special case I now need to remember?  Worse I
have to remember it when writing user level programs; the complexity
of it (granted, not much) isn't hidden from me.  It's a bummer;
surely there's an elegant solution to this problem.

	- Dan C.