Re: rethinking printf
Rich Morin wrote:
At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
I also like this because it allows a typical format string to be
converted
merely by adding a two-character prefix:
printf(The value is %7.2f\n, $foo);
---
printf(qnThe value is %7.2f\n, $foo);
-r
if qf() is defensible, it should pass some generality tests;
1. make it 'replace' printf
print qf'%s %d', $somestring, $someint;
2. make it 'replace' sprintf.
$res = qf('%s %d %d', $somestr, $anint)
3. detect the silent error above - insufficient args.
this quote-like operator is now a list-op, and a smart one.
4. make it know whether %s means hash interpolation or printf-format-spec
a. ive seen perl5 warn about escaping when printing undefined / undeclared
array (cant seem to replicate now :-/ )
b. the universe of printf format specs is pretty small, it really only
interferes
with (the expansion of: {[ each %s ]} ) a few single letter hashes %s,
%d, etc..
c. item b implies a run-time check to see that no %s, %d, are hidden by
a format-spec
interpretation, but that is excessive; a comment in `perldoc -f printf`
would address
that rather fully.
Re: rethinking printf
Quoting Uri Guttman ([EMAIL PROTECTED]):
and interpolating $foo in a format is useful so that is not stopped. i
have used it for format precision values. i recently discovered that
perl still supports the c style of * meaning to use the next arg for the
precision/width value. i much prefer interpolating that where it belongs
instead of matching more args up with format specifiers.
Interpolating into format strings is well known for causing bugs. Although
the security implications are less serious in Perl than C, it's still a
robustness problem.
In my opinion, any fix that introduces noise into printf is unacceptable. I
get the impression that the people who think this is a non-issue never use
printf. I do, and I use strftime on an almost daily basis.
I could live with doing strftime('%Y-%m-%d', localtime), though I'd have to
stop and think about it every time. When it comes to printf though, embedded
newlines are vital, and printf('%11d %11d %s'.\n, @a) and the other wacky
varients are just not gonna cut it. If I wanted to spend all day battling
quoting issues I'd program in shell.
I think there are only three possible solutions:
* An argument type that magically changes the interpolation conventions for
strings. Perl already has a bunch of argument types that do weird
compile-time things, so it wouldn't be unprecedented, and people could
continue to use printf, sprintf, strftime and my_printf as now.
* Throw out printf and write, and replace them with a new formatted-output
facility. It would have to seriously kick ass as compensation for forcing
everyone to learn it.
* Continue to use Perl 5 while we still have the freedom to do so.
Adam
--
Adam Rice -- [EMAIL PROTECTED] -- Blackburn, Lancashire, England
Re: rethinking printf
a == abigail [EMAIL PROTECTED] writes:
a On Wed, Mar 06, 2002 at 11:15:30PM -0500, Uri Guttman wrote:
good point. $() can still wrap that but then there has to be a balance
between printf strings and double quoters. how about this wacky idea:
make a new type of string where %foo{bar} is not interpolated by
default. maybe something in the q/qq family could be added like qn for
no hash interpolation. you can use $() to still force it if you need to
in printf formats.
a I'd think it would be much better that '%' followed by a word *not*
a followed by a { isn't interpolated. Granted, you cannot do
a interpolation of hashes (well, one could always write @{[%hash]},
a just like in perl5, and there's little change of clashing with
a printf formats. There's only a clash if a format specifier is
a followed by a brace.
i already covered how @() and $() will allow interpolation of full
hashes so the hack @{[]} is not needed there or in fact anywhere.
a But the way perl6 is going, I doubt we'll see this kind of DWIM; perl6
a is going more in the way of a bondage and discipline language.
i disagree. but we shall see if larry is listening to this thread and
will back away from hash interpolation or take some of our suggestions
that make it work without killing format strings. i hate to see a
special call or wierd syntax for that. my qn (or qf) suggestion seems to
have some backing and it is clean and unobtrusive.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
Lines: 17
In article [EMAIL PROTECTED],
Uri Guttman [EMAIL PROTECTED] wrote:
i disagree. but we shall see if larry is listening to this thread and
will back away from hash interpolation or take some of our suggestions
that make it work without killing format strings. i hate to see a
special call or wierd syntax for that. my qn (or qf) suggestion seems to
have some backing and it is clean and unobtrusive.
If you are going to make a special q form for sprintf strings, don't
make it just skip hash interpolation. Make it treat [@$%] all as
literals and only process backslashed thingies (including \qq of
course). If you want to interpolate a $foo in an printf format, use
%s.
The idea of interpolating %foo{bar} but not %foo seems unnecessarily
complicating.
RE: rethinking printf
Uri Guttman:
# i disagree. but we shall see if larry is listening to this thread and
# will back away from hash interpolation or take some of our suggestions
# that make it work without killing format strings. i hate to see a
# special call or wierd syntax for that. my qn (or qf)
# suggestion seems to
# have some backing and it is clean and unobtrusive.
I think qn counts as weird syntax. I ask again, what's wrong with one
of:
sprintf(%hash\%s, $string);
sprintf(%hash.'%s', $string);
sprintf('%s%s', _%hash, $string);
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
RE: rethinking printf
Abigail:
# I'd think it would be much better that '%' followed by a word *not*
# followed by a { isn't interpolated. Granted, you cannot do
# interpolation
# of hashes (well, one could always write @{[%hash]}, just
# like in perl5,
# and there's little change of clashing with printf formats.
# There's only
# a clash if a format specifier is followed by a brace.
There's only a clash if you double-quote the format string anyway, which
is a rare thing to need to do at all.
# But the way perl6 is going, I doubt we'll see this kind of DWIM; perl6
# is going more in the way of a bondage and discipline language.
It's more like Perl 6 is removing many inconsistencies. This
particular case isn't incredibly different from the changes in the
precedence of open() between Perls 4 and 5. (For those who don't
remember this or haven't read about it somewhere, open() was once a
hybrid unary and list operator, so open FOO, 'bar' || die; worked.) A
minor adjustment in either the language or the user's usage was all that
was necessary to avoid problems with the change
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
In article [EMAIL PROTECTED], Brent Dax [EMAIL PROTECTED] wrote: There's only a clash if you double-quote the format string anyway, which is a rare thing to need to do at all. I'd expect that a hefty percentage of format strings have a \n.
Re: rethinking printf
Earlier, I mentioned the idea of replacing overly complicated
printfs with a print and some f function calls, as:
{
$a=1828;
$b=45;
print f(pi=%8.6f, ,355/113),
f(e=2.7$a$a$b%d$b\n, $b*2);
}
Now, f is really just shorthand for sprintf, but creating f
was a bit trickier than I'd have thought. FWIW, here's something
that works:
sub f { sprintf(shift(@_), @_); }
-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm- my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: rethinking printf
YS == Yitzchak Scott-Thoennes [EMAIL PROTECTED] writes:
YS Uri Guttman [EMAIL PROTECTED] wrote:
i disagree. but we shall see if larry is listening to this thread and
will back away from hash interpolation or take some of our suggestions
that make it work without killing format strings. i hate to see a
special call or wierd syntax for that. my qn (or qf) suggestion seems to
have some backing and it is clean and unobtrusive.
YS If you are going to make a special q form for sprintf strings, don't
YS make it just skip hash interpolation. Make it treat [@$%] all as
YS literals and only process backslashed thingies (including \qq of
YS course). If you want to interpolate a $foo in an printf format, use
YS %s.
YS The idea of interpolating %foo{bar} but not %foo seems unnecessarily
YS complicating.
but if you just disallow all direct % interpolations you can use $() or
@() to get them. now, how often have you created a format string with a
value from a hash? it is done sometimes but not nearly as often as using
%s so the $()/@() wrapper cost is low in both characters and mindspace.
and interpolating $foo in a format is useful so that is not stopped. i
have used it for format precision values. i recently discovered that
perl still supports the c style of * meaning to use the next arg for the
precision/width value. i much prefer interpolating that where it belongs
instead of matching more args up with format specifiers.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
BD == Brent Dax [EMAIL PROTECTED] writes:
BD I think qn counts as weird syntax. I ask again, what's wrong with one
BD of:
BD sprintf(%hash\%s, $string);
BD sprintf(%hash.'%s', $string);
BD sprintf('%s%s', _%hash, $string);
what if you want to use %hash{width} as a field precision? i don't like
the idea that all format specifiers would be the noisy \%s. they are
much more common than using hashes in format strings. now as i said in
another post, you can use the * method but i never liked it. in c it was
the only decent solution to dynamic precisions (other than doing a
sprint of the format string itself which loses). in perl, interpolation
makes that easier but i have rarely seen hashes used in that way. a temp
variable is as good a solution for that too.
$prec = %hash{width} ;
sprintf( qf%${prec}s, $string);
sprintf( \%${prec}s, $string);
is one of your alternatives. :-/
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
Why not replace the escape character '%' with '#'? No new quoting operators or functions to learn. And introduce a warning if there are no #'s in the format string. Eugene
RE: rethinking printf
Uri Guttman:
# BD == Brent Dax [EMAIL PROTECTED] writes:
#
# BD I think qn counts as weird syntax. I ask again, what's
# wrong with one
# BD of:
#
# BD sprintf(%hash\%s, $string);
#
# BD sprintf(%hash.'%s', $string);
# BD sprintf('%s%s', _%hash, $string);
#
# what if you want to use %hash{width} as a field precision? i
# don't like
# the idea that all format specifiers would be the noisy \%s. they are
# much more common than using hashes in format strings. now as i said in
# another post, you can use the * method but i never liked it.
# in c it was
# the only decent solution to dynamic precisions (other than doing a
# sprint of the format string itself which loses). in perl,
# interpolation
# makes that easier but i have rarely seen hashes used in that
# way. a temp
# variable is as good a solution for that too.
#
# $prec = %hash{width} ;
# sprintf( qf%${prec}s, $string);
#
# sprintf( \%${prec}s, $string);
#
# is one of your alternatives. :-/
You forgot one.
sprintf('%'_%hash{width}_'s', $string);
Not horribly pretty, true, but not bad enough to justify writing a
quoting hack into the language. (And yes, I do consider 'qf' a quoting
hack.)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
BD == Brent Dax [EMAIL PROTECTED] writes:
BD Uri Guttman:
BD # $prec = %hash{width} ;
BD # sprintf( qf%${prec}s, $string);
BD #
BD # sprintf( \%${prec}s, $string);
BD #
BD # is one of your alternatives. :-/
BD You forgot one.
BD sprintf('%'_%hash{width}_'s', $string);
BD Not horribly pretty, true, but not bad enough to justify writing a
BD quoting hack into the language. (And yes, I do consider 'qf' a
BD quoting hack.)
but it fits into the q family well. the above code looks more like a
hack (as you say it is not pretty). anyhow we haven't heard from larry
on this yet since we heard the reports of printf issues. i will drop it
for now as my flavor is out there along with the others.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote: i really think that the printf format spec is so standard and ingrained that changing it with # for % or requiring \% is not a good idea. but then again, backwards compatibility is not a rule you must always obey. i just think in this case it should be. Especially as this is a case in which the functionality itself is not broken, and not itself under review, but rather that a seemingly unrelated proposed change to another part of the language is in effect breaking printf. If the printf formats were to be changed simply to accommodate other changes elsewhere, then they should really be looked at more generally: what would people like to get out of them, before we break them? But even then, backwards compatibility would be nice... Ian Boreham
Re: rethinking printf
Listmom tries to keep this a self-moderating list, but alas, Listmom has had a complaint. This thread started out as fun (How Would YOU Do It? is an acceptable topic for FWP) but has become more meta discussion and less fun with Perl. Please move any further design to [EMAIL PROTECTED] Thanks. -- - Vicki Vicki Brown ZZZ Journeyman Sourceror: P.O. Box 1269 zz |\ _,,,---,,_Scripts Philtres San Bruno, CA zz /,`.-'`'-. ;-;;,_ Perl, Unix, MacOS 94066 USA |,4- ) )-,_. ,\ ( `'-' mailto:[EMAIL PROTECTED] '---''(_/--' `-'\_) http://www.cfcl.com/~vlb
Re: rethinking printf
[EMAIL PROTECTED] wrote: why not qf for format strings then For some reason, I thought Schwern would be the one to suggest a queef operator ;) -matt PS: that may be a US-specific bit of slang http://google.com/search?q=a+queef+is;
Re: rethinking printf
Rich == Rich Morin [EMAIL PROTECTED] writes: Rich This seems pretty ugly to me (Randal didn't like it much either :-) Yup. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: rethinking printf
On Wed, Mar 06, 2002 at 09:45:18AM -0800, Rich Morin wrote:
He
suggested, when asked, that folks could put in newlines as follows:
'yada yada yada \qq{\n}'
I meant to add this in last time: There is also the option of having an
additional function that adds the newline in, e.g. WriteLine() v.
Write() as seen in many other languages (Pascal et al, Java, etc). I've
never really liked this but on the other hand, it seems the lesser of
two evils.
\qq{\n} as a newline strikes me as a joke. Was it profferred in jest?
Paul
--
Paul Makepeace ... http://paulm.com/
If we could fly to the moon, then monkies would be green.
-- http://paulm.com/toys/surrealism/
Re: rethinking printf
BC == Bernie Cosell [EMAIL PROTECTED] writes:
cced perl6-language
BC I wonder if the solution is to look at it the other way: that you
BC have to do something to get interpolation to happen. If we look
BC at it from the old adage of making the more common things simpler,
BC at least in my code I very rarely interpolate arrays [and I
BC suspect I'd even LESS often interpolate hashes], I wouldn't mind
BC the syntax going the other way -- maybe @ never interpolates and
BC you need to do \@ to make interpolation happen [and then
BC similarly with '%']... This is also simlar to the logic behind
BC Perl's reversing the longstanding unix convention WRT to chars
BC like '(' in REs.
that is a good idea. the @() and $() things will interplate any
expressions into strings. so use a method on the hash to get a string
out and wrap it in $().
printf %d hash is $(%foo.string), $bar ;
no ambiguity and no confusion. how often will you need to interpolate a
hash? so make it more cumbersome as it is a rare thing. that is larry's
credo from way back. breaking % in a s/printf format is not good as that
is the very common thing to do.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
how often will you need to interpolate a hash?
A whole hash: quite rarely. A hash item: a LOT. Don't forget that
$foo{BAR} will now become %foo{BAR}
--
Bart.
RE: rethinking printf
Uri Guttman:
# printf %d hash is $(%foo.string), $bar ;
#
# no ambiguity and no confusion. how often will you need to
# interpolate a
# hash?
As others have pointed out, %foo{BAR} has to work. But I have another
question for you: what's wrong with
sprintf '%d hash is %s', $bar, %foo;
? After all, interpolating into an sprintf is a bit dangerous anyway
(what if %foo=('%d' = '')?), and you avoid special cases.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: rethinking printf
In article p05100339b8abfb25cfdf@[192.168.254.205], Rich Morin [EMAIL PROTECTED] wrote: Note that I'm suggesting a new function name because printf has a little-used capability that could conflict with my proposed syntax: The format string is reused as often as necessary to satisfy the arguments. Where did you get that? Not true for Perl or C.
Re: rethinking printf
BD == Brent Dax [EMAIL PROTECTED] writes:
BD Uri Guttman:
BD # printf %d hash is $(%foo.string), $bar ;
BD #
BD # no ambiguity and no confusion. how often will you need to
BD # interpolate a
BD # hash?
BD As others have pointed out, %foo{BAR} has to work. But I have another
BD question for you: what's wrong with
BD sprintf '%d hash is %s', $bar, %foo;
that is fine but if you want the format string to use %foo{bar} then you
need double quotes. the problem is deciding when to allow that and to
not make %s become broken. i proposed a possible solution in my previous
post. maybe it won't fall on deaf ears. :)
BD ? After all, interpolating into an sprintf is a bit dangerous anyway
BD (what if %foo=('%d' = '')?), and you avoid special cases.
that is another point. not allowing a complete hash to interpolate. but
what defines that? what if you wanted %s{bar} and that was a format and
not a hash and in a double quoted string? my proposal handles that well
with no major noise factors. qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: rethinking printf
At 5:27 PM -0800 3/6/02, Yitzchak Scott-Thoennes wrote: The format string is reused as often as necessary to satisfy the arguments. Where did you get that? Not true for Perl or C. Apparently, when I did a man printf, I got the one in FreeBSD's Section 1: PRINTF(1) FreeBSD General Commands Manual PRINTF(1) NAME printf - formatted output SYNOPSIS printf format [arguments ...] DESCRIPTION Printf formats and prints its arguments, after the first, under control of the format. The format is a character string which contains three types of objects: plain characters, which are simply copied to standard output, character escape sequences which are converted and copied to the standard output, and format specifications, each of which causes printing of the next successive argument. The arguments after the first are treated as strings if the corresponding format is either c or s; otherwise it is evaluated as a C constant, with the following extensions: o A leading plus or minus sign is allowed. o If the leading character is a single or double quote, or not a digit, plus, or minus sign, the value is the ASCII code of the next character. The format string is reused as often as necessary to satisfy the arguments. Any extra format specifications are evaluated with zero or the null string. ... I also think Fortran FORMAT statements acted this way, but it's been far too long for me to remember for sure... In any case, it seems that it isn't a problem... -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: rethinking printf
At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
I also like this because it allows a typical format string to be converted
merely by adding a two-character prefix:
printf(The value is %7.2f\n, $foo);
---
printf(qnThe value is %7.2f\n, $foo);
-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm- my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: rethinking printf
On Wed, Mar 06, 2002 at 11:24:57PM -0500, Uri Guttman wrote:
that is another point. not allowing a complete hash to interpolate. but
what defines that? what if you wanted %s{bar} and that was a format and
not a hash and in a double quoted string? my proposal handles that well
with no major noise factors. qn would be just like qq but not allow any
direct hash interpolations (%foo or %foo{bar}). you can always get those
with $() if needed. this solves the common case with a minimal of noise
and the uncommon case has a simple out of using $(). no need for wacko
ways to put in \n. it is double quotish in all ways but one and mainly
to be used for printf format strings.
why not qf for format strings then?
s/(printf)/\1 qf/g
Re: rethinking printf
On Wed, Mar 06, 2002 at 08:56:18PM -0800, Yitzchak Scott-Thoennes wrote:
Apparently, when I did a man printf, I got the one in FreeBSD's Section 1:
The format string is reused as often as necessary to satisfy the
arguments. Any extra format specifications are evaluated with zero or
the null string.
Thats funky.
this is section *1* manual, for commands, right?
It's possible that printf *program* does that, but that's really weird.
(yes, indeed: printf(1) FreeBSD 3.5, Linux 2.2.14, and SunOS 5.8 aka Solaris 8
are
documented and work this way.)
POSIX (IEEE 1003.1-2001) says:
If the format is exhausted while arguments remain, the excess
arguments shall be evaluated but are otherwise ignored.
And C99 (ISO 9899-1999 section 7.19.6.1) says:
If the format is exhausted while arguments remain, the excess
arguments are evaluated (as always) but are otherwise ignored.
Does it in fact reuse the format on your system?
If one remembers how C argument passing convention works on assembly level (and
different from Pascal conversion for example), it is that arguments are pushed
to stack by caller, last to first, then subroutine is called, and stack popped
(possibly
delayed or combined with another stack operation down the road.) Therefore,
it is impossible for called function to know number of arguments it has passed.
(Unless printf() is implemented in the language compiler.)
For example, the following program (pardon terse style):
#include stdio.h
#define NARGS 10
int main() {
int i; int n[NARGS];
for (i = 0; i NARGS; i++) { n[i] = i; }
printf(%d,\n, n[0], n[1], n[2], n[3]);
return 0;
}
produces the following output:
0,
and compiles to the following code, which does not pass 4 as number of
non-format arguments to printf at any way:
.file test-printf.c
.version01.01
gcc2_compiled.:
..section.rodata
..LC0:
.ascii %d,\12\0
..text
.p2align 2
..globl main
.typemain,function
main:
pushl %ebp
movl %esp,%ebp
subl $40,%esp
xorl %eax,%eax
.p2align 2,0x90
..L9:
movl %eax,-40(%ebp,%eax,4)
incl %eax
cmpl $9,%eax
jle .L9
pushl -28(%ebp)
pushl -32(%ebp)
pushl -36(%ebp)
pushl -40(%ebp)
pushl $.LC0
call printf
xorl %eax,%eax
leave
ret
..Lfe1:
.sizemain,.Lfe1-main
.ident GCC: (GNU) 2.7.2.3
Re: rethinking printf
Paul Makepeace [EMAIL PROTECTED] writes:
On Wed, Mar 06, 2002 at 09:45:18AM -0800, Rich Morin wrote:
He
suggested, when asked, that folks could put in newlines as follows:
'yada yada yada \qq{\n}'
I meant to add this in last time: There is also the option of having an
additional function that adds the newline in, e.g. WriteLine() v.
Write() as seen in many other languages (Pascal et al, Java, etc). I've
never really liked this but on the other hand, it seems the lesser of
two evils.
printf(%s\n %s\n%s\n, @haiku_line[0,1,2]);
--
Ariel Scolnicov|http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]
72 Pinhas Rosen St.|Tel: +972-3-7658117 fast, good, and cheap;
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 pick any two!
