Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > OK folks, corrected

Reply
Thread Tools

OK folks, corrected

 
 
Richard Heathfield
Guest
Posts: n/a
 
      03-08-2008
santosh said:

> Richard Heathfield wrote:
>
>> Ian Collins said:
>>
>> <snip>
>>
>>> How can a non-standard function have defined semantics?

>>
>> By making it the fourth argument in a qsort call?

>
> Doesn't that constitute as just defining the interface?


No. The Standard defines the semantics (so much so that, if you provide
different semantics, the program's behaviour is undefined):

"The contents of the array are sorted in ascending order according
to a comparison function pointed to by compar , which is called with
two arguments that point to the objects being compared. The function
shall return an integer less than, equal to, or greater than zero if
the first argument is considered to be respectively less than, equal
to, or greater than the second."

Thus, the following function is non-standard:

int cmpint(const void *vp, const void *vq)
{
const int *p = vp;
const int *q = vq;
return (*p < *q) - (*p > *q);
}

....but if your program passes it to qsort, it has defined semantics which
it must not violate (or, rather, shall not violate).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      03-08-2008
Harald van D?k wrote:

> On Sat, 08 Mar 2008 15:05:05 +0530, santosh wrote:
>> Richard Heathfield wrote:
>>> Ian Collins said:
>>>> How can a non-standard function have defined semantics?
>>>
>>> By making it the fourth argument in a qsort call?

>>
>> Doesn't that constitute as just defining the interface?

>
> "The function shall return an integer less than, equal to, or greater
> than
> zero if the first argument is considered to be respectively less
> than, equal to, or greater than the second."
>
> Unrelated to the actual topic, but a question about qsort: is the
> behaviour defined if compar longjmps out of qsort when the two
> arguments are considered incomparable by the application? It needs
> some way to exit without returning an integer.


I think so, please correct me if I'm wrong; I have hardly ever used
setjmp and longjmp. However I would avoid this problem in the first
place, by perhaps ensuring that there are no incomparable elements in
the array, say something like NaN. Or I might special case the compare
function so that such "invalid" values always compare either above or
below all valid values.

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      03-08-2008
Richard Heathfield wrote:

> santosh said:
>
>> Richard Heathfield wrote:
>>
>>> Ian Collins said:
>>>
>>> <snip>
>>>
>>>> How can a non-standard function have defined semantics?
>>>
>>> By making it the fourth argument in a qsort call?

>>
>> Doesn't that constitute as just defining the interface?

>
> No. The Standard defines the semantics (so much so that, if you
> provide different semantics, the program's behaviour is undefined):
>
> "The contents of the array are sorted in ascending order according
> to a comparison function pointed to by compar , which is called with
> two arguments that point to the objects being compared. The function
> shall return an integer less than, equal to, or greater than zero if
> the first argument is considered to be respectively less than, equal
> to, or greater than the second."
>
> Thus, the following function is non-standard:
>
> int cmpint(const void *vp, const void *vq)
> {
> const int *p = vp;
> const int *q = vq;
> return (*p < *q) - (*p > *q);
> }
>
> ...but if your program passes it to qsort, it has defined semantics
> which it must not violate (or, rather, shall not violate).


Thanks. I didn't consider your careful mention of qsort, and instead
just thought that providing a prototype constitutes providing only an
interface.

 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      03-08-2008
On Sat, 08 Mar 2008 15:29:15 +0530, santosh wrote:
> Harald van D?k wrote:
>> Unrelated to the actual topic, but a question about qsort: is the
>> behaviour defined if compar longjmps out of qsort when the two
>> arguments are considered incomparable by the application? It needs some
>> way to exit without returning an integer.

>
> I think so, please correct me if I'm wrong; I have hardly ever used
> setjmp and longjmp.


I wasn't serious, but I'm pretty sure the behaviour's meant to be
undefined for such a case the same way as for a comparison function that
unconditionally returns 1. Neither actually violates 7.20.5p4, but that's
only because of sloppy wording, and if the sloppy wording is fixed in the
most obvious possible way (removing "That is,"), both functions would fail
to meet its requiremenets.

> However I would avoid this problem in the first
> place, by perhaps ensuring that there are no incomparable elements in
> the array, say something like NaN. Or I might special case the compare
> function so that such "invalid" values always compare either above or
> below all valid values.


Yes, that's really the only sensible thing to do.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-08-2008
santosh said:

<snip>

> Thanks. I didn't consider your careful mention of qsort, and instead
> just thought that providing a prototype constitutes providing only an
> interface.


Moving on, then, I don't think that a mere function prototype is sufficient
as an interface description. It's certainly /necessary/ (in style terms,
that is - one can simply do: int foo(); which is not a prototype, and let
the user guess the parameters!), but in my view one also needs to specify
the constraints that the caller must observe when calling the function.
For example, char *strcpy(char *target, const char *source) does not *on
its own* tell us that target must be a pointer to sufficient memory to
store a copy of the data starting at source, which must itself be a
null-terminated string. The compiler can't tell you that this code:

#include <string.h>
int main(void)
{
char target;
char source = 'X';
strcpy(&target, &source); /* NO! */
return 0;
}

is wrong.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-08-2008
Richard Heathfield wrote:

> santosh said:
>
> <snip>
>
>> Thanks. I didn't consider your careful mention of qsort, and instead
>> just thought that providing a prototype constitutes providing only an
>> interface.

>
> Moving on, then, I don't think that a mere function prototype is
> sufficient as an interface description. It's certainly /necessary/ (in
> style terms, that is - one can simply do: int foo(); which is not a
> prototype, and let the user guess the parameters!), but in my view one
> also needs to specify the constraints that the caller must observe
> when calling the function. For example, char *strcpy(char *target,
> const char *source) does not *on its own* tell us that target must be
> a pointer to sufficient memory to store a copy of the data starting at
> source, which must itself be a null-terminated string. The compiler
> can't tell you that this code:
>
> #include <string.h>
> int main(void)
> {
> char target;
> char source = 'X';
> strcpy(&target, &source); /* NO! */
> return 0;
> }
>
> is wrong.


