Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #155484 > unrolled thread

Trick to knowing hex address alignment?

Back to article view | Back to comp.lang.c

Contents

  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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#155664

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>The 68K series has (had?) distinct address and data registers
>>>(A0..A7, D0..D7).  A7 is the stack pointer.
>>
>> Although, loading those registers did not perform any permissions check (which
>> was the genesis of this thread by bonnie's sockpuppet).
>>
>> Many older architectures had only one register, if they had registers at
>> all.   e.g.  Burroughs B5500 and HP-3000 (stack based) or the various
>> memory-to-memory architectures (Burroughs B3500, IBM 1401, IBM 1620)
>> are examples.   Several had reserved locations in memory that could be
>> used as 'index' registers.
>>
>> In the Burroughs cases, permission checking happened when memory
>> was accessed.
>
>The only exception I know of to that rule (you check memory protections
>when you access memory) was the 286 checking when you loaded a segment
>register.  In that case, no one in their right mind would ever load a
>segment register unless they were planning to access that memory
>segment, so it made sense.
>
>I wouldn't be at all surprised to learn of other segmented architectures
>that behaved the same way, but I don't know of them.

Burroughs Medium systems was 'segmented' (maximum 500KB / 1,000,000 digits
per segment). Eight segments were active at any one time, the first held
general global data and the stack, the second code; the remaining were
application specific.

The address space was described via an Environment Table.  An application
could have up to 100,000 environments.   Each environment had a memory
area table with up to 100 entries (the first eight would be loaded into
the base/limit registers, the remaining were available to be referenced
via "copy" descriptors or a set of data movement instructions (compare,
move and hash)).

Both in-environment and cross-environment function call instructions
(virtual enter - VEN) were available, the cross-environment would
load the eight base-limit registers with the table associated with the
target environment number.    Negative environment numbers (0xD00001,
for example) are reserved for the operating system code/data (similarly
to the VA splits on x86/arm).

The index registers (1-3 mapped to addresses 0, 8 and 24 in base 0,
and 4-7 held in the processor) had a digit that selected which
base to use, and there were operand prefixes that would select
base 0 or base 1 directly.

Permissions checks, such as they were in the day, occured during
the VEN call.

While data pointers were 8 digits (sign, base selector, six-digit offset),
function pointers were 20 digits (6 digit target environment number,
6 digit offset in target environment base 1, and 8 padding digits for
future use).

Smallest addressable unit was the digit (nibble, 4-bits).

[toc] | [prev] | [next] | [standalone]

#155626

Richard Damon <Richard@Damon-Family.org> writes:

> On 10/12/20 10:37 AM, Christian Hanné wrote:
>>>> The conversion (uintptr_t)pointer takes hundreds
>>>> of clock clycles on a CPU today.
>> 
>>>
>>> A convertion from (type *) to (uintptr_t) is a no-op on
>>> x86, x86_64, armv7, armv8 and most other modern CPUs.
>> 
>> No, it involves a privilege-check on the page referenced.
>> When you convert the pointer to size_t this doesn't happen.
>
> The privilege check will only happen if the pointer is loaded into an
> 'address' register. A compiler would be very bad to load the pointer
> into such a register if it isn't being used to access the memory, and
> especially if arithmatic is going to immediately be done on the value.
>
> Such a compiler is almost sure to do the same for a conversion to
> size_t, so there would be no savings.
>
> Perhaps, on a segmented address machine, it would be more efficent to
> use a special pointer load instruction (if such a thing existed) that
> loaded both the segment and offset in one step, and that might cause the
> check, but on such a machine, size_t is probably not sufficient to hold
> the conversion of the pointer (but maybe enough to just check alignment).

The closest thing I can think of to an architecture in which loading
into an address register would cause a privilege check would indeed be
the segmentation registers in a 286 -- and as you say, nobody is going
to load one of them until you're actually in the process of
dereferencing the pointer.

[toc] | [prev] | [next] | [standalone]

#155642

On 2020-10-12, Christian Hanné <the.hanne@gmail.com> wrote:
>>> The conversion (uintptr_t)pointer takes hundreds
>>> of clock clycles on a CPU today.
>
>> 
>> A convertion from (type *) to (uintptr_t) is a no-op on
>> x86, x86_64, armv7, armv8 and most other modern CPUs.
>
> No, it involves a privilege-check on the page referenced.
> When you convert the pointer to size_t this doesn't happen.

You are bat-shit crazy/stupid.

[toc] | [prev] | [next] | [standalone]

#155644

>>> A convertion from (type *) to (uintptr_t) is a no-op on
>>> x86, x86_64, armv7, armv8 and most other modern CPUs.

>> No, it involves a privilege-check on the page referenced.
>> When you convert the pointer to size_t this doesn't happen.

> You are bat-shit crazy/stupid.

You are misinformed.

[toc] | [prev] | [next] | [standalone]

#155673

On 2020-10-13, Christian Hanné <the.hanne@gmail.com> wrote:
>>>> A convertion from (type *) to (uintptr_t) is a no-op on
>>>> x86, x86_64, armv7, armv8 and most other modern CPUs.
>
>>> No, it involves a privilege-check on the page referenced.
>>> When you convert the pointer to size_t this doesn't happen.
>
>> You are bat-shit crazy/stupid.
>
> You are misinformed.

Oh, I have it from some pretty darn unreliable sources that you're
bat-shit crazy/stupid.  Namely, your posts in this thread.

Sorry, you walked right into that one, and something tells me
you might be prone to doing so repeatedly.

[toc] | [prev] | [next] | [standalone]

#155675

Kaz Kylheku <793-849-0957@kylheku.com> writes:

> On 2020-10-13, Christian Hanné <the.hanne@gmail.com> wrote:
>>>>> A convertion from (type *) to (uintptr_t) is a no-op on
>>>>> x86, x86_64, armv7, armv8 and most other modern CPUs.
>>
>>>> No, it involves a privilege-check on the page referenced.
>>>> When you convert the pointer to size_t this doesn't happen.
>>
>>> You are bat-shit crazy/stupid.
>>
>> You are misinformed.
>
> Oh, I have it from some pretty darn unreliable sources that you're
> bat-shit crazy/stupid.  Namely, your posts in this thread.

Those seem like very reliable sources to me.

[toc] | [prev] | [next] | [standalone]

#155561

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Saturday, October 10, 2020 at 1:50:20 PM UTC-4, Christian Hanné wrote:
>> > sprintf() isn't particularly efficient. .. 
>> 
>> No, it's the superior solution.
>
> Superior to (uintptr_t)pointer % 32 == 0? In what way?

Haven't you sussed the poster's MO yet?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#155567

On 10/12/20 6:20 AM, Ben Bacarisse wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> 
>> On Saturday, October 10, 2020 at 1:50:20 PM UTC-4, Christian Hann� wrote:
>>>> sprintf() isn't particularly efficient. .. 
>>>
>>> No, it's the superior solution.
>>
>> Superior to (uintptr_t)pointer % 32 == 0? In what way?
> 
> Haven't you sussed the poster's MO yet?

I think you may be correct.

[toc] | [prev] | [next] | [standalone]

#155501

Christian Hanné <the.hanne@gmail.com> writes:
>> Is there a trick to quickly figuring the alignment?
>
> Do a sprintf and identify the 16-bit-aligned adresses by checking if
> the last digit is 0, the 32-bit-aligned addresses by checking if the
> last digit is 0 and the second last digit is even. That's the most
> efficient solution.

I'm not going to say that's the *least* efficient solution, but I
can't think of one that's less efficent without being deliberately
contrived.

Convert to unintptr_t and check the low-order bits.  This isn't
completely portable (I've worked on systems where it wouldn't work),
but it's likely to work on most implementations.  Add a comment
acnowledging the portability issues.

The standard guarantees that converting a void* value to [u]intptr_t
and back again yields the original value.  If there is no integer
type for which it can make that guarantee, it won't define
[u]intptr_t.  It says nothing about how pointers are represented,
so you can't portably assume that the low-order bits mean what you
think they do, but implementations where they don't are rare.

-- 
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]

