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

Groups > comp.lang.c > #138190

Re: My dynamic arrays module [was:Re: Pointer conversion and alignment]

Show all headers | View raw

Thanks for your very detailed answers, James:

> I don't know if I can help you with that, since I don't
> understand why you find it a stumbling block. A single
> object can be sub-divided into multiple sub-objects in
> many different ways -- that fact doesn't make it any less
> of a single object. This is exactly analogous to the fact
> that there are many different ways to subdivide a line
> segment into a group of smaller line segments. It is
> still, itself, a single line segment.

I understand the analogy and even have used its discrete
version to calculate the number of such subdivisions.  I
failed, however, to deduce the possibility of this
subdivision from the Standard.

> > I don't see how the Standard even hints at this
> > important property of objects, except very indirecly.
>
> "If a value is stored into an object having no declared
> type through an lvalue having a type that is not a
> character type, then the type of the lvalue becomes the
> effective type of the object for that access and for
> subsequent accesses that do not modify the stored value."
> (6.5p6)

I wrongly assumed that in `(*mydata).field' the lvalue used
for the access is `*mydata'.  I stand corrected.

> Note that it is ONLY the object written to that acquires
> that effective type. Higher level objects that happen to
> contain the object written to don't acquire an effective
> time just because a sub-object did.

That is difficult.  Writing to an `int' field of a struct
through a `short' pointer breaks the effective type of the
field, but keeps the effectvie type of the whole struct?
Remember my earlier example of overwriting the upper two
bytes of a (4-byte) int through a pointer to short (assumed
two bytes wide) -- you said this access broke the effective
type of the whole int object -- a contradition?

> =To a considerable extent, the fact that you're allowed to
> take advantage of this fact to give different pieces of a
> block different effective types, is due primarily to the
> lack of a prohibition on doing so. It's pretty hard to
> cite the text that fails to prohibit it - think about it.

Did you mean "to cite the text that prohibits it"?

> Writing to memory that has no declared type gives that
> memory an effective type which matches the type of the
> lvalue you used to write it. If you write individual
> members of a struct, you give each piece of memory the
> effective type of the corresponding piece. However, if you
> write an entire struct using a single lvalue, as in my
> example with
>
>    *now = empty;
>
> then that entire piece of memory has the effective type of
> that struct, which is a better match to your expectations.

And the result is an allocated object with a hierarchical
sturcture of effective types.

> > > I believe it is not necessary for a compiler to store
> > > such information.  The distinction is relevant
> > > primarily to which optimizations an implementation is
> > > permitted to perform, but what's relevant to those
> > > optimizations is the types of individual expressions
> > > in a piece of code.  If pointers to two types that are
> > > permitted to alias each other are in scope in the same
> > > block of code, the compiler can always simply not
> > > perform optimizations that would fail if they did
> > > alias each other.
> >
> > [...]
> > In other words, the compiler you described checks a
> > sufficient condition of aliasing violation, missing some
> > violations.
>
> No -- it's checking for sufficient conditions for the
> ABSENCE of aliasing violations; that's equivalent to NOT
> finding necessary conditions for an aliasing violation.

A sufficient condition is one that, when satisfied, makes
you certain that some statement is true.  When the compiler
sees two incompatible pointers used in some code block, it
assumes that they do not alias, even though in fact they
modify the same memory area.  This is an aliasing violation
amenable to aliasing optimisation.  Since this does not
apply to the case when the pointers do actually not alias
(so nothing is volated), it is more correct to say that the
compiler checks for a sufficient condition that a pair of
pointers may be considered as not alisaing each other.  Feel
free to ignore this terminologica nitpick, for we seem to
understand each other.

> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > void* vP;
> > void bye( void )
> > {  int i = *(int*)vP; /* this should be UB */
> >    printf("i = %i\n", i);
> > }
> >
> > int main(int argc, char** argv)
> > {  vP = malloc( sizeof( double ) );
> >    *(double*)vP = 11.11;
> >    /* ... */
> >    atexit( &bye );
> > }
>
> Since I can see that this code violates aliasing rules, a
> sufficiently sophisticated compiler could do so as well.
> However, it's not clear to me what optimization
> opportunities it would miss by failing to identify that
> fact. It might help me to understand your point if you
> could identify such an opportunity. How would the
> optimizaed version of the code differ from the unoptimized
> version?

For example, the optimised version might desist from
generating any machine code for this line:

   int i = *(int*)vP;

and supply the following printf() with an arbitrary hard-
code value -- UB in action!

