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

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

memscan() function or equivalent

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

Contents

  memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 06:16 -0700
    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 15:47 +0200
      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:15 -0700
        Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:34 +0000
          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 07:42 -0700
            Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 14:45 +0000
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:07 -0700
                Re: memscan() function or equivalent jameskuyper@verizon.net - 2017-06-07 09:14 -0700
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:33 -0700
        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 16:48 +0200
          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:31 -0700
            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:37 +0200
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:47 -0700
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:02 +0200
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:09 -0700
                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:34 +0200
                      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:54 -0700
                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:01 +0200
                          Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:17 -0700
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 19:53 +0200
                        Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:15 -0700
                          Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:26 -0700
                            Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 22:56 -0700
                              Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-07 23:03 -0700
              Re: memscan() function or equivalent scott@slp53.sl.home (Scott Lurndal) - 2017-06-07 16:10 +0000
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:30 -0700
          Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 16:50 +0100
            Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 08:58 -0700
              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:03 -0700
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:07 -0700
                Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:30 +0100
                  Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:36 -0700
                    Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 17:48 +0100
                      Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 09:57 -0700
                      Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 05:54 +0000
                  Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 09:48 -0700
                    Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:55 +0100
                    Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-07 22:13 +0100
                      Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-07 16:02 -0700
                        Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 01:26 +0100
                          Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-08 13:00 +1200
                            Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-08 09:48 +0100
                        Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 08:52 +0200
              Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 10:00 -0700
                Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 10:13 -0700
                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 11:19 -0700
                    Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-07 11:27 -0700
              Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-07 21:18 +0100
            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 18:18 +0200
              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-07 21:15 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:16 +0200
                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 09:08 +0200
                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 09:56 +0200
                      Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 17:14 +0200
                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 17:38 +0200
                          Re: memscan() function or equivalent David Kleinecke <dkleinecke@gmail.com> - 2017-06-10 11:52 -0700
                            Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 20:03 +0100
                            Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-10 13:32 -0700
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-10 23:40 +0200
                              Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 00:53 +0300
                                Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 01:11 +0300
                                  Re: memscan() function or equivalent Ian Collins <ian-news@hotmail.com> - 2017-06-11 10:26 +1200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:32 +0200
                                      Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:05 +0200
                                        Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:06 +0200
                                        Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-11 13:19 -0700
                                    Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:17 +0300
                                Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-10 15:21 -0700
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:19 +0200
                                  Re: memscan() function or equivalent Anton Shepelev <anton.txt@gmail.com> - 2017-06-11 02:15 +0300
                                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:36 +0200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:46 +0200
                                Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-10 22:25 -0700
                              Re: memscan() function or equivalent "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-10 15:13 -0700
                              Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-10 23:21 +0100
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 00:28 +0200
                                  Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 10:56 +0100
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 13:27 +0200
                                      Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 13:19 +0100
                                    Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:36 +0000
                                      Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-11 20:22 +0100
                                        Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 06:09 +0000
                                          Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 10:38 +0100
                                            Re: memscan() function or equivalent asetofsymbols@gmail.com - 2017-06-12 05:30 -0700
                                            Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 13:51 +0000
                                              Re: memscan() function or equivalent bartc <bc@freeuk.com> - 2017-06-12 15:04 +0100
                                        Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-12 21:26 +0000
                              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 10:04 +0200
                                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:13 +0200
                                  Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:38 +0200
                                    Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 14:18 +0200
                                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-11 09:57 -0700
                                    Re: memscan() function or equivalent Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 17:18 +0000
                          Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 09:53 +0200
                            Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-11 10:00 +0200
                              Re: memscan() function or equivalent "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-11 13:41 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:24 +0200
                Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 21:55 +0200
            Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-07 20:54 +0100
              Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 23:00 +0200
                Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 08:16 +0100
                  Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 10:55 +0200
                    Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 11:44 +0100
                      Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 13:11 +0200
                        Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-08 13:45 +0100
                          Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-08 14:51 +0200
                  Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-08 08:00 -0700
            Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-09 12:26 -0700
              Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 07:24 +0100
                Re: memscan() function or equivalent Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-10 13:17 +0100
                  Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-10 17:18 +0100
                    Re: memscan() function or equivalent Ike Naar <ike@iceland.freeshell.org> - 2017-06-11 18:11 +0000
                Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-11 15:08 -0700
                  Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-12 18:34 +0100
                    Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-14 09:52 -0700
                      Re: memscan() function or equivalent Gareth Owen <gwowen@gmail.com> - 2017-06-14 19:56 +0100
                        Re: memscan() function or equivalent Keith Thompson <kst-u@mib.org> - 2017-06-14 12:20 -0700
                        Re: memscan() function or equivalent Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-17 06:37 -0700
                          Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-17 10:02 -0700
        Re: memscan() function or equivalent David Brown <david.brown@hesbynett.no> - 2017-06-07 16:51 +0200
          Re: memscan() function or equivalent GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-07 17:00 +0200
            Re: memscan() function or equivalent supercat@casperkitty.com - 2017-06-07 08:53 -0700

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