#155512

> Convert to unintptr_t and check the low-order bits.

The conversion is ultimately slow.

[toc] | [prev] | [next] | [standalone]

#155540

Christian Hanné <the.hanne@gmail.com> writes:
>> Convert to unintptr_t and check the low-order bits.
>
> The conversion is ultimately slow.

I wrote the text you quoted.  Please leave attributions in place.

I'm not sure just what you mean by "The conversion is ultimately
slow", but it's almost certainly incorrect.  Conversion between
same-sized integer and pointer types is likely to be free, or
nearly so.  Note that my suggestion was a reply to your claim that
calling sprintf() and checking the last character is "the most
efficient solution".

Are you serious?

-- 
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]

#155554

> I'm not sure just what you mean by "The conversion is ultimately
> slow", but it's almost certainly incorrect.  Conversion between
> same-sized integer and pointer types is likely to be free, or
> nearly so. ...

Wrong.

[toc] | [prev] | [next] | [standalone]

#155557

Christian Hanné <the.hanne@gmail.com> writes:
>> I'm not sure just what you mean by "The conversion is ultimately
>> slow", but it's almost certainly incorrect.  Conversion between
>> same-sized integer and pointer types is likely to be free, or
>> nearly so. ...
>
> Wrong.

You have again removed the attribution line that would have told
readers that I wrote the quoted text (starting with "I'm not sure").
Stop doing that.  It's rude.

