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

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

arranging items in a array with a sorted pointer-list

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

Contents

  arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 11:00 +0100
    Re: arranging items in a array with a sorted pointer-list Melzzzzz <Melzzzzz@zzzzz.com> - 2020-11-28 10:49 +0000
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 12:12 +0100
    Re: arranging items in a array with a sorted pointer-list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-28 03:21 -0800
      Re: arranging items in a array with a sorted pointer-list Richard Damon <Richard@Damon-Family.org> - 2020-11-28 08:32 -0500
        Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 14:49 +0100
          Re: arranging items in a array with a sorted pointer-list scott@slp53.sl.home (Scott Lurndal) - 2020-11-28 16:08 +0000
            Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 17:16 +0100
            Re: arranging items in a array with a sorted pointer-list Bart <bc@freeuk.com> - 2020-11-28 16:23 +0000
              Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 17:35 +0100
    Re: arranging items in a array with a sorted pointer-list "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-11-28 17:34 +0100
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 17:38 +0100
        Re: arranging items in a array with a sorted pointer-list Richard Damon <Richard@Damon-Family.org> - 2020-11-28 13:03 -0500
          Re: arranging items in a array with a sorted pointer-list Tim Woodall <news001@woodall.me.uk> - 2020-11-28 23:40 +0000
        Re: arranging items in a array with a sorted pointer-list Dolores Filandro <dolfiland8@gmail.com> - 2020-12-23 13:06 -0800
    Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-28 18:08 +0000
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-28 19:14 +0100
        Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-28 19:14 +0000
    Re: arranging items in a array with a sorted pointer-list Tim Woodall <news001@woodall.me.uk> - 2020-11-28 18:13 +0000
    Re: arranging items in a array with a sorted pointer-list Siri Cruise <chine.bleu@yahoo.com> - 2020-11-28 17:16 -0800
      Re: arranging items in a array with a sorted pointer-list Juha Nieminen <nospam@thanks.invalid> - 2020-11-29 09:41 +0000
        Re: arranging items in a array with a sorted pointer-list Siri Cruise <chine.bleu@yahoo.com> - 2020-11-29 02:16 -0800
          Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-29 18:32 +0000
          Re: arranging items in a array with a sorted pointer-list Juha Nieminen <nospam@thanks.invalid> - 2020-11-30 09:01 +0000
            Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-30 13:03 +0000
              Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-30 20:46 +0000
                Re: arranging items in a array with a sorted pointer-list scott@slp53.sl.home (Scott Lurndal) - 2020-11-30 21:03 +0000
                  Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-30 22:27 +0000
                    Re: arranging items in a array with a sorted pointer-list Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-11-30 18:14 -0700
                      Re: arranging items in a array with a sorted pointer-list James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-30 23:02 -0500
                      Re: arranging items in a array with a sorted pointer-list Dolores Filandro <dolfiland8@gmail.com> - 2020-11-30 20:12 -0800
                        Re: arranging items in a array with a sorted pointer-list scott@slp53.sl.home (Scott Lurndal) - 2020-12-01 15:04 +0000
                          Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-01 22:10 +0000
                            Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-01 22:25 +0000
                              Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-01 23:43 +0000
                            Re: arranging items in a array with a sorted pointer-list James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-01 23:25 -0500
                              Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-02 14:53 +0000
                                Re: arranging items in a array with a sorted pointer-list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-02 07:03 -0800
                                  Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-02 23:48 +0000
                                Re: arranging items in a array with a sorted pointer-list James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-02 11:13 -0500
                                  Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 05:34 -0800
                                Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-02 16:25 +0000
                                  Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-02 23:58 +0000
                                Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-03 21:16 -0800
                      Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-01 07:33 +0000
                        Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-01 03:46 -0800
                          Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-01 17:15 +0000
                            Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-04 00:17 -0800
                          Re: arranging items in a array with a sorted pointer-list Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-01 10:07 -0800
                            Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-13 11:06 -0800
                        Re: arranging items in a array with a sorted pointer-list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-01 07:04 -0800
                      Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-01 04:09 -0800
        Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-29 18:28 +0000
          Re: arranging items in a array with a sorted pointer-list dave_thompson_2@comcast.net - 2021-01-31 16:03 -0500
        Re: arranging items in a array with a sorted pointer-list Richard Damon <Richard@Damon-Family.org> - 2020-11-29 14:01 -0500
          Re: arranging items in a array with a sorted pointer-list Juha Nieminen <nospam@thanks.invalid> - 2020-11-30 09:05 +0000
            Re: arranging items in a array with a sorted pointer-list Richard Damon <Richard@Damon-Family.org> - 2020-11-30 07:09 -0500
            Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-30 13:06 +0000
              Re: arranging items in a array with a sorted pointer-list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-11-30 06:28 -0800
                Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-30 15:50 +0000
              Re: arranging items in a array with a sorted pointer-list James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-30 10:07 -0500
                Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-30 15:26 +0000
            Re: arranging items in a array with a sorted pointer-list James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-11-30 10:02 -0500
      Re: arranging items in a array with a sorted pointer-list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-11-29 12:32 +0000
        Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 18:58 -0800
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-29 13:52 +0100
        Re: arranging items in a array with a sorted pointer-list Dolores Filandro <dolfiland8@gmail.com> - 2020-12-23 13:56 -0800
    Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-28 23:41 -0800
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-05 12:23 +0100
        Re: arranging items in a array with a sorted pointer-list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 16:27 -0800
          Re: arranging items in a array with a sorted pointer-list David Brown <david.brown@hesbynett.no> - 2020-12-07 11:17 +0100
    Re: arranging items in a array with a sorted pointer-list Kaz Kylheku <563-365-8930@kylheku.com> - 2020-11-29 18:34 +0000
      Re: arranging items in a array with a sorted pointer-list Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-29 21:23 +0100
      Re: arranging items in a array with a sorted pointer-list Juha Nieminen <nospam@thanks.invalid> - 2020-11-30 09:10 +0000

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