Yes, good point. There is a continuum between the interface and the
semantics. For C functions the prototype with a description of
constraints on the arguments and the return value would constitute the
interface. The semantics might be a more deeper explanation of what the
function does, why it does it that way, and other similar details. A
good example, I suppose, is strtok.

But this is all just splitting hairs anyway.

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-08-2008
santosh said:

<snip>

> There is a continuum between the interface and the
> semantics. For C functions the prototype with a description of
> constraints on the arguments and the return value would constitute the
> interface. The semantics might be a more deeper explanation of what the
> function does, why it does it that way, and other similar details. A
> good example, I suppose, is strtok.
>
> But this is all just splitting hairs anyway.


Actually, I think it is a genuinely useful discussion (especially if it
prompts readers to think more carefully about how - or whether! - they
write their interface documentation).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-08-2008
Richard Heathfield <(E-Mail Removed)> writes:
> santosh said:
> <snip>
>
>> There is a continuum between the interface and the
>> semantics. For C functions the prototype with a description of
>> constraints on the arguments and the return value would constitute the
>> interface. The semantics might be a more deeper explanation of what the
>> function does, why it does it that way, and other similar details. A
>> good example, I suppose, is strtok.
>>
>> But this is all just splitting hairs anyway.

>
> Actually, I think it is a genuinely useful discussion (especially if it
> prompts readers to think more carefully about how - or whether! - they
> write their interface documentation).


I note that the "restrict" keyword makes it possible to squeeze
slightly more interface information into a prototype than you can
without it. A hypothetical new keyword that says a pointer must be
non-null might be something similar. But you can't completely
describe the interface in the language. A full-blown mechanism for
describing preconditions in code could come a lot closer, but I think
some natural-language documentation will always be necessary.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-09-2008
Keith Thompson wrote:
> I note that the "restrict" keyword makes it possible to squeeze
> slightly more interface information into a prototype than you can
> without it. A hypothetical new keyword that says a pointer must be
> non-null might be something similar.


In standard C you can say that a pointer is non null with

int function(int tab[static 1]);

tab must point to at least one element, hence it can't be NULL.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      03-09-2008
On Sun, 09 Mar 2008 01:14:38 +0100, jacob navia wrote:
> Keith Thompson wrote:
>> I note that the "restrict" keyword makes it possible to squeeze
>> slightly more interface information into a prototype than you can
>> without it. A hypothetical new keyword that says a pointer must be
>> non-null might be something similar.

>
> In standard C you can say that a pointer is non null with
>
> int function(int tab[static 1]);
>
> tab must point to at least one element, hence it can't be NULL.


True, but this also disallows other valid non-null pointer values from
being passed to that function, such as a pointer to the end of an array.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Received corrected DVD's for "Wiseguy: Between the Mob and a Hard Place" Film Buff DVD Video 0 04-18-2005 03:53 AM
Execute code after death of all child processes - (corrected posting) Markus Franz Python 2 12-28-2004 03:35 PM
Re: NEW MAINTAINER for Pymacs [corrected] =?iso-8859-1?Q?Fran=E7ois?= Pinard Python 2 09-24-2004 10:07 PM
BTTF--are corrected copies for sale yet Michael S. DVD Video 11 10-03-2003 03:39 PM
Corrected Jurassic Park? Rich Jackson DVD Video 4 09-14-2003 10:43 PM



Advertisments