#111778

On 06/ 8/17 12:26 PM, bartc wrote:
> On 08/06/2017 00:02, Keith Thompson wrote:

>> If you're writing a C implementation, or part of one, this is the
>> kind of stuff you really need to know.
>
> What's in the headers really lies outside a C compiler proper, which
> knows about signed and unsigned, char, short, normal, long and long long
> versions of int. It doesn't know about size_t.
>
> And what's in real headers is a *lot* messier than the summary in the C
> standard. Little of that is to do with details of implementation, more
> like trying to paper over a lot of cracks so that they just about still
> work.

What is in "real" headers is what is required to get the implementation 
to work on all possible platforms and all possible conformance modes.

-- 
Ian

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

#111799

On 08/06/2017 02:00, Ian Collins wrote:
> On 06/ 8/17 12:26 PM, bartc wrote:
>> On 08/06/2017 00:02, Keith Thompson wrote:
> 
>>> If you're writing a C implementation, or part of one, this is the
>>> kind of stuff you really need to know.
>>
>> What's in the headers really lies outside a C compiler proper, which
>> knows about signed and unsigned, char, short, normal, long and long long
>> versions of int. It doesn't know about size_t.
>>
>> And what's in real headers is a *lot* messier than the summary in the C
>> standard. Little of that is to do with details of implementation, more
>> like trying to paper over a lot of cracks so that they just about still
>> work.
> 
> What is in "real" headers is what is required to get the implementation 
> to work on all possible platforms and all possible conformance modes.
> 


/All/ platforms and all modes?

I thought the point of having system headers segregated was just so 
there can be a specific set for each target (many of my C compilers do 
in fact come with separate 32- and 64-bit versions for example).

And it doesn't explain why there are so many time and stat headers.

Besides, I'm trying to write a set for ONE target, yet I have still have 
to provide all these extra ones because applications make use of them.

-- 
bartc

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

#111920

Le 08.06.2017 à 01:02, Keith Thompson a écrit :
> bartc <bc@freeuk.com> writes:
>> On 07/06/2017 17:48, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>>> [...]
>>>> One more thing with the C version: n is size_t so probably unsigned.
>>>
>>> "probably"?
>>
>> Yes, probably. It was easier to add that word than doing the research
>> needed to eliminate it.
> 
> size_t is an unsigned type.
> 
>> But in C, half of this stuff is defined within the standard headers,
>> 'conveniently' split up into dozens of separate files (with the language
>> requiring that there are half a dozen ?time.h or time?.h headers all
>> redefining the same things).
> 
> No, the standard defines exactly one header named <time.h>.  No other
> standard header has the string "time" in its name.  (A particular
> implementation or a separate standard like POSIX might define other
> headers such as <sys/time.h>.  Some such headers might be intended
> to be included in user code, others might exist only to implement
> the standard headers.)
> 
> size_t is defined in <stddef.h> and in several other standard headers
> that need to refer to it.
> 
>> Each header can be optionally included, presumably so custom versions
>> can be used, ones where 'size_t' might be signed.
> 
> I suppose it would be possible for some implementation-specific
> header to define "size_t" as a signed type, but it would be
> stupid (since such a header could not be used along with any of
> the standard headers that define size_t), and I don't believe any
> actual implementation would do so.

size_t is a special type in C. It is a type that violates abstraction 
layers because it is _defined_ in the headers but is the type returned 
by an operator of the compiler `sizeof`. So the definition of size_t 
must be adjusted to the result of sizeof by the compiler provider.

The C99 standard says:
6.5.3.4 The sizeof operator
Constraints
[...]
4 The value of the result is implementation-defined, and its type (an 
unsigned integer type)
is size_t, defined in <stddef.h> (and other headers).

> 
> If you're writing a C implementation, or part of one, this is the
> kind of stuff you really need to know.
> 
Definitely.

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

#111732

On Wednesday, June 7, 2017 at 10:58:58 AM UTC-5, Rick C. Hodgin wrote:
> Why are you (or is C) opposed to using const char * parameters, or
> char parameters?  Why use the conversion / translation in local
> variable space?

