Hello, On 11/17/22 08:02, A via Libc-alpha wrote: > Hi, > > I prefer long over size_t. 'long'? really? 'ptrdiff_t' could make sense, but 'long' is a very bad choice, IMO. I whish it had never been invented. What does 'long' mean, in a (ISO C) portable way? Nothing. 'long' is just a type on which typedefs can be made, but it has no use on its own, except for a few places in libc where it's used because noone stopped to create a better typedef for the variable (e.g., timespec.tv_nsec, which would have been better with a typedef called nseconds_t). > > This is because, in case the user passes a negative number by mistake > then I will be able to check it if the type is long and return > immediately. signed types have their own issues. In the end, if you pass a negative value to malloc(3), which will be converted to a huge value, sooner or later you will probably realize. > > But if size_t is used, then most probably, it will result in a crash - And I love that. Crashing is the best thing you can do. That tells me immediately that I wrote a bug. Isn't that what we wanted in the first place? > like malloc(-1) will crash the program because unsigned -1 is > 0xFFFFFFFF and this much memory is not available on today's computers > and probably may not be available at all in future also (RAM size of > 2^64 bits is really really huge). We're not so lucky with malloc(3), since it's virtual memory, and you won't get it all at once. But yes, sooner or later, if you passed -1 to malloc(3), you'll see a crash, which is a Good Thing (tm). > > Another thing is that if size_t is used an array index then array[-1] > will result in wrong behavior or program crash. But with long, the > developer can check whether the index is negative, thus avoiding > program crash. And what do you plan to do when you detect -1 in your code? Set errno to EPROGRAMMERNOTSMARTENOUGH and return -1 from your function? BTW, just for fun, would anyone please add that errno code to glibc? It would be a nice easter egg :P If you weren't smart enough to avoid a bug in your code (and of course nobody is smart enough to write 0 bugs), can you yourself write code that is smart enough to handle it? It makes little sense. What if you write another bug in your code handling the bug? > > So, in my opinion, long should be used instead of size_t. I'd like to change your opinion. Please read this excellent article by Jens Gustedt (member of WG14, the group that develops the ISO C standard) which explains why size_t is better: > > I know that original glibc authors had chosen size_t, so there must be > some reason for that, however that reason is not clear to me. The reason why it was chosen is not documented, AFAIK, and could possibly be attributed to a historical accident. However, I'd say it's a great accident if it was that way. But in the article above you may find readons to keep using it for your own code. > > Amit Cheers, Alex --