Re: Built-in printf Sits Awkwardly with UDP.
Hi André, > > When printf is finished the buffer is flushed, e.g. if there's > > anything in it then write(2) is called. > > If standard output is a log file, log entries could remain latent for > a very long time. I don't see why. I'm not asking for buffering across multiple calls to the built-in printf but for non-line buffering *within* the processing of one printf. printf 'foo\nbar\n' # One write(2) preferred, not the current two. printf foo # One write(1), printf bar # the second write(1). The stdio buffer should always be flushed at the end of each printf command, to do otherwise would break too many things and be non-sensical. It also wouldn't match the behaviour of calling the /usr/bin printf. Cheers, Ralph. P.S. Please keep me CC'd.
Re: Built-in printf Sits Awkwardly with UDP.
> OK, well for %b and %q bash's built-in printf calls it's own > printstr() and that does do things like `fw = -fw' without checking if > fw was already the largest negative. On a related note, I can't interrupt this, e.g. Ctrl-C. printf '%-92233720368547758q.\n' foo Cheers, Ralph. P.S. Please keep me CC'd.
Re: bug#9129: Built-in printf Sits Awkwardly with UDP.
retitle 9129 printf: RFE: reject field width larger than INT_MAX tags 9129 notabug thanks Eric Blake wrote: > [adding coreutils] > > On 07/20/2011 07:34 AM, Ralph Corderoy wrote: >> BTW, the code for the built-in printf has a bug. For negative >> field-widths it negates a negative integer without checking it will fit. >> E.g. on this 64-bit machine >> >> $ printf '%-9223372036854775808s.\n' foo >> foo. >> $ > > Coreutils' printf shares this misfortune. Sadly, it might even be a > bug in the underlying glibc printf(), although I haven't tried to > write a test program to check that, yet. This is not about a negative field width. You can induce misbehavior without the "-". The "-" is just the left-alignment option. Compare these: $ printf '_%2s_\n' o _ o_ $ printf '_%-2s_\n' o _o _ The trouble is that whenever you specify a field width larger than INT_MAX, you enter into unspecified (or was it undefined?) territory. Applications like printf or bash's built-in printf should be able to detect and diagnose such questionable inputs before passing the offending directive to an underlying *printf function. I've marked this "not a bug" but have left the ticket open, since I see it as a reasonable request for improvement.
Re: bug#9129: Built-in printf Sits Awkwardly with UDP.
Hi Jim, > > On 07/20/2011 07:34 AM, Ralph Corderoy wrote: > > > BTW, the code for the built-in printf has a bug. For negative > > > field-widths it negates a negative integer without checking it > > > will fit. E.g. on this 64-bit machine > > > > > > $ printf '%-9223372036854775808s.\n' foo > > > foo. > > > $ > > > > Coreutils' printf shares this misfortune. Sadly, it might even be a > > bug in the underlying glibc printf(), although I haven't tried to > > write a test program to check that, yet. > > This is not about a negative field width. Just to ensure there's no confusion, as far as bash's built-in printf is concerned one aspect of it is about a negative field width since $ printf '.%*q.\n' -10 foo .foo . is implemented by converting the "-10" into a number, spotting it's negative, setting the left-justified flag, and then negating the number. Coreutils' printf doesn't have that particular issue since it passes the negative number to the C library as a negative and has it deal with the justification change. For %b, which libc doesn't support, coreutils says /* FIXME: Field width and precision are not supported for %b, even though POSIX requires it. */ so there's no code to go wrong. :-) Cheers, Ralph.
sorry--this is my question
is this a bug? > echo goodbye\ cruel\ world\! goodbye cruel world! > echo "goodbye cruel world!" bash: !": event not found > echo "goodbye cruel world\!" goodbye cruel world\!