#156803

In comp.lang.c++ Siri Cruise <chine.bleu@yahoo.com> wrote:
> This is my code
> 
>     int stringcompare ( /*String comparison for qsort.*/
>         const ptr a, const ptr b
>     ) {
>         char **A = a, **B = b;
>         return strcmp(*A, *B);
>     }

Ah, I love how in C you just implicitly cast from const void* to
non-const char** without a worry in the world, happily ignoring
the compiler warnings, because what does the compiler know anyway?
It's just a dumb program.

Also love how the comparator function is non-static, throwing it in the
global namespace. Better not have any other function with that name
anywhere else. But how likely is that? After all, "stringcompare" is
such a unique name. The chances that anybody will ever use that same
name anywhere are astronomically minuscule.

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

#156804

In article <rpvqc3$1cc$1@gioia.aioe.org>,
 Juha Nieminen <nospam@thanks.invalid> wrote:

> Ah, I love how in C you just implicitly cast from const void* to

I love how in C++ you have a billion names of cast. Even for a 
strong coercion.

> Also love how the comparator function is non-static, throwing it in the
> global namespace. Better not have any other function with that name

Yeah, because it's impossible to decorate the code if you use it.

> anywhere else. But how likely is that? After all, "stringcompare" is
> such a unique name. The chances that anybody will ever use that same
> name anywhere are astronomically minuscule.

Yeah, because it's not like the original names are different, 
part of collection of qsort utilities, only changed here for 
didactism.

Fuck off, child.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#156813

On 2020-11-29, Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <rpvqc3$1cc$1@gioia.aioe.org>,
>  Juha Nieminen <nospam@thanks.invalid> wrote:
>
>> Ah, I love how in C you just implicitly cast from const void* to
>
> I love how in C++ you have a billion names of cast. Even for a 
> strong coercion.