> > Is it possible to implement a compiler that would be
> > able make a program that terminated upon each and every
> > effective type mismatch according to the letter of the
> > Standard?
>
> I believe it can be shown that identifying every effective
> type mismatch with no false positives or false negatives
> would be equivalent to solving the halting problem. The
> basic approach to this proof is to have execution of one
> of the two statements that makes it a mismatch depend upon
> whether or not a given piece of code halts.

I am sure it is true of detecting UB at compile time, but
surely not at run-time, i.e. during the execution of the
compiled program?

> > Terminating with a run-time error in case of UB is a
> > good idea as a compiler option.
>
> Many of the things that qualify as UB do so, precisely
> because it is unduly difficult to identify all possible
> cases where they come up. It is quite common for
> identifying such cases with no false positives and no
> false negatives, to be equivalent to solving the halting
> problem.

What sort of UB cannot be deteced at run-time?

> The usual way that UB is used is NOT to explicitly
> identify occurrences.  Instead, the compiler sets up
> conditions for performing a given optimization. Those
> conditions are chosen so that any code that meets those
> conditions, but would be broken by the optimization, must
> have undefined behavior.

Well, so far I fail to see why you can't simultaneously
optimise and detect UB at run-time.

> void replace_match_with_0(size_t n, int *x, int *y)
> {
>     for(size_t i = 0; i<n; i++)
>         if(x[i] == (int)*y)
>              x[i] = 0;
> }
> It might seem that this code can be optimized by
> evaluating *y only once, prior to the start of the loop,
> rather than repeatedly evaluating it during each pass
> through the loop. However, if x[i], for some value of i
> from 0 to n-1, refers to the same object as *y, then that
> optimization would be invalid. Such code has well-defined
> behavior, which causes the value of *y to change from
> whatever it was originally to 0, as soon as the loop
> executes for that value of i, and that changed value of *y
> would be used for all subsequent passes through the loop.
> That optimization would incorrectly continue using the
> original value of *y instead of the new one, and is
> therefore not allowed.

The (type-based) sufficient condition that the pointers can
be considered as not aliasing each other is not met.

> If, on the other hand, y were changed to "short *y", then
> the optimization would be perfectly valid, because it
> would have undefined behavior if *y aliased x[i].

In other words, the pointers can be considered as not
aliasing each other, although they may in fact point to the
same location in memory.

> That undefined behavior would take the form of having the
> change to the value of *y go unnoticed. Notice that
> compiler doesn't have any need to determine whether or not
> the behavior is undefined. It uses only the fact that *y
> has a type that cannot be used to alias x[i], to determine
> that the optimization is valid.

Yes: a simple sufficient conditon.

> > But *iP occupies the whole allocated region because I
> > passed sizeof(int) to malloc.
>
> My apologies - I hadn't noticed that you were allocating
> only a single int object. "The whole region" and "only
> *iP" refer to same thing, so we're actually in agreement,
> but I would have chosen different wording if I'd noticed.

Do feel free to correct my terminology.

> > In other words, upon writing through int*, we had the
> > following effective type for our 4-byte allocated
> > object:
> >                   1     2     3     4
> >                  int   int   int   int
> >
> > After modifying the latter two bytes through short* it
> > became:
> >                   1     2    3     4
> >                  N/A   N/A short short
> >
> > Looks pretty non-trivial to follow in an implementation
> > that takes the Standard literally...  Using sufficient
> > conditions of effective type mimatch instead of an exact
> > criterium is a relaxation that prevents the compiler
> > from catching all isntances of UB.
>
> You're thinking about UB incorrectly. A compiler is not
> obligated to catch all instances of UB,->

I understand that, and think that run-time detection of all
UB (it is impossible at compile-time) would be a good option
for the complier.  A test with full code coverage will then
help to eliminate the majority of UB in a program.

For the sake of curiosity and completeness, could you answer
my question about the int/short example above: did I
correctly deduce the final effective type of the allocated
object?

> -> which is good, because it's provably impossible to
> catch all such instances.

Impossible through static analysis at compile-time, but I
think possible at run-time.

> That fact, in turn, is part of the reason why many things
> have undefined behavior rather than being constraint
> violations: If an implementation is supposed to positively
> identify all occurrences of a given problem, and to never
> falsely identify the problem, the problem is usually
> tagged as a constraint violation, not as UB.

I think the reason is that detecting UB at run-time is
possible but hard and makes the program slower by executing
intrumental code of which the only purpose is the detection
of UB.

> The proper way to make use of the concept of UB is
> outlined in my discussion of replace_match_with_0() above.

