Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #155484 > unrolled thread
| Started by | dfs <nospam@dfs.com> |
|---|---|
| First post | 2020-10-09 20:11 -0400 |
| Last post | 2020-10-10 14:01 -0700 |
| Articles | 20 on this page of 131 — 23 participants |
Back to article view | Back to comp.lang.c
Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 20:11 -0400
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-09 18:43 -0600
Re: Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 22:14 -0400
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-10 01:10 +0000
Re: Trick to knowing hex address alignment? dfs <nospam@dfs.com> - 2020-10-09 22:15 -0400
Re: Trick to knowing hex address alignment? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-10-10 01:30 -0400
Re: Trick to knowing hex address alignment? BGB <cr88192@gmail.com> - 2020-10-10 01:30 -0500
Re: Trick to knowing hex address alignment? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-10-12 16:58 -0400
Re: Trick to knowing hex address alignment? BGB <cr88192@gmail.com> - 2020-10-14 16:04 -0500
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-10 18:31 +0200
Re: Trick to knowing hex address alignment? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-10-10 09:46 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-10 19:50 +0200
Re: Trick to knowing hex address alignment? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-10-10 18:45 +0000
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-10 15:05 -0400
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-10 12:34 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 08:10 +0200
Re: Trick to knowing hex address alignment? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-10-11 02:29 -0700
Re: Trick to knowing hex address alignment? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-10-11 12:08 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 13:13 +0200
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-11 15:06 -0400
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-11 15:27 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:18 +0200
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 08:19 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 00:43 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 12:03 +0200
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 13:14 +0200
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-12 08:33 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:21 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:07 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:58 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 00:10 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 09:53 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:25 -0700
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:31 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 10:34 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 01:47 -0700
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-13 15:39 +0000
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 16:16 -0700
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:32 +0000
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-12 07:13 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 19:16 +0200
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-12 21:26 +0100
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:08 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:50 +0200
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-11 21:16 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:18 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:44 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:21 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 13:18 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:19 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-11 14:12 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:20 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-12 07:09 -0700
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:35 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:37 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 15:51 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 17:07 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 16:45 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 17:47 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-12 17:05 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:46 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:19 -0700
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:48 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:22 +0200
Re: Trick to knowing hex address alignment? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-10-13 06:25 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:20 +0200
Re: Trick to knowing hex address alignment?, speciall Richard Damon <Richard@Damon-Family.org> - 2020-10-13 12:38 -0400
Re: Trick to knowing hex address alignment?, speciall James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-13 12:51 -0400
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-12 11:11 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 18:50 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-12 13:03 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 19:30 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:47 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:52 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:23 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 14:43 +0100
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 08:57 -0600
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:21 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 17:38 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:03 +0200
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 11:20 -0600
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:23 +0200
Re: Trick to knowing hex address alignment? Bart <bc@freeuk.com> - 2020-10-13 18:28 +0100
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:30 +0200
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-14 09:24 +0000
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-14 09:35 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-15 09:29 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-13 10:24 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 19:31 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-13 14:47 -0700
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-12 21:48 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 06:49 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-13 15:24 +0000
Re: Trick to knowing hex address alignment? Richard Damon <Richard@Damon-Family.org> - 2020-10-13 12:32 -0400
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-13 21:55 +0100
Re: Trick to knowing hex address alignment? Vir Campestris <vir.campestris@invalid.invalid> - 2020-10-13 22:00 +0100
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-13 14:13 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-14 13:13 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-14 15:59 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-14 11:31 -0600
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-14 19:03 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-13 09:50 -0600
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-13 17:41 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 20:07 +0200
Re: Trick to knowing hex address alignment? Kaz Kylheku <793-849-0957@kylheku.com> - 2020-10-15 00:38 +0000
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-14 21:23 -0600
Re: Trick to knowing hex address alignment? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-10-12 11:20 +0100
Re: Trick to knowing hex address alignment? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-10-12 10:19 -0400
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-10 15:42 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-11 13:14 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-11 14:11 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 07:20 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 00:42 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 13:16 +0200
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 07:22 -0700
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:23 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-12 14:35 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-12 16:40 +0200
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-12 14:09 -0700
Re: Trick to knowing hex address alignment? David Brown <david.brown@hesbynett.no> - 2020-10-12 08:26 +0200
Re: Trick to knowing hex address alignment? Öö Tiib <ootiib@hot.ee> - 2020-10-12 03:19 -0700
Re: Trick to knowing hex address alignment? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-10-12 07:22 -0700
Re: Trick to knowing hex address alignment? arnold@hooterville.invalid (Arnold Ziffel) - 2020-10-13 11:59 +0000
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 14:25 +0200
Re: Trick to knowing hex address alignment? scott@slp53.sl.home (Scott Lurndal) - 2020-10-13 15:26 +0000
Re: Trick to knowing hex address alignment? DFS <nospam@dfs.com> - 2020-10-13 11:33 -0400
Re: Trick to knowing hex address alignment? Christian Hanné <the.hanne@gmail.com> - 2020-10-13 18:23 +0200
Re: Trick to knowing hex address alignment? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-10-11 09:47 -0600
Re: Trick to knowing hex address alignment? Elias Schwerdtfeger <nachtwaechter@tamagothi.de> - 2020-10-10 18:45 +0200
Re: Trick to knowing hex address alignment? Barry Schwarz <schwarzb@delq.com> - 2020-10-10 10:32 -0700
Re: Trick to knowing hex address alignment? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-10-10 14:01 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-10-11 15:27 -0400 |
| Message-ID | <rlvmaq$4cs$1@dont-email.me> |
| In reply to | #155506 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Sunday, 11 October 2020 at 07:11:01 UTC+1, Christian Hann� wrote: >> > size_t is an integer type, not compatible with any pointer type. ... >> >> You can actuall convert a pointer to size_t and back without any loss >> of information on all today's platforms. I'm curious - how do you know this? Are you actually familiar with every implementation of C currently in use? Can you provide us with a comprehensive list? I think that what you actually mean is "... all platforms I'm personally familiar with", but if you had said that, it wouldn't support your point as well as what you actually said. > You have to ask yourself, what is more likely - that size_t isn't the same size > as a pointer, or that the code might have to be ported to pre-C99 where > uintptr_t isn't avaialble? I have no idea how to even collect the information needed to answer that question, much less what that answer is. If every implementation of C that your code currently needs to work with is one where uintptr_t is supported and also one where size_t meets the requirements for uintptr_t, it doesn't make any difference. It's only the possibility that it will be ported to some other platform in the future that matters. In the future, the probability of needing to port to a platform where only C90 is supported should decline. You can also expect that implementations will eventually target platforms that differ from our current targets in unpredictable ways, including the possibility that UINTPTR_MAX > SIZE_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-12 07:18 +0200 |
| Message-ID | <rm0ouh$bam$1@gioia.aioe.org> |
| In reply to | #155530 |
> I'm curious - how do you know this? ... There's no of today's platforms where this doesn't work.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-12 08:19 +0200 |
| Message-ID | <rm0shr$1i4f$1@gioia.aioe.org> |
| In reply to | #155551 |
>> I'm curious - how do you know this? ... > There's no of today's platforms where this doesn't work. https://www.viva64.com/en/a/0050/ "The size of size_t and ptrdiff_t always coincide with the pointer's size."
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-10-12 00:43 -0700 |
| Message-ID | <87o8l76g97.fsf@nosuchdomain.example.com> |
| In reply to | #155555 |
Christian Hanné <the.hanne@gmail.com> writes:
>>> I'm curious - how do you know this? ...
>
>> There's no of today's platforms where this doesn't work.
>
> https://www.viva64.com/en/a/0050/
> "The size of size_t and ptrdiff_t always coincide with
> the pointer's size."
From that same web page:
Before we begin I would like to note that the definitions and
recommendations given in the article refer to the most popular
architectures for the moment (IA-32, Intel 64, IA-64), and may not
fully apply to some exotic architectures.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-10-12 12:03 +0200 |
| Message-ID | <rm19lp$4e3$1@dont-email.me> |
| In reply to | #155558 |
On 12/10/2020 09:43, Keith Thompson wrote: > Christian Hanné <the.hanne@gmail.com> writes: >>>> I'm curious - how do you know this? ... >> >>> There's no of today's platforms where this doesn't work. >> >> https://www.viva64.com/en/a/0050/ >> "The size of size_t and ptrdiff_t always coincide with >> the pointer's size." > > From that same web page: > > Before we begin I would like to note that the definitions and > recommendations given in the article refer to the most popular > architectures for the moment (IA-32, Intel 64, IA-64), and may not > fully apply to some exotic architectures. > It also recommends using uintptr_t as the integer type to use when converting a pointer to an integer. (In case anyone is interested, on the 8-bit AVR microcontrollers - a very popular modern family of microcontrollers with gcc as the main compiler, used in the "Arduino" kits - generic pointers are 24-bit and have size 3, while size_t is 16-bit and size 2. It is "exotic" in the sense that it doesn't run Linux or Windows.)
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-12 13:14 +0200 |
| Message-ID | <rm1dra$1f28$1@gioia.aioe.org> |
| In reply to | #155558 |
>> https://www.viva64.com/en/a/0050/ >> "The size of size_t and ptrdiff_t always coincide with >> the pointer's size." > From that same web page: > Before we begin I would like to note that the definitions and > recommendations given in the article refer to the most popular > architectures for the moment (IA-32, Intel 64, IA-64), and may not > fully apply to some exotic architectures. That's not necessary. size_t or ptrdiff_t is sufficient as well. And it has the advantage of backwards-compability.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-10-12 08:33 -0400 |
| Message-ID | <p2YgH.109614$nI.74938@fx21.iad> |
| In reply to | #155562 |
On 10/12/20 7:14 AM, Christian Hanné wrote: >>> https://www.viva64.com/en/a/0050/ >>> "The size of size_t and ptrdiff_t always coincide with >>> the pointer's size." > >> From that same web page: >> Before we begin I would like to note that the definitions and >> recommendations given in the article refer to the most popular >> architectures for the moment (IA-32, Intel 64, IA-64), and may not >> fully apply to some exotic architectures. > > That's not necessary. size_t or ptrdiff_t is sufficient as well. > And it has the advantage of backwards-compability. > size_t may not be big enough for a pointer. On segmented memory architecture, 'far' pointers can be bigger than an object can be. On such an architecture, size_t likely matches the size of the offset field. While the use of segmented memory isn't mainstream now, it does exist some in historical 16 bit protected mode code, and is available on the current 64 bit processors (though I don't think the OSes have real support for it at the moment). There are embedded processors which this is also not true, either because they use segmented addresses or a Harvard architecture, where pointers to program data (or 'const' data) might be bigger than a normal data pointer, and thus uintprt_t would be bigger than size_t.
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-12 16:21 +0200 |
| Message-ID | <rm1oot$pkg$1@gioia.aioe.org> |
| In reply to | #155564 |
> size_t may not be big enough for a pointer. On segmented memory > architecture, 'far' pointers can be bigger than an object can be. This are abandonned architectures. > While the use of segmented memory isn't mainstream now, it does exist > some in historical 16 bit protected mode code, and is available on the > current 64 bit processors (though I don't think the OSes have real > support for it at the moment). You can't even run 16 bit processes with a 64 bit OS because large mode hasn't support for this kind of processes.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-12 14:07 -0700 |
| Message-ID | <rm2gj4$s3q$1@gioia.aioe.org> |
| In reply to | #155568 |
On 10/12/2020 7:21 AM, Christian Hanné wrote: >> size_t may not be big enough for a pointer. On segmented memory >> architecture, 'far' pointers can be bigger than an object can be. > > This are abandonned architectures. > >> While the use of segmented memory isn't mainstream now, it does exist >> some in historical 16 bit protected mode code, and is available on the >> current 64 bit processors (though I don't think the OSes have real >> support for it at the moment). > > You can't even run 16 bit processes with a 64 bit OS because > large mode hasn't support for this kind of processes. Are you Bonita? You basically post the same way. No attributions, along with other odd similarities. :^)
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 06:58 +0200 |
| Message-ID | <rm3c5b$1nqe$1@gioia.aioe.org> |
| In reply to | #155593 |
>> You can't even run 16 bit processes with a 64 bit OS because >> large mode hasn't support for this kind of processes. > Are you Bonita? ... Bonita is using a different server than me.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 00:10 -0700 |
| Message-ID | <rm3jt4$9pg$1@gioia.aioe.org> |
| In reply to | #155603 |
On 10/12/2020 9:58 PM, Christian Hanné wrote: >>> You can't even run 16 bit processes with a 64 bit OS because >>> large mode hasn't support for this kind of processes. > >> Are you Bonita? ... > > Bonita is using a different server than me. > Why are you so similar?
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 09:53 +0200 |
| Message-ID | <rm3mdu$1e8i$1@gioia.aioe.org> |
| In reply to | #155604 |
> Why are you so similar? Simiar in stripping attributions? That's all?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 01:25 -0700 |
| Message-ID | <rm3o9u$5dh$1@gioia.aioe.org> |
| In reply to | #155605 |
On 10/13/2020 12:53 AM, Christian Hanné wrote: >> Why are you so similar? > > Simiar in stripping attributions? > That's all? Well, its more than that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 01:31 -0700 |
| Message-ID | <rm3olc$euk$1@gioia.aioe.org> |
| In reply to | #155606 |
On 10/13/2020 1:25 AM, Chris M. Thomasson wrote: > On 10/13/2020 12:53 AM, Christian Hanné wrote: >>> Why are you so similar? >> >> Simiar in stripping attributions? >> That's all? > > Well, its more than that. You seem to be a little bit of its clone?
[toc] | [prev] | [next] | [standalone]
| From | Christian Hanné <the.hanne@gmail.com> |
|---|---|
| Date | 2020-10-13 10:34 +0200 |
| Message-ID | <rm3oq7$hfl$1@gioia.aioe.org> |
| In reply to | #155607 |
> You seem to be a little bit of its clone? You smell paranoid.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 01:47 -0700 |
| Message-ID | <rm3pi6$s01$1@gioia.aioe.org> |
| In reply to | #155608 |
On 10/13/2020 1:34 AM, Christian Hanné wrote: >> You seem to be a little bit of its clone? > > You smell paranoid. Perhaps.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <793-849-0957@kylheku.com> |
|---|---|
| Date | 2020-10-13 15:39 +0000 |
| Message-ID | <20201013083920.633@kylheku.com> |
| In reply to | #155603 |
On 2020-10-13, Christian Hanné <the.hanne@gmail.com> wrote: >>> You can't even run 16 bit processes with a 64 bit OS because >>> large mode hasn't support for this kind of processes. > >> Are you Bonita? ... > > Bonita is using a different server than me. And since Bonita could never use a different server from the one Bonita uses, you can't be Bonita. QED.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-10-13 16:16 -0700 |
| Message-ID | <rm5cg9$jts$1@gioia.aioe.org> |
| In reply to | #155625 |
On 10/13/2020 8:39 AM, Kaz Kylheku wrote: > On 2020-10-13, Christian Hanné <the.hanne@gmail.com> wrote: >>>> You can't even run 16 bit processes with a 64 bit OS because >>>> large mode hasn't support for this kind of processes. >> >>> Are you Bonita? ... >> >> Bonita is using a different server than me. > > And since Bonita could never use a different server from the one Bonita > uses, you can't be Bonita. QED. > ;^)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-10-12 14:32 +0000 |
| Message-ID | <hOZgH.285435$r25.101856@fx08.iad> |
| In reply to | #155564 |
Richard Damon <Richard@Damon-Family.org> writes: >On 10/12/20 7:14 AM, Christian Hanné wrote: >>>> https://www.viva64.com/en/a/0050/ >>>> "The size of size_t and ptrdiff_t always coincide with >>>> the pointer's size." >> >>> From that same web page: >>> Before we begin I would like to note that the definitions and >>> recommendations given in the article refer to the most popular >>> architectures for the moment (IA-32, Intel 64, IA-64), and may not >>> fully apply to some exotic architectures. >> >> That's not necessary. size_t or ptrdiff_t is sufficient as well. >> And it has the advantage of backwards-compability. >> > >size_t may not be big enough for a pointer. On segmented memory >architecture, 'far' pointers can be bigger than an object can be. On >such an architecture, size_t likely matches the size of the offset field. > >While the use of segmented memory isn't mainstream now, it does exist >some in historical 16 bit protected mode code, and is available on the >current 64 bit processors (though I don't think the OSes have real >support for it at the moment). Segmentation, as such, in the x86 and compatible architectures died with AMD's 64-bit support. AMD did have to backtrack a bit and add support for checking the segment limit registers to support Xen before they added SVM.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-10-12 07:13 -0700 |
| Message-ID | <621e3611-606b-403c-9f68-da21ec0882c7n@googlegroups.com> |
| In reply to | #155562 |
On Monday, October 12, 2020 at 7:15:08 AM UTC-4, Christian Hanné wrote: > >> https://www.viva64.com/en/a/0050/ > >> "The size of size_t and ptrdiff_t always coincide with > >> the pointer's size." ... > > Before we begin I would like to note that the definitions and > > recommendations given in the article refer to the most popular > > architectures for the moment (IA-32, Intel 64, IA-64), and may not > > fully apply to some exotic architectures. > That's not necessary. size_t or ptrdiff_t is sufficient as well. > And it has the advantage of backwards-compability. David has already posted an example of a microcontroller where size_t is 2 bytes, while pointers have 3 bytes, meaning that ptrdiff_t and [u]intptr_t also need to have 3 bytes.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web