Functions named "mem*" are generally expected to be suitable for use with
data of arbitrary type.  If a mem* function uses a parameter of type "char*"
but 100 different callers need it to operate on anything of a different
known type, each of those those 100 callers would have to include a pointer
cast.  Including a cast in the function along with the "extra" variable (that
even a relatively simple optimizer could eliminate) would eliminate the need
for 100 casts elsewhere in the code.

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

#111734

On Wednesday, June 7, 2017 at 1:00:59 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, June 7, 2017 at 10:58:58 AM UTC-5, Rick C. Hodgin wrote:
> > Why are you (or is C) opposed to using const char * parameters, or
> > char parameters?  Why use the conversion / translation in local
> > variable space?
> 
> Functions named "mem*" are generally expected to be suitable for use with
> data of arbitrary type.  If a mem* function uses a parameter of type "char*"
> but 100 different callers need it to operate on anything of a different
> known type, each of those those 100 callers would have to include a pointer
> cast.  Including a cast in the function along with the "extra" variable (that
> even a relatively simple optimizer could eliminate) would eliminate the need
> for 100 casts elsewhere in the code.

The function is designed to take memory of arbitrary types, however,
and search them for a character, right?

So ... I don't see it other than possibly the convention to allow a
void * reference so it indicates non-predilection.  But even then,
it is a character scan function, so ... I'm only 38% convinced.

Thank you,
Rick C. Hodgin

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

#111738

On Wednesday, June 7, 2017 at 12:14:14 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, June 7, 2017 at 1:00:59 PM UTC-4, supe...@casperkitty.com wrote:
> > On Wednesday, June 7, 2017 at 10:58:58 AM UTC-5, Rick C. Hodgin wrote:
> > > Why are you (or is C) opposed to using const char * parameters, or
> > > char parameters?  Why use the conversion / translation in local
> > > variable space?
> > 
> > Functions named "mem*" are generally expected to be suitable for use with
> > data of arbitrary type.  If a mem* function uses a parameter of type "char*"
> > but 100 different callers need it to operate on anything of a different
> > known type, each of those those 100 callers would have to include a pointer
> > cast.  Including a cast in the function along with the "extra" variable (that
> > even a relatively simple optimizer could eliminate) would eliminate the need
> > for 100 casts elsewhere in the code.
> 
> The function is designed to take memory of arbitrary types, however,
> and search them for a character, right?
> 
> So ... I don't see it other than possibly the convention to allow a
> void * reference so it indicates non-predilection.  But even then,
> it is a character scan function, so ... I'm only 38% convinced.

If C had a pointer type that would behave like a char*, but which was
intended to access the contents of objects identified by pointers of
other types, and thus allowed implicit casting, such a type would be
more appropriate than void* in most cases where the latter is used.
Such a type could be added without breaking any existing code by
allowing "void" to be used as a qualifier rather than a type.  Thus,
a "void char*" would be a "char*" that can handle implicit conversions
to or from other type, and handle aliasing with any other type.  Such
an approach could easily be extended to e.g. "void uint32_t*" in cases
where code has an aligned pointer to data of arbitrary type that it
wishes to process in four-byte chunks.

Of course, C has no such types, thus making it necessary to use "void*"
instead, but there's no reason any new languages would need to be bound
by C's limitations in that regard.

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

#111739

On Wednesday, June 7, 2017 at 2:19:59 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, June 7, 2017 at 12:14:14 PM UTC-5, Rick C. Hodgin wrote:
> > The function is designed to take memory of arbitrary types, however,
> > and search them for a character, right?
> > 
> > So ... I don't see it other than possibly the convention to allow a
> > void * reference so it indicates non-predilection.  But even then,
> > it is a character scan function, so ... I'm only 38% convinced.
> 
> If C had a pointer type that would behave like a char*, but which was
> intended to access the contents of objects identified by pointers of
> other types, and thus allowed implicit casting, such a type would be
> more appropriate than void* in most cases where the latter is used.
> Such a type could be added without breaking any existing code by
> allowing "void" to be used as a qualifier rather than a type.  Thus,
> a "void char*" would be a "char*" that can handle implicit conversions
> to or from other type, and handle aliasing with any other type.  Such
> an approach could easily be extended to e.g. "void uint32_t*" in cases
> where code has an aligned pointer to data of arbitrary type that it
> wishes to process in four-byte chunks.
> 
> Of course, C has no such types, thus making it necessary to use "void*"
> instead, but there's no reason any new languages would need to be bound
> by C's limitations in that regard.

