Safely working out how many rows in an array?

[Malcolm]

Many thanks all.

I curious why people prefer a size_t instead of int? On my PC, a quick
sizeof shows both are same size, though that could be down the the %d
in prinft("%d", sizeof(tSize_t))

It's an uglifiaction of the langauge to get round the largely theoretical
problem, what if a memory object is larger than the range of an int?

 

[Chris Torek]

[size_t is] an uglifiaction of the langauge to get round the
largely theoretical problem, what if a memory object is larger
than the range of an int?

Hardly "theoretical", since this is in fact the case on Solaris
on SPARC, MIPS, and Intel x86-64, to name three.

 

[Bill Reid]

Other examples:
strlen() returns size_t
malloc()'s parameter is of type size_t

So what's the deal about using say, an unsigned long (which is
what I usually use for data sizes) with parameters that are declared
as size_t?

Reason I ask is I was just fooling around with fread() and
fwrite(), using the same old unsigned longs that I always use
as data sizes, as the size of the elements to read and write.

The puzzling results: fread() works just fine, fwrite() blows
up and causes an exception, and writes extraneous garbage at
the end of the new file, UNTIL I deliberately declare an extra
size_t variable just to assign the existing unsigned long so I can
use THAT as the parameter.

Wazzup wid dat? I don't ever remember seeing something
like that before...

 

[Ian Collins]

So what's the deal about using say, an unsigned long (which is
what I usually use for data sizes) with parameters that are declared
as size_t?

Reason I ask is I was just fooling around with fread() and
fwrite(), using the same old unsigned longs that I always use
as data sizes, as the size of the elements to read and write.

The puzzling results: fread() works just fine, fwrite() blows
up and causes an exception, and writes extraneous garbage at
the end of the new file, UNTIL I deliberately declare an extra
size_t variable just to assign the existing unsigned long so I can
use THAT as the parameter.

Example please, it shouldn't matter, you can pass unsigned char to
fwrite (as long as the size fits) and it will be promoted to whatever
type size_t is. Odds are your system uses unsigned long for size_t.

 

[Keith Thompson]

So what's the deal about using say, an unsigned long (which is
what I usually use for data sizes) with parameters that are declared
as size_t?

If a prototype is in scope (which usually just means that you have a
"#include" for the appropriate header), this shouldn't be a problem,
as long as the value is within the range of both unsigned long and
size_t. The compiler knows the type of the argument expression
(unsigned long) and the type of the parameter (size_t), and provides
an implicit conversion if it's needed.

(If you *don't* have a prototype in scope, then you'll likely invoke
undefined behavior as soon as you call the function. Don't do that.)

Reason I ask is I was just fooling around with fread() and
fwrite(), using the same old unsigned longs that I always use
as data sizes, as the size of the elements to read and write.

The puzzling results: fread() works just fine, fwrite() blows
up and causes an exception, and writes extraneous garbage at
the end of the new file, UNTIL I deliberately declare an extra
size_t variable just to assign the existing unsigned long so I can
use THAT as the parameter.

My best guess is that you're missing the required "#include
<stdio.h>". If so, you should do (at least) two things: add the
"#include <stdio.h>", and learn how to invoke your compiler so it
warns you about errors like this.

Beyond that, it's impossible to guess what's happening without seeing
some actual code.

 

[Bill Reid]

Example please, it shouldn't matter, you can pass unsigned char to
fwrite (as long as the size fits) and it will be promoted to whatever
type size_t is. Odds are your system uses unsigned long for size_t.

I believe it uses unsigned int which is the same 32 bits used for
unsigned long (and short too I think!). I keep using long because
I can't help but believe that long is a bigger number...

I'm not giving an example because I figured out what I was doing
wrong and man is my face red...I may describe it in another post,
but the actual code, NEVER!

 

[Bill Reid]

If a prototype is in scope (which usually just means that you have a
"#include" for the appropriate header), this shouldn't be a problem,
as long as the value is within the range of both unsigned long and
size_t. The compiler knows the type of the argument expression
(unsigned long) and the type of the parameter (size_t), and provides
an implicit conversion if it's needed.

Yeah, it was never a problem before, but you know...

"There can be only one possible explanation. It must be due to human
error. These kinds of things have cropped up before, and it was always
due to human error."

(If you *don't* have a prototype in scope, then you'll likely invoke
undefined behavior as soon as you call the function. Don't do that.)


My best guess is that you're missing the required "#include
<stdio.h>". If so, you should do (at least) two things: add the
"#include <stdio.h>", and learn how to invoke your compiler so it
warns you about errors like this.

Nope...

"I think you missed it."

Beyond that, it's impossible to guess what's happening without seeing
some actual code.

Not gonna happen, I figured out what the problem was. I was
stupidly free()ing the entire structure and associated text editor buffer
before writing it to the file. Strangely, that didn't seem to affect the
text in the buffer at all, but somehow goofed up the part of the
structure with the buffer size.

So it's all fixed now and works fine...just remember in the future that
when I ask a really stupid question, I'll probably figure it out myself on
my own in a week or so...

 

[Christopher Layne]

I believe it uses unsigned int which is the same 32 bits used for
unsigned long (and short too I think!). I keep using long because
I can't help but believe that long is a bigger number...

If you need an integer type for "sizes" or "lengths" start using size_t. Then
the issue of "is long, long enough?" becomes a non-issue. This is a reason
why size_t exists.