A curiosity...

A curiosity...

[mockturtle]

Dear all,
this is not a question, nor an announcement, but
just something that I discovered few days ago and
I would like to share with you.  I know you can
appreciate it.

Few days ago a formerly student of mine came to
ask me something about (C) threads.  She showed
me a tutorial she found somewhere (unfortunately
I do not know where, so I cannot give you any
reference).

In case you never used the pthread library, let me say
that in order to start a thread you use the function

pthread_create (thread,attr,start,arg)

where
  thr     : opaque variable associated to the thread
  attr    :  thread attributes
  start  :  address of the function executed by the thread
  arg    :  parameter (void*) passed to the thread


In the tutorial they showed how to start several threads,
giving to each one its "ID" (an integer).  First they show
the wrong solution which was something

/*---- Begin Wrong --- */
void *thr_main(void *ID_pt)
{
    int my_ID = *(int *) ID_pt;
   /*--- other stuff... */
}

int main()
{
    int t;
    pthread_t th[10];

    for (t=0; t<10; t++)
     { pthread_create(th+t, NULL, thr_main, (void*) &t); }
}
/*---- End wrong ---*/

They say (correctly) that this is wrong since there is no
guarantee that the thread starts before t is incremented
again.  After the wrong solution they give the right one.

/*---- Begin Right --- */
void *thr_main(void *pt)
{
    int my_ID = (int) pt; /*!!!!!*/
   /*--- other stuff... */
}

int main()
{
    int t;
    pthread_t th[10];

    for (t=0; t<10; t++)
     { pthread_create(th+t, NULL, thr_main, (void*)  t); } /*!!!!!*/
}
/*---- End Right ---*/

In order to pass t "by value" they first convert it to
a pointer to void, then back to an integer...

Excuse me  while I turn the heat up... I suddenly
feel a chill down my spine.... ;-)

Re: A curiosity...

[Adam Beneschan]

On Dec 4, 12:47 pm, mockturtle <framefri...@gmail.com> wrote:

> Excuse me  while I turn the heat up... I suddenly
> feel a chill down my spine.... ;-)

Just in case that chill is starting to go away, please remember that
the kids who are learning C from tutorials like that today, are the
ones who will be writing the programs that go into automobiles and
airplanes and nuclear weapons in the next generation.  That chill
coming back yet?

Sorry about that.  :)  OK, maybe this will make you feel better:

int main()
{
    int t;
    pthread_t th[10];
    int args[10];

    for (t=0; t<10; t++) {
      args[t] = t;
      pthread_create(&th[t], NULL, thr_main, (void*) &args[t]); }
}

Ahhh, sanity at last...  (Or at least as much as you can expect from
C...)

                                 -- Adam

Re: A curiosity...

[Hyman Rosen]

Adam Beneschan wrote:
> Ahhh, sanity at last...

In fact, that "chilling" code wasn't really bad. It's just that
pthread_create gets a void * final parameter which it passes along
as an argument to the thread function it starts. The tutorial code
wants to pass in a plain integer, so it casts the integer into a
pointer so that it can pass it to pthread_create and then the thread
routine casts it back to an integer.

On any conventional architecture, casting a small integer to pointer
and back will leave its value unchanged, and the ability to do this
very common in C compilers and has been for decades.

Re: A curiosity...

[Ludovic Brenta]

On Dec 4, 10:48 pm, Hyman Rosen <hyro...@mail.com> wrote:
> Adam Beneschan wrote:
> > Ahhh, sanity at last...
>
> In fact, that "chilling" code wasn't really bad. It's just that
> pthread_create gets a void * final parameter which it passes along
> as an argument to the thread function it starts. The tutorial code
> wants to pass in a plain integer, so it casts the integer into a
> pointer so that it can pass it to pthread_create and then the thread
> routine casts it back to an integer.
>
> On any conventional architecture, casting a small integer to pointer
> and back will leave its value unchanged, and the ability to do this
> very common in C compilers and has been for decades.

Yes. In fact, C requires that pointers and integers be interchangable
so as to make address arithmetic "transparent" and extremely
dangerous. That's why, instead of writing "&th[t]" as Adam did, they
wrote "th+t" and thought themselves clever.

I'm glad I no longer program in C or C++.

--
Ludovic Brenta.

Re: A curiosity...

[Ludovic Brenta]

Ludovic Brenta wrote:
> Yes. In fact, C requires that pointers and integers be interchangable
> so as to make address arithmetic "transparent" and extremely
> dangerous. That's why, instead of writing "&th[t]" as Adam did, they
> wrote "th+t" and thought themselves clever.

And I think this rule is responsible for the "limitation" that all
current processor architectures use addresses which are the same size
as integers. Before the advent of C, address size and word size were
not necessarily the same; now they always are, and that's *only* for
compatibility with C.

