Printable View
Hi, I'm totally not using type of data size_t but I've seen many developers are using it, my question is, when we use size_t? and what's about? I've searched in google, I found it's like integers but not defined in advance .., may anyone please explain to me what's size_t by an example? thanks alot.
There you go.Quote:
SYNOPSIS
#include <string.h>
size_t strlen(const char *s);
Use strlen() in a program, and you're using a size_t.
Generally its root include is stddef.h I think, its usage is just to ensure you don't try to allocate more than the system permits, for example most systems will map this to unsigned long which means you only be able allocate at most ULONG_MAX bytes per call to malloc (malloc.h), 16bit systems will map this to unsigned short normally (USHORT_MAX) and 64bit systems will normally map this to either unsigned long long (ULLONG_MAX) or unsigned long depending on whether long is mapped to 64bit word or not, there are situations where size_t maps to something smaller than what the system can handle, for example 16bit software running on 32/64bit systems and likewise 32bit on 64bit systems (note you cannot go in reverse), there's also when libraries map it to something smaller before inludeing stddef.h (whether it be directly included or indirectly), for printing the value the most portable way would be to cast it to the largest size your compiler supports (typically unsigned long long nowadays) and feed the appropriate modifier to printf etc (%llu)Quote:
Originally Posted by RyanC
A cast is unnecessary; just use %zu with the printf family. Of course, you might argue that this is not as portable, but then if your compiler's standard library implementation doesn't support %zu, it probably doesn't support %llu either, so you should cast to unsigned long and use %lu with the idea that it is improbable that the size_t value would exceed the max unsigned long value.Quote:
Originally Posted by awsdert
I said most PORTABLE way, not the BEST way, at least when casting you avoid the issue of some random c library not supporting %zu, I agree that in most cases %zu is preferable but its always nice to know the workaround if one does encounter the scenario that they need itQuote:
Originally Posted by laserlight
Read my edit. The most portable way certainly doesn't involve using unsigned long long with %llu: those were standardised at the same time as %zu for size_t.Quote:
Originally Posted by awsdert
EDIT:
Assuming we're compiling with respect to C99 or later, %zu is the most portable way since "the largest size your compiler supports" is not necessarily the largest size my compiler supports.
That assumes your compiling printf and co, but in the case that your not (which most people will go with) the linux the system library that string.h etc map will definitly support %zu but I'm thinking varieties of windows and homebrew apps for older consoles such as playstation 2 or xbox or nintendo64 etc, windows in particular is extremely annoying to use sometimes, as for largest size another compiler supports so far the best way would simply be int_least64_t from stdint.h I supposeQuote:
Originally Posted by laserlight
I called you out on not suggesting %zu because you suggested %llu: if you were really thinking about those, then unsigned long long and %llu would be a strange suggestion, e.g., on older Windows you might have to use %I64u. Then there's the thing about some extant systems still being 32 bit. Honestly, I'm inclined to say that if you need to worry about legacy systems, don't worry about being portable: cater to the legacy systems as needed, e.g., through conditional compilation.Quote:
Originally Posted by awsdert
Nope. <stdint.h> was introduced in C99: if you want to be so portable that %zu is a concern, then you cannot #include <stdint.h>Quote:
Originally Posted by awsdert
So if I understand you well, we are using size_t since we know that we know that the variable which its type size_t will be just integer like length etc ?! , in the same time we can use size_t as "integer" int .. ye?Quote:
Originally Posted by Salem
size_t is guaranteed to be an unsigned integer type. It is defined as the type of the result of the sizeof operator.
Well then what do you suggest as a fallback?Quote:
Originally Posted by laserlight
Just use %zu. If you must handle legacy systems, use conditional compilation to handle them on a case by case basis, e.g., check the macro for standard C version, check if the macro for max unsigned long long value exists, OS specific macros, etc. Based on these, conditionally compile different versions of the code, e.g., %zu, %llu with cast, %lu with cast, %I64u, etc. (I suggested just using %lu with cast earlier, but in retrospect that isn't as good as conditional compilation if you want to be portable.)Quote:
Originally Posted by awsdert
Ironically, if portability wasn't a concern, then you could effectively do it the way it was done pre-C99: use %zu if your compiler supports it, otherwise "cast it to the largest size your compiler supports (typically unsigned long long nowadays) and feed the appropriate modifier to printf etc (%llu)", i.e., your suggestion is a good fallback, but it isn't portable precisely because you're suggesting people choose according to their compilers.
So I was right:
Would work just fineCode:#ifdef ULLONG_MAX
#define PRI_CAST_SIZE_T_TEXT "llu"
#define PRI_CAST_SIZE_T unsigned long long
#define SCN_CAST_SIZE_T_TEXT "hu"
#define SCN_CAST_SIZE_T_REF unsigned short *
#else
#define PRI_CAST_SIZE_T_TEXT "lu"
#define PRI_CAST_SIZE_T unsigned long
#define SCN_CAST_SIZE_T_TEXT "hu"
#define SCN_CAST_SIZE_T_REF unsigned short *
#endif
Ignoring the issue of %I64u on the older MSVCRT, yes: you're effectively replicating what %zu would do through conditional compilation because you know that the legacy systems that you want to cater to don't support it. I'd be more inclined to use a typedef for types though, and to still use %zu instead of %llu: no sense doing an unnecessary cast even though it is safe (and if the type is effectively unsigned long long, it would be optimised away, but you can't be sure that it is not effectively unsigned long, as you pointed out).
What's with the SCN macros?
Since we were only talking printf macros I thought the poster might be interested to see how to cast the scanf usage portably, since unsigned short is always available and size_t is always at least 2 bytes it would make sense to just limit the user input to 2 bytes worth, while it can certainly be done plainly in code like this:
doesn't mean I don't get that itch to complete the set :)Code:scanf("%hu", (unsigned short *)(&size) );