Which is: use optimisation if the behavior without UB is
unaffected.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-17 14:38 +0300
  Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-17 17:37 +0300
    Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-17 21:01 +0000
      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 00:43 +0300
        Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:20 +0300
          Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:12 -0500
            Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 02:32 +0300
              Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:59 -0500
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 12:40 +0300
        Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 02:14 +0000
          Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 13:23 +0300
            Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 11:28 +0000
              Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 15:31 +0300
                Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 15:03 +0000
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 23:00 +0300
      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 00:49 +0300
  Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-17 06:52 -0800
    Re: Pointer conversion and alignment Ian Collins <ian-news@hotmail.com> - 2018-11-18 09:18 +1300
      Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-17 13:49 -0800
        Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-17 13:57 -0800
          Re: Pointer conversion and alignment Ian Collins <ian-news@hotmail.com> - 2018-11-18 11:08 +1300
            Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:13 +0300
              Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-17 18:37 -0800
        Re: Pointer conversion and alignment Philipp Klaus Krause <pkk@spth.de> - 2018-11-18 14:14 +0100
  Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 10:05 -0500
    Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:08 +0300
      Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-17 14:31 -0800
        Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-17 16:10 -0800
          Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 15:01 +0300
            Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-18 07:25 -0500
              Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-19 21:30 -0800
            Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-20 14:20 -0800
      Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:04 -0500
      Re: Pointer conversion and alignment Philipp Klaus Krause <pkk@spth.de> - 2018-11-18 14:18 +0100
      Re: Pointer conversion and alignment scott@slp53.sl.home (Scott Lurndal) - 2018-11-18 19:49 +0000
    Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-23 18:27 -0800
      Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-23 21:59 -0500
        Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-24 00:32 -0800
          Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-24 08:17 -0500
            Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 09:55 -0800
              Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-29 21:48 -0500
                Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-05 04:14 -0800
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-05 08:14 -0500
                Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-05 05:29 -0800
                Re: Pointer conversion and alignment David Brown <david.brown@hesbynett.no> - 2018-12-05 14:44 +0100
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-05 21:58 -0500
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-05 16:38 +0300
                Re: Pointer conversion and alignment scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 14:23 +0000
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-05 14:35 -0800
                Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-08 19:28 -0800
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 08:18 -0500
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 14:35 -0500
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-09 14:04 -0800
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 20:40 -0500
                Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-17 07:18 -0800
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-17 12:35 -0800
                Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-17 12:48 -0800
      Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-24 18:33 -0800
  My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-19 02:26 +0300
    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 11:08 +0000
      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 15:37 +0300
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 15:39 +0300
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 15:07 +0000
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-19 22:24 +0300
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 12:33 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:34 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 14:38 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-20 00:43 +0000
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-19 21:44 -0500
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jadill33@gmail.com - 2018-11-20 07:11 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] bart4858@gmail.com - 2018-11-20 10:02 -0800
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 22:20 +0000
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 14:01 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Melzzzzz <Melzzzzz@zzzzz.com> - 2018-11-20 11:07 +0000
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:12 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:15 -0500
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 23:08 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-20 14:13 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 16:38 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-21 09:05 -0500
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 20:28 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 12:58 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-22 01:47 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 15:50 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-24 19:37 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 21:22 +0000
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 01:15 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 15:06 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] mark.bluemel@gmail.com - 2018-11-19 08:05 -0800
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] scott@slp53.sl.home (Scott Lurndal) - 2018-11-19 16:49 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 10:35 -0800
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:45 +0300
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 14:24 -0800
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:05 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:31 -0500
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Richard Damon <Richard@Damon-Family.org> - 2018-11-20 20:02 -0500
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-21 22:47 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 13:08 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-22 00:31 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 21:36 +0000
      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 16:04 +0300
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 14:56 +0000
    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-24 19:24 +0300
      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-24 21:31 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-24 21:46 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 01:12 +0300
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-25 01:39 +0000
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 14:19 +0300
  Re: Pointer conversion and alignment jadill33@gmail.com - 2018-11-19 08:44 -0800
    Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:02 +0300
      Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-19 13:51 -0800
        Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 01:08 +0300
          Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-19 14:31 -0800
            Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:21 +0300
              Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:59 -0500
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-20 11:06 -0800
                Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-20 12:43 -0800
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-20 14:33 -0800
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 14:33 +0300
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-21 07:49 -0500
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-21 12:42 -0800
                Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-21 08:41 -0500
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 15:06 +0300
                Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-25 10:47 -0500
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-26 12:42 +0300
                Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 03:07 -0800
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-26 12:56 -0800
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-26 18:17 -0500
                Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 09:06 -0800
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-26 23:52 +0300
                Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 13:13 -0800
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-27 00:31 +0300
                Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 14:15 -0800
      Re: Pointer conversion and alignment jadill33@gmail.com - 2018-11-19 14:33 -0800

csiph-web