Nowadays, computers are moving towards non-uniform memory
architectures (e.g. main memory, video memory, network interface cache
memory, physics processor memory, etc.) which would map extremely well
to Ada's storage pools and very poorly with C's pointer arithmetic.

--
Ludovic Brenta.

Re: A curiosity...

[Hyman Rosen]

Ludovic Brenta wrote:
> Yes. In fact, C requires that pointers and integers be interchangable
> so as to make address arithmetic "transparent" and extremely
> dangerous. That's why, instead of writing "&th[t]" as Adam did, they
> wrote "th+t" and thought themselves clever.

That's completely false. The expression 'th + t' exhibits two features of C,
neither of which involves pointers and integers being interchangeable. The
first is that in an expression, a value of type 'array of T' converts to the
type 'pointer to T' with value 'address of first element of that array'. The
second is that adding integers to pointers is equivalent to indexing; given
a pointer to an element of an array, adding or subtracting a number from it
results in a pointer pointing to another element of the array.

Re: A curiosity...

[Hyman Rosen]

Ludovic Brenta wrote:
> And I think this rule is responsible for the "limitation" that all
> current processor architectures use addresses which are the same size
> as integers. Before the advent of C, address size and word size were
> not necessarily the same; now they always are, and that's *only* for
> compatibility with C.

No such limitation exists. In fact, for many years C compilers on the
Intel x86 architecture used 16-bit integers and 32-bit pointers.

> map extremely well to Ada's storage pools and very poorly with C's
 > pointer arithmetic.

C's pointer arithmetic exists only within the confines of a single
array. Unless your Ada storage pools are planning to allocate single
objects with memory spanning separate devices, C's pointer arithmetic
model will be just fine.

Re: A curiosity...

[Randy Brukardt]

"mockturtle" <framefritti@gmail.com> wrote in message 
news:a88dafcc-04d0-4a46-a168-7cb034894181@k41g2000yqn.googlegroups.com...
...
> Few days ago a formerly student of mine came to
> ask me something about (C) threads.  She showed
> me a tutorial she found somewhere (unfortunately
> I do not know where, so I cannot give you any
> reference).
...
> Excuse me  while I turn the heat up... I suddenly
> feel a chill down my spine.... ;-)

I thought you were going to show her (and us) the proper Ada way to do this.

Otherwise, I think I'm missing your point. Every C-language interface that 
I've every used (the most important being Win32) is full of hacks to get 
around strong typing. This isn't news, or even a reflection on the C 
language itself. Claw is full of similar hacks (in Ada!) in order to use 
Win32 properly.

The best thing to do with almost any C-language interface is to wrap it as 
thickly as possible to cover up as much as possible of that cruft. That's 
irrespective of the implementation language (why do you think MFC was so 
widely used??). Perhaps C programmers are so used to cruft that they fail to 
abstract it away properly, but that reflects more on the programmers (and 
the culture that they work it) than the language.

                                             Randy.

Re: A curiosity...

[Hyman Rosen]

Randy Brukardt wrote:
> Every C-language interface that I've every used is
 > full of hacks to get around strong typing.
 > ...
 > Perhaps C programmers are so used to cruft that they
 > fail to abstract it away properly, but that reflects
 > more on the programmers (and the culture that they
 > work it) than the language.

I don't think that's particularly fair, or right.
The main issue that the sample exposes is that when
you have a library which needs to accept user objects
and pass them back into user code, it's going to be
difficult to define the interface properly without a
lot of mechanism.

It really is the case that all pthread_create wants
to do with that pointer is hand it back once it starts
the thread. I expect that in modern C++, this would
get wrapped in template code to make sure that the
type of the pointer passed matches the argument type
of the thread function, and I guess Ada would use
generics similarly, but in a C interface, you just do
the cast and leave it at that.

Re: A curiosity...

[Samuel Tardieu]

>>>>> "Ludovic" == Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

Ludovic> And I think this rule is responsible for the "limitation"
Ludovic> that all current processor architectures use addresses which
Ludovic> are the same size as integers. Before the advent of C,
Ludovic> address size and word size were not necessarily the same; now
Ludovic> they always are, and that's *only* for compatibility with C.

Certainly not. For example, on a x86_64 Linux machine with GCC, you
can try the following snippet (untested):

#include <stdio.h>
int main()
{
  printf("integer size is %d, pointer size is %d\n",
         sizeof(int), sizeof(void*));
  return 0;
}

You should get respectively 4 and 8.

Ludovic> Nowadays, computers are moving towards non-uniform memory
Ludovic> architectures (e.g. main memory, video memory, network
Ludovic> interface cache memory, physics processor memory, etc.) which
Ludovic> would map extremely well to Ada's storage pools and very
Ludovic> poorly with C's pointer arithmetic.

Nah, this is a FUD. If you want to use an integer type in C which is
compatible with addresses, you should use "size_t" explicitely, not
any other integer type (though I know of no architecture where
"unsigned long" is not the same as "size_t" even though this is
allowed).

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: A curiosity...

[Georg Bauhaus]

Ludovic Brenta wrote:

> Yes. In fact, C requires that pointers and integers be interchangable
> so as to make address arithmetic "transparent" and extremely
> dangerous.

Uhm, not interchangeable has been pointed out; this also seems
to be reflected in how Interfaces.C.Pointers is made. To me, a more
significant difference is that we do have more predefined mechanism
around Ada arrays. th + 100 is defined in C, it needs
not designate an element of an allocated array, though
(being off bounds, off the intended cell, whatever ...).
and this is not checked. You get erroneous execution,
or some kind of violation will kill the program if 100 happens
to be too much.  (C programmers might feel that they are
more skilled when they do not rely on what they might call a cane:
array bounds checking at run time, as is done in Ada and
in C++/STL (with .at)... "The C language is alright, just pick
real programmers!" is what I have heard now and then.)

When you implement an Ada storage pool, can you rely
on an Ada array to be mapped linearly to the sequence
of hardware addresses?  Is this important?

Re: A curiosity...

[Peter C. Chapin]

Samuel Tardieu wrote:

> Nah, this is a FUD. If you want to use an integer type in C which is
> compatible with addresses, you should use "size_t" explicitely, not
> any other integer type (though I know of no architecture where
> "unsigned long" is not the same as "size_t" even though this is
> allowed).

Section 17.18.1.4 of the C99 standard defines the type intptr_t and
uintptr_t as follows:

<QUOTE>
The following type designates a signed integer type with the property
that any valid pointer to void can be converted to this type, then
converted back to pointer to void, and the result will compare equal to
the original pointer:

intptr_t

The following type designates an unsigned integer type with the property
that any valid pointer to void can be converted to this type, then
converted back to pointer to void, and the result will compare equal to
the original pointer:

uintptr_t

These types are optional.
</QUOTE>

These types were introduced, I expect, because so many people feel a
need to convert pointers into integers and back again, yet the older C
standard did not provide a portable way of doing that. Note, however,
that these types are optional. Note also that the OP's example actually
requires the opposite of what is provided here. The OP's example depends
on converting an integer to a pointer and back again without loss of
information... the types above might not support that (they might be too
long to fit into a pointer).

Peter

Re: A curiosity...

[Martin Krischik]

Am 05.12.2008, 09:02 Uhr, schrieb Samuel Tardieu <sam@rfc1149.net>:

> #include <stdio.h>
> int main()
> {
>   printf("integer size is %d, pointer size is %d\n",
>          sizeof(int), sizeof(void*));
>   return 0;
> }

Of course my copy ISO C standart states that only intptr_t and uintptr_t  
*need* to be lange enough to hold a pointer. The real problem is that most  
C programmers don't know that. Which gets us back to the "C is alright -  
just get better programmers". Only: realy good C programmers are just as  
scares as Ada progammers.

Martin

-- 
Martin Krischik

Re: A curiosity...

[Hyman Rosen]

Martin Krischik wrote:
> The real problem is that most C programmers don't know that.

The semantics of conversion between pointer and integer are
defined by the implementation. There's no law that says that
C programs must be written to be portable. It's acceptable
to use implementation-specific behavior and knowledge of the
architecture if that's what you want, especially when the
architectures that are different enough to matter are as rare
as hen's teeth.

No argument, though, that C and C++ ate unsafe by default.

Re: A curiosity...

[Keith Thompson]

Samuel Tardieu <sam@rfc1149.net> writes:
>>>>>> "Ludovic" == Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> Ludovic> And I think this rule is responsible for the "limitation"
> Ludovic> that all current processor architectures use addresses which
> Ludovic> are the same size as integers. Before the advent of C,
> Ludovic> address size and word size were not necessarily the same; now
> Ludovic> they always are, and that's *only* for compatibility with C.
>
> Certainly not. For example, on a x86_64 Linux machine with GCC, you
> can try the following snippet (untested):
>
> #include <stdio.h>
> int main()
> {
>   printf("integer size is %d, pointer size is %d\n",
>          sizeof(int), sizeof(void*));
>   return 0;
> }
>
> You should get respectively 4 and 8.
[...]

You get undefined behavior, since "%d" expects an argument of type int
and you're giving it an argument of type size_t.  And on the system in
question, it's very likely that size_t is bigger than int, so this
could cause real problems.

    printf("integer size is %lu, pointer size is %lu\n",
           (unsigned long)sizeof(int), (unsigned long)sizeof(void*));

or, in C99:

    printf("integer size is %zu, pointer size is %zu\n",
           sizeof(int), sizeof(void*));

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: A curiosity...

[Keith Thompson]

Hyman Rosen <hyrosen@mail.com> writes:
> Randy Brukardt wrote:
>> Every C-language interface that I've every used is
>> full of hacks to get around strong typing.
>> ...
>> Perhaps C programmers are so used to cruft that they
>> fail to abstract it away properly, but that reflects
>> more on the programmers (and the culture that they
>> work it) than the language.
>
> I don't think that's particularly fair, or right.
> The main issue that the sample exposes is that when
> you have a library which needs to accept user objects
> and pass them back into user code, it's going to be
> difficult to define the interface properly without a
> lot of mechanism.
>
> It really is the case that all pthread_create wants
> to do with that pointer is hand it back once it starts
> the thread. I expect that in modern C++, this would
> get wrapped in template code to make sure that the
> type of the pointer passed matches the argument type
> of the thread function, and I guess Ada would use
> generics similarly, but in a C interface, you just do
> the cast and leave it at that.

Except that there's no guarantee in C that converting an int to void*
and back again will yield the original int value.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: A curiosity...

[Hyman Rosen]

Keith Thompson wrote:
> Except that there's no guarantee in C that converting an int to void*
> and back again will yield the original int value.

There's a guarantee in your implementation's documentation.

Re: A curiosity...

[Keith Thompson]

Hyman Rosen <hyrosen@mail.com> writes:
> Keith Thompson wrote:
>> Except that there's no guarantee in C that converting an int to void*
>> and back again will yield the original int value.
>
> There's a guarantee in your implementation's documentation.

Maybe.  The result of converting an integer to a pointer type, or vice
versa, is implementation-defined, which means the implementation must
document it.  It's not at all clear what level of detail is required,
but you can *probably* determine whether it works the way you want.
Which it might not.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: A curiosity...

[Adam Beneschan]

On Dec 5, 12:20 pm, Keith Thompson <ks...@mib.org> wrote:
> Hyman Rosen <hyro...@mail.com> writes:
> > Keith Thompson wrote:
> >> Except that there's no guarantee in C that converting an int to void*
> >> and back again will yield the original int value.
>
> > There's a guarantee in your implementation's documentation.
>
> Maybe.  The result of converting an integer to a pointer type, or vice
> versa, is implementation-defined, which means the implementation must
> document it.  It's not at all clear what level of detail is required,
> but you can *probably* determine whether it works the way you want.
> Which it might not.

This thread started with a comment about a tutorial that showed
students the "right" way to accomplish a certain task.  What do you
want to bet that this tutorial didn't say "This works only for such-
and-such implementations", nor "Check your implementation's
documentation to make sure the size of the pointer and integer are the
same"---but rather, that it presented its solution as if this were the
right solution with no regard for the particular implementation, host,
or target?  And students are learning to program from resources like
this.

                                 -- Adam

Re: A curiosity...

[Peter C. Chapin]

Martin Krischik wrote:

> Only: realy good C programmers
> are just as scares as Ada progammers.

I know of one really good C programmer who is now an Ada programmer. His
reasons for switching to Ada are largely the same reasons that made him
really good in the first place. And... he's lucky enough to be working
in a job where he can choose the programming language he wants to use.

Peter

Re: A curiosity...

[Hyman Rosen]

Adam Beneschan wrote:
> This thread started with a comment about a tutorial that showed
> students the "right" way to accomplish a certain task.  What do you
> want to bet that this tutorial didn't say "This works only for such-
> and-such implementations"

The distinction between right and wrong that the tutorial
was making was about not having multiple threads access a
shared object because of unpredictable timing. I doubt that
there has ever been a C implementation on any architecture
where it was wrong to convert a small integer to pointer
and back.

Re: A curiosity...

[Gary Scott]

Hyman Rosen wrote:

> Adam Beneschan wrote:
> 
>> This thread started with a comment about a tutorial that showed
>> students the "right" way to accomplish a certain task.  What do you
>> want to bet that this tutorial didn't say "This works only for such-
>> and-such implementations"
> 
> 
> The distinction between right and wrong that the tutorial
> was making was about not having multiple threads access a
> shared object because of unpredictable timing. I doubt that
> there has ever been a C implementation on any architecture
> where it was wrong to convert a small integer to pointer
> and back.
Interesting, I never realized that there is this huge issue or 
controversy with shared memory/objects.  These techniques have been used 
for 50 years and there are well known ways to synchronize and/or 
structure data to avoid timing issues.  Of course some operating systems 
are better than others.  My experience is mostly with OS' that provide 
no assistance at all, so you may define a handshaking process into the 
data access process.

-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: A curiosity...

[Hyman Rosen]

Gary Scott wrote:
> Interesting, I never realized that there is this huge issue or 
> controversy with shared memory/objects.

The example showed the problem of accidentally sharing an
object when you don't mean to.