I love how you can wrap the C++ casts behind macros, and then
take advantage of them in code that compiles as C or C++:

  #ifdef __cplusplus
  #define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
  #define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
  #define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
  #else
  #define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
  #define convert(TYPE, EXPR) ((TYPE) (EXPR))
  #define coerce(TYPE, EXPR) ((TYPE) (EXPR))
  #endif

The GNU C++ compiler has a -Wold-style-cast warning option to find
places in your code where you're neglecting to use these macros.

Compile the code as C++, and the macros will catch issues, like some
change in the code that suddenly causes a convert(X, Y) call to suddenly
be stripping away a qualifier.

-- 
TXR Programming Language: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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

#156822

In comp.lang.c++ Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <rpvqc3$1cc$1@gioia.aioe.org>,
>  Juha Nieminen <nospam@thanks.invalid> wrote:
> 
>> Ah, I love how in C you just implicitly cast from const void* to
> 
> I love how in C++ you have a billion names of cast. Even for a 
> strong coercion.

At least C++ doesn't allow you to *implicitly* cast away constness.
You can do it, but you have to do it *explicitly*, so your intent
is clear. This diminishes the possibility of bugs that happen because
of the UB caused by trying to modify const data.

> Fuck off, child.

Excellent mature argument. I'm convinced.

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

#156826

Juha Nieminen <nospam@thanks.invalid> writes:

> At least C++ doesn't allow you to *implicitly* cast away constness.
> You can do it, but you have to do it *explicitly*, so your intent
> is clear.

Well C does not allow it either, in the sense that it is a fault that
must be diagnosed.  C compilers traditionally make that sort of a thing
a warning rather the a fatal error, but that's something that can be
fixed in the build set-up.

-- 
Ben.

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

#156834

On 2020-11-30, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>
>> At least C++ doesn't allow you to *implicitly* cast away constness.
>> You can do it, but you have to do it *explicitly*, so your intent
>> is clear.
>
> Well C does not allow it either, in the sense that it is a fault that
> must be diagnosed.  C compilers traditionally make that sort of a thing
> a warning rather the a fatal error, but that's something that can be
> fixed in the build set-up.

The issue is that in C, constness can inadvertantly be cast away
as an unintended casualty of a type conversion.

Or, more pertinently, not "in C", but "using a C cast" (which is
the only one we have in C).

   const void *ptr;

   int *intptr = (int *) ptr; // no diagnostic required

The static_cast we would use in C++ to convert void * to int *
will not remove qualifiers:

   int *intptr = static_cast<int *>(ptr); // diagnostic required

We need:

   int *intptr = static_cast<int *>(const_cast<void *>(ptr));

If these cast operators are used exclusively, then there is some
protection against certain mistakes.

-- 
TXR Programming Language: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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

#156836

Kaz Kylheku <563-365-8930@kylheku.com> writes:
>On 2020-11-30, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>
>>> At least C++ doesn't allow you to *implicitly* cast away constness.
>>> You can do it, but you have to do it *explicitly*, so your intent
>>> is clear.
>>
>> Well C does not allow it either, in the sense that it is a fault that
>> must be diagnosed.  C compilers traditionally make that sort of a thing
>> a warning rather the a fatal error, but that's something that can be
>> fixed in the build set-up.
>
>The issue is that in C, constness can inadvertantly be cast away
>as an unintended casualty of a type conversion.

One could argue that it cannot be "inadvertantly", as the programmer
must write the cast in the first place.  One could argue that some
C programmers don't understand 'constness', but that just means they
shouldn't be writing C programs :-).

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

#156837

On 2020-11-30, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>On 2020-11-30, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Juha Nieminen <nospam@thanks.invalid> writes:
>>>
>>>> At least C++ doesn't allow you to *implicitly* cast away constness.
>>>> You can do it, but you have to do it *explicitly*, so your intent
>>>> is clear.
>>>
>>> Well C does not allow it either, in the sense that it is a fault that
>>> must be diagnosed.  C compilers traditionally make that sort of a thing
>>> a warning rather the a fatal error, but that's something that can be
>>> fixed in the build set-up.
>>
>>The issue is that in C, constness can inadvertantly be cast away
>>as an unintended casualty of a type conversion.
>
> One could argue that it cannot be "inadvertantly", as the programmer
> must write the cast in the first place.