CAlive addresses this with the new "any" type.  CAlive uses C++'s model
for strict typing, and thus casting something from char* to void* does
require a cast, but casting something from char* to any* does not.

I added that feature for backward compatibility, and to make it its own
type.  any* and void* are functionally identical otherwise, except that
any* does not require explicit casting, and is automatically cast as in
C.

I have also introduced typing which is indirect, and it allows for some
additional information, such as the original type even if the pointer's
been cast to another form.  It uses one level of indirection as well,
so its data is movable while in use.  It's slower than traditional data
access, but not that much slower, and it adds a tremendously powerful
set of data-knowledge features at runtime.

Thank you,
Rick C. Hodgin

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

#111754

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Wednesday, June 7, 2017 at 11:51:09 AM UTC-4, Ben Bacarisse wrote:
>>   size_t memfrqBB(const void *s, int c, size_t n)
>>   {
>>        const unsigned char *s0 = s, c0 = c;
>>        size_t k = 0;
>>    
>>        while (n-- > 0)
>>             k += *s0++ == c0;
>>        return k;
>>   }
>
> Why are you (or is C) opposed to using const char * parameters, or
> char parameters?  Why use the conversion / translation in local
> variable space?

I'm not opposed to it.  I was implementing a given prototype.

>    size_t memfrqBB(const char *p, char c, size_t n)
>    {
>         for (size_t k = 0; n > 0; n--, p++)
>              k += (*p == c);
>
>         return k;

k not in scope here.

>    }
>
> Still not the same function,

I know.  That's why I replied to the message I replied to.  If I were
re-writing yours, I'd have replied to you.

-- 
Ben.

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

#111722

On Wed, 07 Jun 2017 16:50:59 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> That looks fussy to me.  If you don't keep repeating the type you don't
> need to typedef it.  I'd also keep the const:
> 
>   const unsigned char *s0 = s, c0 = c;

I don't like multidefinition. I don't keep the const keyword since I increment
the pointer later.


>   size_t k = 0;
> 
> >   scan:
> >   {
> >     if (n > 1)
> 
> What do you have against n == 1?!!

That's a typo I should have written n > 0 but I thought it was so obvious that
n could be greater than zero...


> >     {
> >       if (*s0 == c0)
> >       {
> >         k++;
> >       }
> >
> >       s0++;
> >       n--;
> >
> >       goto scan;
> >     }
> 
> Seriously?  That's a wind-up, surely?

Does it break anything? Please tell me! :-)


> 
> >     return k;
> >   }
> > }
> 
> What is the general view of writing things like
> 
>   k += *s0 == c0;
> 
> ?  I find it compact and natural with no extra cost, at least with
> modern compilers.

My brain is pretty limited and I can process only one statement by line.


> Anyway, an alternative version (keeping the names):
> 
>   size_t memfrqBB(const void *s, int c, size_t n)
>   {
>        const unsigned char *s0 = s, c0 = c;
>        size_t k = 0;
>    
>        while (n-- > 0)
>             k += *s0++ == c0;
>        return k;
>   }

Very compact but too much for my limited brain. ;-)

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

#111745

Le 07.06.2017 à 18:18, GOTHIER Nathan a écrit :
> On Wed, 07 Jun 2017 16:50:59 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> 
>> That looks fussy to me.  If you don't keep repeating the type you don't
>> need to typedef it.  I'd also keep the const:
>>
>>    const unsigned char *s0 = s, c0 = c;
> 
> I don't like multidefinition. I don't keep the const keyword since I increment
> the pointer later.
> 

That's not what the const denotes. THAT const tells that the function 
doesn't modify the data pointed to. The pointer itself is modifiable at 
leisure.

