Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168385
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: size_t vs long. |
| Date | 2022-11-29 10:21 -0800 |
| Organization | None to speak of |
| Message-ID | <87tu2hk4fa.fsf@nosuchdomain.example.com> (permalink) |
| References | (3 earlier) <1b4juk47wa.fsf@pfeifferfamily.net> <tm0s7v$1p7e1$1@dont-email.me> <tm0sf3$1p7e1$2@dont-email.me> <xOSgL.117610$8875.113341@fx13.iad> <0a801acb-1c1d-4216-894a-aa11ad307934n@googlegroups.com> |
A <amit234234234234@gmail.com> writes:
> On Monday, 28 November 2022 at 05:26:26 UTC+5:30, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> >On 11/27/2022 3:35 PM, Chris M. Thomasson wrote:
>> >> On 11/27/2022 9:36 AM, Joe Pfeiffer wrote:
>> >>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> >>>
>> >>>> On 11/25/2022 5:26 PM, Dolores Filandro wrote:
>> >>>>> malloc returns NULL if the amount requested exceeds what malloc can
>> >>>>> allocate.
>> >>>>> There is no wrong behavior or crash from malloc(-1)
>> >>>>
>> >>>> I remember way back, in 2001'ish where if a malloc failed the server
>> >>>> program would go into "panic mode" and start dumping resources.
>> >>>
>> >>> That's a program that didn't properly handle a null return from
>> >>> malloc(), not a problem with malloc().
>> >>>
>> >>> Something I do regard as a problem with either malloc(), Linux, or their
>> >>> interaction is that malloc() will happily allocate space that doesn't
>> >>> exist, and the user won't find out until an attempt is made to access
>> >>> the space and a protection violation happens.
>> >>
>> >> I was testing different methods to handle resources in a server back
>> >> then. One of the tests would malloc per-connection state on every new
>> >> connection. Sure enough, a stress test would make a malloc return NULL.
>> >> So, I would start dumping user state, and try malloc again in an
>> >> experiment. Fun times. NT 4.0. Actually, forget about malloc failing for
>> >> a moment, I remember some tests where the non-paged memory pool would
>> >> get exhausted do to too many pending IOCP actions, and blast the whole
>> >> system.
>> >
>> >For some reason my brain is thinking about an old paper that dealt with
>> >so-called cohort scheduling. A method to bunch up like operations in
>> >IOCP or the POSIX aio api. Let me try to find the paper...
>> >
>> Back in the mid 90's, I was working on the Oracle OSD for the Unisys OPUS
>> platform (a massively parallel system). The OSD (OS-dependent layer)
>> abstracts the hardware from the RDBMS itself. The OPUS systems had
>> up to 64 nodes, each with a scsi controller and each with an ethernet
>> port (100baseT at that point). We were running OPS (Oracle Parallel
>> Server - later called RAC) to exploit the parallelism.
>>
>> The database was striped across multiple disks on all nodes and OPS
>> workloads are dominated by I/O. The core RDBMS passed a list of
>> required blocks to the OSD layer and we use the POSIX lio_listio(2)
>> function to queue several thousand block requests to the kernel with
>> a single system call. The kernel queued all the I/O's to the corresponding
>> node automatically and we could poll for completion when prompted by the
>> RDBMS.
>
>
> Is size_t usage justified in memcpy()? If a user passes a negative
> number by mistake then memcpy() will crash.
How do you know it will crash?
It's not possible to pass a negative value to memcpy(). It is possible
to use a negative value as an argument, but it will be implicitly
converted to size_t before being passed.
Yes, if you pass -1 as the size argument, it will result in memcpy()
receiving SIZE_MAX. This will *probably* result in undefined behavior,
because it *probably* exceeds the size of the source and/or target
object, and likely the maximum object size the implementation supports.
There is no guarantee that it will crash. In the worst case, it will
quietly copy more memory than you intended, corrupt memory past the end
of the target object, and result in arbitrary misbehavior later on.
So don't do that.
Seriously, passing a negative value to memcpy() would be a bug, but it's
not one that I've ever encountered as far as I know. Programs don't
call memcpy() with a size argument obtained from unchecked user input.
Have you ever encountered such a bug?
You propose changing the way the language defines memcpy() (and a
plethora of other functions) to avoid an error that hardly ever occurs.
And it's just one of a number of possible errors, such as passing a
pointer to an object that no longer exists, computing the size
incorrectly in a way that still yields a positive value, trying to copy
overlapping objects, passing a pointer to the wrong object, reversing
the source and destination pointers, etc.
It's not possible to guard against all these errors. It might be
possible to build an interface *on top of* memcpy() that guards against
many of them.
> void *memcpy(void *dest, const void *src, size_t n);
>
> Shouldn't memcpy() function be like this:
>
> void *memcpy(void *dest, const void *src, long n)
> {
> if (n < 0)
> return NULL;
>
> __Rest_of_Code__
>
> }
No, it shouldn't.
The use of size_t by memcpy() is mandated by the ISO C standard.
I believe that's been mentioned here a number of times.
The standard (nearly) guarantees that the size of any object can be
represented by a value of type size_t. It makes no such guarantee for
type long. And in fact modern Windows has 32-bit long and 64-bit
size_t, and you could have an object whose size requires 33 or more bits
to represent it. I believe that's also been mentioned here a number of
times. You haven't suggested how that should be addressed.
> It can be argued that a large number for 'n' can also crash the system
> but we should try to crash as less as possible.
At what cost? (And again, a crash is not guaranteed.)
> Crashing is good but only during internal testing. Once the system
> goes live and people start using it, then if the system crashes then
> it is a big problem. And it is quite possible that the system may not
> crash in internal testing but may crash when it is live.
Yes, bugs happen. I do not suggest radically changing an aspect of the
language (abandoning size_t) to prevent one very rare class of bug.
> Suppose, a user by mistake enters '-1' for some value asked by the
> system and then this value is passed to memcpy(), then memcpy() will
> crash. It can be argued that the system can check for negative values,
> but it is equivalent to saying that memcpy() can also check for
> negative values.
That would be the fault of the programmer who passed an unchecked value
to memcpy().
> And, in internal testing, it is quite possible than manual testers /
> automated tests don't pass a value of '-1' when asked for a value by
> the system.
They shouldn't be able to. A user typing the string "-1" on standard
input should never result in a value of -1 being passed to memcpy().
There needs to be a lot more checking between user input and low-level
function calls.
> I know glibc won't be changed but in my opinion, where ever size_t is
> used in glibc and a '-1' value for it can crash the system, then
> size_t is a wrong choice. In my opinion, these functions should
> declare size variables as long and check for negative values and
> return an error if the value is negative.
Why are you still talking about glibc? glibc implements these functions
as specifed by the C standard. It cannot change them. Your disgreement
is with the way they're defined by the C standard.
If I agreed with your underlying point, I would not suggest using long.
I would suggest that the type used to represent sizes should be a a
signed type rather than an unsigned type. I would suggest standardizing
the POSIX signed integer type ssize_t (which can be defined
appropriately for each implementation) and using that as the parameter
for memcpy(), and deprecating the unsigned type size_t.
Again, I do not agree with your underlying point. Accidentally passing
a negative value to memcpy() is a rare error, one that I don't think
I've ever seen, and that's the entire rationale for your suggestion.
But even I agreed, changing memcpy()'s parameter type from size_t to
long would be the wrong answer.
If you want the kind of memory safety you're looking for, there are
other languages that (attempt to) provide it. (Many of them are
implemented in C.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-16 22:20 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-17 02:44 -0500
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 00:16 -0800
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 00:28 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-17 07:59 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 05:09 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 13:45 +0000
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 22:39 -0800
Re: size_t vs long. Ike Naar <ike@sdf.org> - 2022-11-18 08:19 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:42 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:32 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:32 -0500
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-18 11:21 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-19 02:51 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 11:37 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 22:39 -0800
Re: size_t vs long. Paul <nospam@needed.invalid> - 2022-11-18 13:21 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 16:17 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 09:56 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:46 -0500
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:41 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 09:37 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:41 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:56 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 13:03 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-19 21:17 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 17:41 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-21 10:30 +0100
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-22 04:27 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-22 08:55 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:33 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 22:50 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-25 20:51 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-25 12:21 -0800
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 06:52 -0800
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 09:31 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 02:43 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-17 10:02 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:19 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 01:46 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 13:01 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 04:56 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:49 +0000
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 06:19 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-19 06:44 -0800
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 09:53 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 02:23 -0500
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 06:42 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-19 10:00 -0500
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 10:09 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 13:27 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-24 11:26 +0100
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-04 06:29 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-21 11:31 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-21 08:51 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-21 15:11 -0500
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-18 07:33 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 04:55 -0800
Re: size_t vs long. tTh <tth@none.invalid> - 2022-11-18 11:01 +0100
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-23 09:23 +0100
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-24 20:09 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-25 08:29 +0100
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-17 11:16 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 02:48 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 11:30 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 03:52 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 12:27 +0000
Re: size_t vs long. Mark Bluemel <mark.bluemel@gmail.com> - 2022-11-17 04:28 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 04:34 -0800
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 15:48 +0000
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 22:36 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 04:28 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 12:46 +0000
Re: size_t vs long. Paul N <gw7rib@aol.com> - 2022-11-17 05:24 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 16:20 +0000
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 15:55 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:43 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:47 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:33 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 22:38 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:51 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-20 15:43 +0000
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-20 15:29 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 16:59 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:30 +0100
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 12:47 +0000
Re: size_t vs long. Ike Naar <ike@sdf.org> - 2022-11-17 13:15 +0000
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-17 15:01 +0000
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-11-17 15:24 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-17 21:48 -0800
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-18 20:12 +0100
Re: size_t vs long. Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-18 00:26 -0600
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:37 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:43 -0500
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 03:06 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 19:58 -0800
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 08:34 +0100
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-20 20:11 +0100
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 20:48 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-21 21:57 -0800
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-11-22 02:33 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-25 12:01 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-23 09:28 +0100
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-23 13:29 +0100
Re: size_t vs long. Dolores Filandro <dolfiland8@gmail.com> - 2022-11-25 17:26 -0800
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-26 09:15 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-26 14:50 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-26 18:02 -0500
Re: size_t vs long. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-11-27 10:36 -0700
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 18:23 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-27 15:35 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-27 15:39 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 23:56 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 00:51 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 06:29 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 03:43 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 12:43 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 04:56 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 08:11 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 05:18 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 18:53 -0500
Re: size_t vs long. Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-10 16:04 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 17:19 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 18:55 -0500
Re: size_t vs long. Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2022-11-30 00:02 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-30 01:58 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-29 10:21 -0800
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-29 19:42 +0100
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-29 19:00 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-29 13:47 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-29 22:45 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-30 00:42 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-30 00:44 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-30 23:31 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-30 23:35 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-01 09:08 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 04:23 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 16:42 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-01 02:47 -0500
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-01 09:14 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-01 12:41 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-01 23:53 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:30 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-03 13:48 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-05 00:17 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:12 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 14:55 +0100
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 09:35 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 14:56 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 15:33 -0500
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-03 20:51 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 15:58 -0500
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-03 21:12 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 17:22 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 23:58 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 19:25 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 23:44 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 19:22 -0500
Re: size_t vs long. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-12-03 16:41 +0000
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 17:24 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-01 10:04 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-01 19:14 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 04:49 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 05:13 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-02 07:17 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 08:07 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-02 16:32 +0000
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-02 16:58 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 12:46 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:32 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:41 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:42 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:49 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-04 12:49 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-03 12:59 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-04 11:54 -0500
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-02 14:58 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:17 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:38 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-03 03:39 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-13 01:45 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-13 20:18 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-14 01:20 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-16 03:03 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-05 01:21 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-05 01:41 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-05 16:53 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 01:29 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 10:51 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 02:19 -0800
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-06 02:43 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 14:56 +0100
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2023-01-06 16:26 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 19:51 +0100
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-06 12:52 -0800
Re: size_t vs long. DFS <nospam@dfs.com> - 2023-01-05 15:38 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-05 14:05 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 01:30 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-06 10:06 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-03 18:11 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-13 01:46 -0800
Re: size_t vs long. Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-10 17:24 +0000
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-10 11:51 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-10 21:09 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-11 20:49 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 10:18 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:24 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 16:54 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-03 12:48 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-04 11:55 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 09:58 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-01 20:02 +0000
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-04 07:35 -0800
csiph-web