Your claims about the relative efficiency of a call to sprintf
vs. a simple pointer-to-integer conversion are laughably incorrect.

I'm nearly convinced that you are deliberately trolling.
You probably think you're being clever.  You're not.

If you'd like to back up your rather extraordinary claims, please
do so.  If not, don't expect anyone to pay any further attention
to you.

-- 
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]

#155563

> If you'd like to back up your rather extraordinary claims, please
> do so.  If not, don't expect anyone to pay any further attention
> to you.

Convertion to uintptr_t involves a privilege-check to the page
addressed. That's not true for conversions to ptrdiff_t or size_t.

[toc] | [prev] | [next] | [standalone]

#155570

Christian Hanné <the.hanne@gmail.com> writes:
>> If you'd like to back up your rather extraordinary claims, please
>> do so.  If not, don't expect anyone to pay any further attention
>> to you.
>
> Convertion to uintptr_t involves a privilege-check to the page
> addressed. That's not true for conversions to ptrdiff_t or size_t.

*PLONK*

-- 
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]

#155571

>> Convertion to uintptr_t involves a privilege-check to the page
>> addressed. That's not true for conversions to ptrdiff_t or size_t.

> *PLONK*

You really lack essntial IT-knowledge.

[toc] | [prev] | [next] | [standalone]

#155574

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Christian Hanné <the.hanne@gmail.com> writes:
>>> I'm not sure just what you mean by "The conversion is ultimately
>>> slow", but it's almost certainly incorrect.  Conversion between
>>> same-sized integer and pointer types is likely to be free, or
>>> nearly so. ...
>>
>> Wrong.
>
>You have again removed the attribution line that would have told
>readers that I wrote the quoted text (starting with "I'm not sure").
>Stop doing that.  It's rude.

It's also likely to be another sock puppet for bonnie.

[toc] | [prev] | [next] | [standalone]

#155576

>> You have again removed the attribution line that would have told
>> readers that I wrote the quoted text (starting with "I'm not sure").
>> Stop doing that.  It's rude.

> It's also likely to be another sock puppet for bonnie.

My reader is - like most readers - split in three sections: one for the
groups-list, one for the threaded view of the articles of the group and
one for the article itself. I can see from the theading who responses
to whom. So where's the problem. This isn't rude.

[toc] | [prev] | [next] | [standalone]

#155595

On 10/12/2020 7:35 AM, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Christian Hanné <the.hanne@gmail.com> writes:
>>>> I'm not sure just what you mean by "The conversion is ultimately
>>>> slow", but it's almost certainly incorrect.  Conversion between
>>>> same-sized integer and pointer types is likely to be free, or
>>>> nearly so. ...
>>>
>>> Wrong.
>>
>> You have again removed the attribution line that would have told
>> readers that I wrote the quoted text (starting with "I'm not sure").
>> Stop doing that.  It's rude.
> 
> It's also likely to be another sock puppet for bonnie.
> 

Big time!

[toc] | [prev] | [next] | [standalone]

#155556

On 11/10/2020 23:11, Keith Thompson wrote:
> Christian Hanné <the.hanne@gmail.com> writes:
>>> Convert to unintptr_t and check the low-order bits.
>>
>> The conversion is ultimately slow.
> 
> I wrote the text you quoted.  Please leave attributions in place.
> 
> I'm not sure just what you mean by "The conversion is ultimately
> slow", but it's almost certainly incorrect.  Conversion between
> same-sized integer and pointer types is likely to be free, or
> nearly so.  Note that my suggestion was a reply to your claim that
> calling sprintf() and checking the last character is "the most
> efficient solution".
> 
> Are you serious?
> 

I think it is clear that Christian Hanné is serious about trolling
people.  No one can possibly be as completely wrong and muddled as his
posts have suggested (and we've seen a few wrong and muddled people in
c.l.c. over the years).  He is trolling.  The only reason to reply to
his posts would be if you think he might be confusing other people.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web