It can be the case that at the time the cast is written, there is no
const qualifier being cast away. The accident occurs when someone
later introduces const, and that cast now silently subverts it.

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

#156838

Kaz Kylheku <563-365-8930@kylheku.com> writes:
>
> It can be the case that at the time the cast is written, there is no
> const qualifier being cast away. The accident occurs when someone
> later introduces const, and that cast now silently subverts it.

Raising a question -- what would have been the downside (note that I'm
recognizing it's Too Late, just Monday morning quarterbacking), when
const was added to the language, to defining the cast so it doesn't
throw the const away?

ie if you had a

    const int x;
    
and cast it with
    (char) x

having x then treated as type

    const char

My immediate intuition is that there is no case in which one would want
to throw a const away with a cast, and this would have been a better
choice.

Thoughts?

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

#156839

On 11/30/20 8:14 PM, Joe Pfeiffer wrote:
...
> Raising a question -- what would have been the downside (note that I'm
> recognizing it's Too Late, just Monday morning quarterbacking), when
> const was added to the language, to defining the cast so it doesn't
> throw the const away?
> 
> ie if you had a
> 
>     const int x;
>     
> and cast it with
>     (char) x
> 
> having x then treated as type
> 
>     const char
> 
> My immediate intuition is that there is no case in which one would want
> to throw a const away with a cast, 

The most common reason I'm aware of for throwing away const (in my
experience, the only legitimate reason) is to interface with third-party
library routines whose interfaces were defined without using 'const' in
places where it should have been used. For example, the library might
have a function declared as

    int get_age(struct employee*);

which doesn't actually modify anything in the object it's parameter
points at. That parameter should, therefore, have been declared "const
struct employee *", but it wasn't. Since I don't have the option of
correcting that error, if I have

    const struct employee *manager = get_manager(this_employee);

then I have to use get_age((struct employee*)manager).
It's been three decades since K&R C was replaced by C90, so this issue
should have disappeared by now, but there's still a fair number of
programmers out there who refuse to use 'const' properly.

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

#156840

On Monday, November 30, 2020 at 8:14:41 PM UTC-5, Joe Pfeiffer wrote:

> My immediate intuition is that there is no case in which one would want 
> to throw a const away with a cast, and this would have been a better 
> choice. 
> 
> Thoughts?

You need to throw const away with a cast
if you want to write the bsearch function in C.

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

#156846

Dolores Filandro <dolfiland8@gmail.com> writes:
>On Monday, November 30, 2020 at 8:14:41 PM UTC-5, Joe Pfeiffer wrote:
>
>> My immediate intuition is that there is no case in which one would want 
>> to throw a const away with a cast, and this would have been a better 
>> choice. 
>> 
>> Thoughts?
>
>You need to throw const away with a cast
>if you want to write the bsearch function in C.

If they had changed the C standard as Joe suggested, they would
likely have added a bsearch_const() function (or possibly changed
the bsearch prototype to include const).

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

#156856

scott@slp53.sl.home (Scott Lurndal) writes:

> Dolores Filandro <dolfiland8@gmail.com> writes:
>>On Monday, November 30, 2020 at 8:14:41 PM UTC-5, Joe Pfeiffer wrote:
>>
>>> My immediate intuition is that there is no case in which one would want 
>>> to throw a const away with a cast, and this would have been a better 
>>> choice. 
>>> 
>>> Thoughts?
>>
>>You need to throw const away with a cast
>>if you want to write the bsearch function in C.
>
> If they had changed the C standard as Joe suggested, they would
> likely have added a bsearch_const() function (or possibly changed
> the bsearch prototype to include const).

bsearch's prototype includes const everywhere one might expect.  There's
no apparent reason you'd have to cast away const to implement it.
Dolores Filandro is, quite likely, trolling.

-- 
Ben.

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

#156857

On 2020-12-01, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Dolores Filandro <dolfiland8@gmail.com> writes:
>>>On Monday, November 30, 2020 at 8:14:41 PM UTC-5, Joe Pfeiffer wrote:
>>>
>>>> My immediate intuition is that there is no case in which one would want 
>>>> to throw a const away with a cast, and this would have been a better 
>>>> choice. 
>>>> 
>>>> Thoughts?
>>>
>>>You need to throw const away with a cast
>>>if you want to write the bsearch function in C.
>>
>> If they had changed the C standard as Joe suggested, they would
>> likely have added a bsearch_const() function (or possibly changed
>> the bsearch prototype to include const).
>
> bsearch's prototype includes const everywhere one might expect.  There's
> no apparent reason you'd have to cast away const to implement it.

> Dolores Filandro is, quite likely, trolling.

Or simply referring to bsearch returning an unqualified void *,
which, if the item is found, points into an array that comes into
the function as a const void * base pointer.

-- 
TXR Programming Language: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

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

#156858

Kaz Kylheku <563-365-8930@kylheku.com> writes:

> On 2020-12-01, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Dolores Filandro <dolfiland8@gmail.com> writes:
>>>>On Monday, November 30, 2020 at 8:14:41 PM UTC-5, Joe Pfeiffer wrote:
>>>>
>>>>> My immediate intuition is that there is no case in which one would want 
>>>>> to throw a const away with a cast, and this would have been a better 
>>>>> choice. 
>>>>> 
>>>>> Thoughts?
>>>>
>>>>You need to throw const away with a cast
>>>>if you want to write the bsearch function in C.
>>>
>>> If they had changed the C standard as Joe suggested, they would
>>> likely have added a bsearch_const() function (or possibly changed
>>> the bsearch prototype to include const).
>>
>> bsearch's prototype includes const everywhere one might expect.  There's
>> no apparent reason you'd have to cast away const to implement it.
>
>> Dolores Filandro is, quite likely, trolling.
>
> Or simply referring to bsearch returning an unqualified void *,
> which, if the item is found, points into an array that comes into
> the function as a const void * base pointer.

I suppose so, but then there are much simpler examples one could use to
make that case as you pointed out.  (It's not a case I would defend, but
that's not the issue here.)

-- 
Ben.

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

#156860

On 12/1/20 5:10 PM, Ben Bacarisse wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> Dolores Filandro <dolfiland8@gmail.com> writes:
...
>>> You need to throw const away with a cast
>>> if you want to write the bsearch function in C.
...
> bsearch's prototype includes const everywhere one might expect.

    void *bsearch(const void *key, const void *base,
         size_t nmemb, size_t size,
         int (*compar)(const void *, const void *));

> There's
> no apparent reason you'd have to cast away const to implement it.
> Dolores Filandro is, quite likely, trolling.

I'm pretty tired right now, so maybe I'm missing something obvious. If
written in C, how would bsearch() go about returning a void* when it's
arguments are const void*, without casting away const somewhere?

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

#156863

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 12/1/20 5:10 PM, Ben Bacarisse wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>> 
>>> Dolores Filandro <dolfiland8@gmail.com> writes:
> ...
>>>> You need to throw const away with a cast
>>>> if you want to write the bsearch function in C.
> ...
>> bsearch's prototype includes const everywhere one might expect.
>
>     void *bsearch(const void *key, const void *base,
>          size_t nmemb, size_t size,
>          int (*compar)(const void *, const void *));
>
>> There's
>> no apparent reason you'd have to cast away const to implement it.
>> Dolores Filandro is, quite likely, trolling.
>
> I'm pretty tired right now, so maybe I'm missing something obvious. If
> written in C, how would bsearch() go about returning a void* when it's
> arguments are const void*, without casting away const somewhere?

There are various ways, but as an old-timer, I like

  void *remove_const(s) void *s; { return s; }

and in bsearch

  return remove_const(ptr);

-- 
Ben.

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

#156864

On Wednesday, 2 December 2020 at 14:53:50 UTC, Ben Bacarisse wrote:
> James Kuyper <james...@alumni.caltech.edu> writes: 
> 
> > On 12/1/20 5:10 PM, Ben Bacarisse wrote: 
> >> sc...@slp53.sl.home (Scott Lurndal) writes: 
> >> 
> >>> Dolores Filandro <dolfi...@gmail.com> writes: 
> > ... 
> >>>> You need to throw const away with a cast 
> >>>> if you want to write the bsearch function in C. 
> > ... 
> >> bsearch's prototype includes const everywhere one might expect. 
> > 
> > void *bsearch(const void *key, const void *base, 
> > size_t nmemb, size_t size, 
> > int (*compar)(const void *, const void *)); 
> > 
> >> There's 
> >> no apparent reason you'd have to cast away const to implement it. 
> >> Dolores Filandro is, quite likely, trolling. 
> > 
> > I'm pretty tired right now, so maybe I'm missing something obvious. If 
> > written in C, how would bsearch() go about returning a void* when it's 
> > arguments are const void*, without casting away const somewhere?
> There are various ways, but as an old-timer, I like 
> 
> void *remove_const(s) void *s; { return s; } 
> 
> and in bsearch 
> 
> return remove_const(ptr); 
> 
Does the old style declaration suppress the const warning?

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

#156883

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 2 December 2020 at 14:53:50 UTC, Ben Bacarisse wrote:
>> James Kuyper <james...@alumni.caltech.edu> writes: 
>> 
>> > On 12/1/20 5:10 PM, Ben Bacarisse wrote: 
>> >> sc...@slp53.sl.home (Scott Lurndal) writes: 
>> >> 
>> >>> Dolores Filandro <dolfi...@gmail.com> writes: 
>> > ... 
>> >>>> You need to throw const away with a cast 
>> >>>> if you want to write the bsearch function in C. 
>> > ... 
>> >> bsearch's prototype includes const everywhere one might expect. 
>> > 
>> > void *bsearch(const void *key, const void *base, 
>> > size_t nmemb, size_t size, 
>> > int (*compar)(const void *, const void *)); 
>> > 
>> >> There's 
>> >> no apparent reason you'd have to cast away const to implement it. 
>> >> Dolores Filandro is, quite likely, trolling. 
>> > 
>> > I'm pretty tired right now, so maybe I'm missing something obvious. If 
>> > written in C, how would bsearch() go about returning a void* when it's 
>> > arguments are const void*, without casting away const somewhere?
>> There are various ways, but as an old-timer, I like 
>> 
>> void *remove_const(s) void *s; { return s; } 
>> 
>> and in bsearch 
>> 
>> return remove_const(ptr); 
>> 
> Does the old style declaration suppress the const warning?

That's an odd question because you can probably answer that better than
I can since you know what compilers you care about.

-- 
Ben.

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

#156865

On 12/2/20 9:53 AM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
>> I'm pretty tired right now, so maybe I'm missing something obvious. If
>> written in C, how would bsearch() go about returning a void* when it's
>> arguments are const void*, without casting away const somewhere?
> 
> There are various ways, but as an old-timer,

I definitely qualify as an old-time; I remember what C was like before
prototypes were added to the language. They were an enormous improvement.

>  I like

I definitely don't like leaving out a function prototype, particularly
when the only reason for doing so is to disable the type checking
enabled by the prototype.

>   void *remove_const(s) void *s; { return s; }
> 
> and in bsearch
> 
>   return remove_const(ptr);

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

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

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

csiph-web