> 
>>    size_t k = 0;
>>
>>>    scan:
>>>    {
>>>      if (n > 1)
>>
>> What do you have against n == 1?!!
> 
> That's a typo I should have written n > 0 but I thought it was so obvious that
> n could be greater than zero...

It's an unsigned, so even if(n) is enough.

> 
> 
>>>      {
>>>        if (*s0 == c0)
>>>        {
>>>          k++;
>>>        }
>>>
>>>        s0++;
>>>        n--;
>>>
>>>        goto scan;
>>>      }
>>
>> Seriously?  That's a wind-up, surely?
> 
> Does it break anything? Please tell me! :-)
> 
> 
>>
>>>      return k;
>>>    }
>>> }
>>
>> What is the general view of writing things like
>>
>>    k += *s0 == c0;
>>
>> ?  I find it compact and natural with no extra cost, at least with
>> modern compilers.
> 
> My brain is pretty limited and I can process only one statement by line.
> 
> 
>> Anyway, an alternative version (keeping the names):
>>
>>    size_t memfrqBB(const void *s, int c, size_t n)
>>    {
>>         const unsigned char *s0 = s, c0 = c;
>>         size_t k = 0;
>>     
>>         while (n-- > 0)
>>              k += *s0++ == c0;
>>         return k;
>>    }
> 
> Very compact but too much for my limited brain. ;-)
> 
It is idiomatic and much, much easier to understand than the diluted 
pseudo machine code before. goto for a simple loop, seriously?

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

#111746

On Wed, 7 Jun 2017 21:15:28 +0200
"Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:
 
> It is idiomatic and much, much easier to understand than the diluted 
> pseudo machine code before. goto for a simple loop, seriously?

There's nothing wrong with goto since it is a C keyword so deal with it. ;-)

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

#111921

Le 07.06.2017 à 21:16, GOTHIER Nathan a écrit :
> On Wed, 7 Jun 2017 21:15:28 +0200
> "Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:
>   
>> It is idiomatic and much, much easier to understand than the diluted
>> pseudo machine code before. goto for a simple loop, seriously?
> 
> There's nothing wrong with goto since it is a C keyword so deal with it. ;-)
> 
There's nothing wrong with goto in some cases.
In this case it is beyond stupid. It is a simple loop with a simple 
condition on one side, that is better expressed by a while() or even a 
for() statement. This makes intent and implementation obvious. A goto is 
much lower abstraction and requires more effort for the reader. A goto 
allows to implement things that are not possible with the usual 
constructs and signals that there is something special here. In you 
example it does not and any reviewer worth its salt will reject that code.

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

#111925

On Sat, 10 Jun 2017 09:08:07 +0200
"Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:

> There's nothing wrong with goto in some cases.
> In this case it is beyond stupid. It is a simple loop with a simple 
> condition on one side, that is better expressed by a while() or even a 
> for() statement. This makes intent and implementation obvious. A goto is 
> much lower abstraction and requires more effort for the reader. A goto 
> allows to implement things that are not possible with the usual 
> constructs and signals that there is something special here. In you 
> example it does not and any reviewer worth its salt will reject that code.

What's really stupid is being unable to understand low level programming...

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

#111928

Le 10.06.2017 à 09:56, GOTHIER Nathan a écrit :
> On Sat, 10 Jun 2017 09:08:07 +0200
> "Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:
> 
>> There's nothing wrong with goto in some cases.
>> In this case it is beyond stupid. It is a simple loop with a simple
>> condition on one side, that is better expressed by a while() or even a
>> for() statement. This makes intent and implementation obvious. A goto is
>> much lower abstraction and requires more effort for the reader. A goto
>> allows to implement things that are not possible with the usual
>> constructs and signals that there is something special here. In you
>> example it does not and any reviewer worth its salt will reject that code.
> 
> What's really stupid is being unable to understand low level programming...
> 
I understad low level very well, thank you very much, that's why I avoid 
it when it is not necessary and HERE it is not necessary. Using goto to 
simulate a simple while/for loop, is like cleaning your toilet with a 
toothbrush, it gets the job done but is more difficult for no practical 
benefit.
Trying to defend that with the argument of it being a low level prowess 
only shows your limitations.

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

#111929

On Sat, 10 Jun 2017 17:14:19 +0200
"Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:

> I understad low level very well, thank you very much, that's why I avoid 
> it when it is not necessary and HERE it is not necessary. Using goto to 
> simulate a simple while/for loop, is like cleaning your toilet with a 
> toothbrush, it gets the job done but is more difficult for no practical 
> benefit.
> Trying to defend that with the argument of it being a low level prowess 
> only shows your limitations.

You're right, my brain is quite limited but insulting people for knowing their
own limits by using a basic feature of C only shows your lack of humanism. I
never insulted anybody for not writing C in a specific programming style but
there are many people here thinking it is their duty to do so...

Actually I find for or while loop straightforward in some regular pattern but I
prefer to draft with labels and goto before finalizing the code.

Many artists use pencils before inking their drawings. Should you also insult
them for not using ink like a true wonderful artist?

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

#111933

On Saturday, June 10, 2017 at 8:42:10 AM UTC-7, GOTHIER Nathan wrote:
> On Sat, 10 Jun 2017 17:14:19 +0200
> "Patrick.Schluter" <Patrick.Schluter@free.fr> wrote:
> 
> > I understad low level very well, thank you very much, that's why I avoid 
> > it when it is not necessary and HERE it is not necessary. Using goto to 
> > simulate a simple while/for loop, is like cleaning your toilet with a 
> > toothbrush, it gets the job done but is more difficult for no practical 
> > benefit.
> > Trying to defend that with the argument of it being a low level prowess 
> > only shows your limitations.
> 
> You're right, my brain is quite limited but insulting people for knowing their
> own limits by using a basic feature of C only shows your lack of humanism. I
> never insulted anybody for not writing C in a specific programming style but
> there are many people here thinking it is their duty to do so...
> 
> Actually I find for or while loop straightforward in some regular pattern but I
> prefer to draft with labels and goto before finalizing the code.
> 
> Many artists use pencils before inking their drawings. Should you also insult
> them for not using ink like a true wonderful artist?

I do the same thing. My first "draft" of a program usually uses
goto's. When that version stabilizes I translate my goto's into
loop language (as much as possible). I have discovered that the
process of introducing loops et al usually causes major changes
in the program and these changes are almost always for the 
better. I think I would be suspicious of anyone who claimed to
program in an entirely different way.

But from the point of view of what is easier to "understand" I
suspect the form in goto's has more popular appeal.

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

#111934

On 10/06/2017 19:52, David Kleinecke wrote:
> On Saturday, June 10, 2017 at 8:42:10 AM UTC-7, GOTHIER Nathan wrote:

>> Many artists use pencils before inking their drawings. Should you also insult
>> them for not using ink like a true wonderful artist?
> 
> I do the same thing. My first "draft" of a program usually uses
> goto's. When that version stabilizes I translate my goto's into
> loop language (as much as possible).

My first draft is usually free of gotos.

It's the second draft that might have them added to fix the problems in 
the first one!

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

#111938

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I do the same thing. My first "draft" of a program usually uses
> goto's. When that version stabilizes I translate my goto's into
> loop language (as much as possible). I have discovered that the
> process of introducing loops et al usually causes major changes
> in the program and these changes are almost always for the 
> better. I think I would be suspicious of anyone who claimed to
> program in an entirely different way.

I think your approach is a very unusual one.  I rarely use gotos, in a
first draft or otherwise.  If I need a loop, I write a loop.  No
translation is necessary, and the changes you describe are there from
the beginning.

> But from the point of view of what is easier to "understand" I
> suspect the form in goto's has more popular appeal.

I doubt that.

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

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

#111939

On Sat, 10 Jun 2017 11:52:29 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:

> But from the point of view of what is easier to "understand" I
> suspect the form in goto's has more popular appeal.

Indeed. I am stunned by the fierce opposition to labels and goto while many
detractors acknowledge its incredible power for corner cases where they are
unable to express clearly their algorithm with a higher level loop structure.

I suspect that they are too full of themselves to accept with humility to use
labels and goto to draft their code before possibly improving its clarity with
higher level loop structures such as while or for.

Actually I prefer to draft loops with labels and goto to tell the machine how I
want to process the data instead of restricting my code with high level loop
structures.

I think it is a better approach to start from a lower level than wasting a lot
of time to think directly from a high level. The simple fact that some peoples
are "forced" with an unecessary shame to use labels and goto in corner cases
proves they failed in their top-down approach which isn't straightforward for
any algorithm.

I have a trivial question for the top-down masters: did you learn the number
theory before counting upto 10 at the kindergarten? :o)

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

#111940

GOTHIER Nathan:

> Indeed.  I  am stunned by the fierce opposition to
> labels and goto while many detractors  acknowledge
> its  incredible  power for corner cases where they
> are unable to express clearly their algorithm with
> a higher level loop structure.

Since C has 'break' and 'continue' and supports mul-
tiple returns from a function,  there  is  rarely  a
need  for  'goto'  outisde error handling and deini-
tialization:

  success = 0;
  a = malloc(...);
  if( a == NULL )
  {  goto ErrorA;  }
  b = malloc(...);
  if( b == NULL )
  {  goto ErrorB;  }
  c = malloc(...);
  if( c == NULL )
  {  goto ErrorC;  }
  ...
  success = 1;
  ErrorC: free(b);
  ErrorB: free(a);
  ErorrA:

  return success;

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

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

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

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

csiph-web