why use fprintf / size_t instead of printf/ int

[G Patel]

E. Robert Tisdale wrote:

int main(int argc, char* argv[]) {
quad_t m = {0, 1, 2, 3};
int r;
fprintf(stdout, "m = (");
for (size_t j = 0; j < 4; ++j)
Why did you declare j as type size_t ?
fprintf(stdout, " %d", m[j]);
fprintf(stdout, ")\n");
WHy did you use fprintf here?
w0(&r, m);
fprintf(stdout, "r = %d\n", r);
return 0;

I'm only asking because I'm one of those people who started out using
functions like gets, strcat, atol and strcpy before being adviced to
use alternatives (fgets, strncat, strtol, and strncpy). Maybe you call
tell me what type of "potential" bug you are trying to prevent by using
fprintf and size_t.

Thanks

Gaya

[E. Robert Tisdale]

G Patel wrote:

E. Robert Tisdale wrote:

int main(int argc, char* argv[]) {
quad_t m = {0, 1, 2, 3};
int r;
fprintf(stdout, "m = (");
for (size_t j = 0; j < 4; ++j)

Why did you declare j as type size_t?

fprintf(stdout, " %d", m[j]);
fprintf(stdout, ")\n");

WHy did you use fprintf here?

w0(&r, m);
fprintf(stdout, "r = %d\n", r);
return 0;

I'm only asking because
I'm one of those people who started out using functions
like gets, strcat, atol and strcpy before being advized
to use alternatives (fgets, strncat, strtol, and strncpy).
Maybe you call tell me what type of "potential" bug
you are trying to prevent by using fprintf and size_t.

Don't look for profound reasoning here.
It's mostly a matter of style.
I use size_t for subscript j and extent n because

0<= j < n

in the declaration of array

int m[n];

I should have written something like:

FILE* myout = stdout;
fprintf(myout, "m = (");
for (size_t j = 0; j < 4; ++j)
fprintf(myout, " %d", m[j]);
fprintf(myout, ")\n");

but I was lazy and
I didn't want to distract attention from the problem at hand.
But this is convenient if, later, I decide that
I really need to redirect this output to a log file for example.

[Jack Klein]

On 25 Jan 2005 19:10:03 -0800, "G Patel" <ga********@gma il.com> wrote
in comp.lang.c:

E. Robert Tisdale wrote:

int main(int argc, char* argv[]) {
quad_t m = {0, 1, 2, 3};
int r;
fprintf(stdout, "m = (");
for (size_t j = 0; j < 4; ++j)
Why did you declare j as type size_t ?

Tisdale is a troll and an idiot. There is absolutely no reason at all
to prefer size_t to int in this situation.

fprintf(stdout, " %d", m[j]);
fprintf(stdout, ")\n");

WHy did you use fprintf here?

Tisdale is still a troll and an idiot. There is absolutely no reason
to prefer fprintf(stdout, /* whatever */) to printf(/* whatever */)
here, or under any circumstances that I can think of off-hand.
Although if there is a case where there is a difference, someone here
will correct me.

There are times when it can be considered reasonable to use
fputs(text_stri ng, stdout) over puts(text_strin g), when you do not,
for some reason, want a '\n' appended and you are otherwise not using
printf().

w0(&r, m);
fprintf(stdout, "r = %d\n", r);
return 0;

I'm only asking because I'm one of those people who started out using
functions like gets, strcat, atol and strcpy before being adviced to
use alternatives (fgets, strncat, strtol, and strncpy). Maybe you call
tell me what type of "potential" bug you are trying to prevent by using
fprintf and size_t.

Thanks

There is nothing wrong with asking the question, if you don't know the
relative reliability of the posters. The best piece of advice you
advice you can gather from this particular exchange is to ignore
Tisdale. Period.

Personally, I have him kill filed, and only see such of his posts as
people like you quote in replies.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Erik de Castro Lopo]

G Patel wrote:

E. Robert Tisdale wrote:

int main(int argc, char* argv[]) {
quad_t m = {0, 1, 2, 3};
int r;
fprintf(stdout, "m = (");
for (size_t j = 0; j < 4; ++j)

Why did you declare j as type size_t ?

fprintf(stdout, " %d", m[j]);
fprintf(stdout, ")\n");

WHy did you use fprintf here?

w0(&r, m);
fprintf(stdout, "r = %d\n", r);
return 0;

I'm only asking because I'm one of those people who started out using
functions like gets, strcat, atol and strcpy before being adviced to
use alternatives (fgets, strncat, strtol, and strncpy). Maybe you call
tell me what type of "potential" bug you are trying to prevent by using
fprintf and size_t.

Tisdale has a lot of strange coding practices. The above is not
wrong, but is definitely not preferable standard C coding
practices.

My suggestion is that you ignore him. At his best he's just a fool,
but its not uncommon for him to be plain wrong.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Being really good at C++ is like being really good at using rocks to
sharpen sticks." -- Thant Tessman

[pete]

Jack Klein wrote:

Why did you declare j as type size_t ?

Tisdale is a troll and an idiot. There is absolutely no reason at all
to prefer size_t to int in this situation.

fprintf(stdout, " %d", m[j]);

size_t is the first type that comes to my mind
when I consider which type to use for an array index.

--
pete

[CBFalconer]

pete wrote:

Jack Klein wrote:

Why did you declare j as type size_t ?

Tisdale is a troll and an idiot. There is absolutely no reason
at all to prefer size_t to int in this situation.

fprintf(stdout, " %d", m[j]);

size_t is the first type that comes to my mind
when I consider which type to use for an array index.

OK, you have rebutted Jacks last assertion. Are you also cavilling
about his other assertions? Also consider that a size_t MAY
require more storage space and processing than an int.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[those who know me have no need of my name]

in comp.lang.c i read:

I'm only asking because I'm one of those people who started out using
functions like gets, strcat, atol and strcpy before being adviced to
use alternatives (fgets, strncat, strtol, and strncpy).

as an aside: i hope someone explained how unsafe strncpy can be, and thus
how to use it semi-safely.

--
a signature

[pete]

CBFalconer wrote:

pete wrote:

Jack Klein wrote:

Why did you declare j as type size_t ?

Tisdale is a troll and an idiot. There is absolutely no reason
at all to prefer size_t to int in this situation.

> fprintf(stdout, " %d", m[j]);
size_t is the first type that comes to my mind
when I consider which type to use for an array index.

OK, you have rebutted Jacks last assertion. Are you also cavilling
about his other assertions?

No, but I want to get off that bandwagon as soon as possible.
Also consider that a size_t MAY
require more storage space and processing than an int.

int is not my first choice to default to
for selecting the type of an array index.
I prefer size_t and my second choice is unsigned.

I know that size_t has the range to index into any array.
I also consider that array index values
are likely to be derived from or compared to
expressions like (sizeof array / sizeof *array)
or expressions involving strlen, which have size_t types.

As far as any speed concerns go, I think that this
particular premature optimization of assuming that size_t
is significantly slower than int, is very premature.
Not worth consider without knowing the performance requirments
and the implementation.

My philosphy on saving memory by using small types
is that it mostly only makes sense for large arrays of small types.
Otherwise a situation, where the difference
between declaring a variable of type long
and declaring a variable of type int,
makes a real difference in the amount of available memory,
would be a very special situation indeed.
In such a situation, I think it would be worth investigating
whether further memory could be saved by using a char type instead.

If I had a special reason to use something instead of size_t
for an array index, then I would. For example, if I wanted
to print out the index values in C89 without using a cast.
But then, I would would still prefer unsigned over int,
to avoid any signed/unsigned mismatch problems from comparison and
assignment operations with sizeof and strlen expressions.

--
pete

[Ben Pfaff]

those who know me have no need of my name <no************ ****@usa.net> writes:

as an aside: i hope someone explained how unsafe strncpy can be, and thus
how to use it semi-safely.

Here's my strncpy() boilerplate:

There is occasionally a good reason to use strncpy(). However:

* Using strncpy() into a large buffer can be very inefficient.
strncpy() always writes to every byte in the destination
buffer, which can waste a lot of time if the destination
buffer is much longer than the source string.

* If the source string is longer than the size of the
destination buffer, then strncpy() doesn't write a
terminating null. So a call to strncpy() must be followed
by explicitly writing a null terminator at the end of the
destination buffer in most cases.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[CBFalconer]

pete wrote:

.... snip ...
I know that size_t has the range to index into any array.
I also consider that array index values
are likely to be derived from or compared to
expressions like (sizeof array / sizeof *array)
or expressions involving strlen, which have size_t types.

As far as any speed concerns go, I think that this
particular premature optimization of assuming that size_t
is significantly slower than int, is very premature.
Not worth consider without knowing the performance requirments
and the implementation.

Of course the proper way is to specify the range required for the
index variable, and let the compiler use that to select the optimal
storage. Pascal does this. In C we only have the option of
selecting something that is big enough. However, surely when we
write:

for (i = 0; i < 4; i++) ....

we have a good idea that i should never have values outside of
1..3, and knowing that int can cover this range, and is the most
efficiently handled integral type, we should have very few qualms
about selecting it as the index type.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson