🚀 go-pugleaf

jamie@csd.uwo.ca (J. Blustein) writes:

>  ANNOTATIONS ON K&R II
>    
>    Clarifications
>    
>     p. 6                   main() requires a return (see p. 26)

How about "main() without an explicit return returns an undefined value"?

>     p. 135                 As the text states: sizeof *x is the size of the
>                            pointer not the x being pointed to.

Do they write that? Sorry, I don't have K&R 2 at hand right now, but
this is _not_ true. Consider:

     char (* x)[20];
     char *y;

     "sizeof(*x)" is the size of an array of 20 chars, not the size of
     a pointer to such.
     "sizeof(*y)" is 1 even on machines where "sizeof(char *)" is not
     equal to 1.
 
Kurt
-- 
| Kurt Watzka                             Phone : +49-89-2180-6254
| watzka@stat.uni-muenchen.de

In article <4jq1eq$a3c@solutions.solon.com> J. Blustein <jamie@uwo.ca> wrote:
>    Clarifications
>    
>     p. 6                   main() requires a return (see p. 26)
    I should have written that main() should have a return.  I've also
found parts of page 164 useful here.


>    Cross-references
[...]
>     p. 42                  NULL is zero (see p. 102)
    That would make more sense as `NULL is equivalent to zero *in this
context*'.

    Thanks to Peter Seebach for pointing out my over-zealousness about
main()'s return.
-- 
Jamie Blustein                                         `Did you say "knives"?'
<jamie@uwo.ca>                                         `*Rotating* knives, yes.'

In article <4jq1eq$a3c@solutions.solon.com>, jamie@csd.uwo.ca says...

[ ... ]
>   ANNOTATIONS ON K&R II

>      p. 135                 As the text states: sizeof *x is the size of the
>                             pointer not the x being pointed to.

I think this bears a bit of clarification: given a definition something like:

something *x;

sizeof(*x);

does NOT give the size of a pointer at all, it gives the size of a `something'  
I think you're trying to say that it doesn't give the size of the block 
actually pointed to by `x', which is also true.  

>      p. 119                 Note that: 1) char * is not the same as void *
>                             and 2) this qsort() is not necessarily the same
>                             as the standard library's.  (I got these points
>                             from a comment on p. 229 (question 13.8) of
>                             Steve Summit's C Programming FAQs.)

While `char *' and `void *' are not the same, they are required to have the 
same representation.  (The general idea seems to be that if you pass one in 
place of the other, it probably shouldn't cause a problem, but they never 
quite state that explicitly.  I presume this was an attempt at enforcing 
compatibility with older libraries that expected a `char *' where a `void *' 
is now indicated.)
                     
>      p. 183                 <sys/types.h> does not define size_t. It is
>                             defined in <stddef.h> (pp. 260-1).

If memory serves, under POSIX, sys/types.h is required to define size_t as 
well.  sys/* are NOT defined by the C standard at all.  size_t is required to 
be defined in string.h, stdlib.h and time.h in addition to stddef.h, for what 
little it may be worth.
    Later,
    Jerry.

In article <4jr727$h6o@solutions.solon.com> Kurt Watzka
<watzka@stat.uni-muenchen.de> wrote:
>jamie@csd.uwo.ca (J. Blustein) writes:
[...]
>>     p. 135                 As the text states: sizeof *x is the size of the
>>                            pointer not the x being pointed to.
>
>Do they write that? Sorry, I don't have K&R 2 at hand right now, but
>this is _not_ true. Consider:

     That's right.  I think my note was based on a misunderstanding of
something else I read.  I have changed the annotation to `sizeof is better
defined in A7.4.8 on page 204'.
-- 
Jamie Blustein                                         `Did you say "knives"?'
<jamie@uwo.ca>                                         `*Rotating* knives, yes.'

jamie@csd.uwo.ca (J. Blustein) writes:
>     p. 255                 tm_sec: there can be as many as 2 leap seconds
>                         
>     p. 257                 %S: there can  be as many as 2 leap seconds
>                         
More precisely:  the C standards committee misunderstood the international
time standards and allowed for two leap seconds in the same minute.
There _can_ be two leap seconds in the same _year_, but
not in the same _minute_.

I've not yet had the good fortune to come across a C implementation that
bothers with leap seconds (if I've understood POSIX.1, a UNIX implementation
_mustn't_ get leap seconds right), so it's not that much of a problem.

-- 
Result of state election = 50% Victorians didn't get MP of their choice.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

In article <4jr73o$h87@solutions.solon.com>, jcoffin@rmii.com (Jerry Coffin) writes:

|> While `char *' and `void *' are not the same, they are required to have the 
|> same representation.  (The general idea seems to be that if you pass one in 
|> place of the other, it probably shouldn't cause a problem, but they never 
|> quite state that explicitly.  I presume this was an attempt at enforcing 
|> compatibility with older libraries that expected a `char *' where a `void *' 
|> is now indicated.)

My understanding is that a conversion to a (void *) followed by a conversion
to the original pointer type is the identity mapping; in other words, the mapping
a C compilers uses between (void *) and any other pointer type is bijective.
I don't know what you mean with representation; note however that
	T1 *p;
	*(T2 **) &p == (T2 *) p
is not necessarily true, even, I think, if T1 or T2 is void.

This is the reason why casting the comparison function argument
of qsort to a function of two void pointers even if the actual argument
is a function of two pointers to non-void is non-conforming, since the
compiler now has no place to insert the pointer-conversion code.

Konrad Schwarz

Konrad Schwarz (schwarz@mips.complang.tuwien.ac.at) wrote:

: My understanding is that a conversion to a (void *) followed by a conversion
: to the original pointer type is the identity mapping; in other words, the mapping
: a C compilers uses between (void *) and any other pointer type is bijective.
: I don't know what you mean with representation; note however that
: 	T1 *p;
: 	*(T2 **) &p == (T2 *) p
: is not necessarily true, even, I think, if T1 or T2 is void.

: This is the reason why casting the comparison function argument
: of qsort to a function of two void pointers even if the actual argument
: is a function of two pointers to non-void is non-conforming, since the
: compiler now has no place to insert the pointer-conversion code.

To be a bit more explicit on that point, since it's a bit subtle:

This isn't guaranteed to work (though it is how many people do it):

---
int compare(const int *x, const int *y) {
    return *x - *y;
}

...
/* This next line casts (int (*)(const int *, const int *)) to 
 * (int (*)(const void *, const void *))
 * which is _not_ the same as casting (void *) to (int *).
 * The compiler can't conceivably insert conversion code here, because the
 * function isn't being called, and there are no args to 'convert'.
 * qsort() can't do the conversion, because the original type has been
 * 'casted away' already.
 */
qsort(base, num, sizeof(int), (int (*)(const void *, const void *))compare);
---

As opposed to the following:

---
int compare (const void *px, const void *py) {
    int x = *(int*)px; /* these are (void*)->(int*) casts, which are */
    int y = *(int*)py; /* guaranteed to work.  If the pointers have */
	               /* different formats, the compiler _must_ insert */
		       /* conversion code here */
    return x - y;
}

...
/* Note no cast needed here, since compare is already of the right
type */
qsort(base, num, sizeof(int), compare);
---

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

Konrad Schwarz wrote:

[stuff left out]
> This is the reason why casting the comparison function argument
> of qsort to a function of two void pointers even if the actual argument
> is a function of two pointers to non-void is non-conforming, since the
> compiler now has no place to insert the pointer-conversion code.

I am not sure I understand this. Is that this code is illegal?

[Well, the //'s are illegal, because they're a syntax error... -mod]

int comp(const type* p1, const type* p2) {
	// logic here
}

type array[size];

qsort(array, sizeof(array)/sizeof(array[0]), sizeof(array[0]), 
(int(*)(const void*, const void*)) comp);

and that this is?

int comp(const void* p1, const void* p2) {

	// logic here with ((type*) p1) and ((type*) p2)
	
}

type array[size];

qsort(array, sizeof(array)/sizeof(array[0]), sizeof(array[0]), comp);



------------------------------------------------------------------
" When I use MS Word 6.0 on a PC  running windows 3.1 and DOS 6.0
 and write a normal plain english letter, The Tools/Languages ...
 option never works.  It never succeeded  in translating ( in any
 languages). This is a serious bug. "
------------------------------------------------------------------

schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz) writes:

>My understanding is that a conversion to a (void *) followed by a conversion
>to the original pointer type is the identity mapping; in other words, the
>mapping a C compilers uses between (void *) and any other pointer type is
>bijective.

It is not necessarily, the mapping from (useful*) to (void*) is not
required to be surjective, and the mapping from (void*) to (useful*)
is not required to be injective, except when restricted to the set of
(void*)s that points to objects with suitable alignment for useful's.
-- 

Henning Makholm - math and CS student - University of Copenhagen
makholm@diku.dk - http://www.diku.dk/students/makholm - fido 2:235/224.92

In article <4k60bd$aa1@solutions.solon.com>,
Jerry Coffin <jcoffin@rmii.com> wrote:
 >In article <4jv6o8$coj@solutions.solon.com>, 
 >schwarz@mips.complang.tuwien.ac.at says...
 >> 
 >> My understanding is that a conversion to a (void *) followed by a conversion
 >> to the original pointer type is the identity mapping; in other words, the
 >> mapping a C compilers uses between (void *) and any other pointer type is
 >> bijective.
 >
 >Hmm...I'm not sure what "bijective" means (my dictionary doesn't include it) 
 >the basic idea here seems to be correct: "A pointer to any incomplete or 
 >object type may be converted to a pointer to void and back again; the result 
 >shall compare equal to the original pointer."  ($6.2.2.3)

Actually, he's mistaken about the "bijective" bit, the map is only
"injective". Bijective means the mapping is two-way on both domains,
ie a cast from a (Type *) to a (void *) can be cast back (true) _and_
that a cast from a (void *) to a (Type *) can be cast back (generally
false). (Since the mapping from (Type *) to (void *) is injective, it
follows that the mapping from (void *) to (Type *) is surjective.)

regards, ct