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

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

Whaddaya think?

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

Contents

  Whaddaya think? DFS <nospam@dfs.com> - 2024-06-15 15:36 -0400
    Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-15 22:33 +0100
    Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-15 23:03 +0100
      Re: Whaddaya think? bart <bc@freeuk.com> - 2024-06-16 00:22 +0100
        Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-16 10:30 +0100
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:52 -0400
        Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 00:17 +0100
          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 08:49 -0400
    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 15:22 -0700
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 12:20 -0400
        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 13:54 -0700
        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-16 22:41 -0400
          Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-16 22:45 -0700
          Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:39 +0000
            Re: Whaddaya think? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 01:22 -0700
            Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:50 -0400
              Re: Whaddaya think? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-17 16:23 +0100
                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-17 18:46 +0200
                Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-22 22:14 +0000
                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:10 -0700
                  Re: Whaddaya think? Phil Carmody <pc+usenet@asdf.org> - 2024-06-23 11:20 +0300
            Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:19 -0700
              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 03:10 -0700
                Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:24 -0700
                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 17:55 -0700
                    Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-19 01:58 +0000
          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 08:50 -0400
            Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 15:41 +0100
              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 08:12 +0200
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 03:07 -0700
        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 00:30 -0400
    Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 01:56 +0300
      Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 03:26 +0000
        Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 05:41 +0200
          Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 21:17 -0700
            Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 04:41 +0000
            Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 06:44 +0200
              Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:09 -0400
                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-16 17:56 +0200
                  Re: Whaddaya think? bart <bc@freeuk.com> - 2024-06-16 18:14 +0100
                    Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-17 14:44 +0200
                  Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:52 -0400
          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 06:51 +0200
            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 22:21 -0700
              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 07:41 +0200
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 22:49 -0700
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:29 +0200
                    Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 16:04 +0100
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 17:13 +0200
                    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 13:32 -0700
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:41 +0200
                        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 23:20 -0700
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:16 +0200
                            Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 09:38 -0400
                              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:17 -0700
                              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 07:09 +0200
                                Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:25 -0400
                                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 02:57 -0700
                            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:15 -0700
                              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 08:02 +0200
                              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 19:07 -0700
                                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-19 09:50 +0200
                                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:13 -0700
                        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:21 -0400
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:22 +0200
                Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 11:11 +0300
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:07 +0200
                    Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 12:38 +0300
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 12:03 +0200
                        Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 14:31 +0300
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 17:37 +0200
                            Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-17 00:45 +0300
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 17:06 -0700
                  Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-16 22:40 -0700
                    Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:52 +0200
                      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:45 -0400
                        Re: Whaddaya think? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:16 -0700
                          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 17:07 -0400
                            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 15:48 -0700
                            Re: Whaddaya think? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 22:48 +0000
                        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 15:44 -0700
                          Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-18 15:00 +0200
                        Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 06:57 +0200
                      Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:25 -0700
                    Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:38 -0400
                      Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:01 -0700
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:48 +0200
                    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 23:29 -0700
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:35 +0200
          Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 08:19 +0100
          Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 10:44 +0300
            Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:13 +0200
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:03 -0400
    Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-16 15:52 +0000
      Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 17:17 +0100
      Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 08:06 +0000
      Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-25 17:37 +0000
        Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-25 14:09 -0400
          Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-25 18:11 +0000

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

#386124

DFS <nospam@dfs.com> writes:
> On 6/17/2024 1:52 AM, Janis Papanagnou wrote:
>> On 17.06.2024 07:40, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> The worst consequence of undefined behavior is having your code
>>>> appear to "work".
>>>
>>> Personally I think causing a missle launch that started a
>>> worldwide thermonuclear war would be a worse consequence.
>>> YMMV.
>> I think I wouldn't code a missile control system in "C". ;-)
>> Janis
>
> Per "Google AI Overview": "In 1987, the Department of Defense mandated
> that Ada be the standard programming language for Defense computer 
> resources used in military command and control systems."

Please don't post AI-based misinformation.

The DOD Ada mandate was introduced in 1991, and effectively dropped in 1997.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#386169

On 18/06/2024 00:44, Keith Thompson wrote:
> DFS <nospam@dfs.com> writes:
>> On 6/17/2024 1:52 AM, Janis Papanagnou wrote:
>>> On 17.06.2024 07:40, Tim Rentsch wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> The worst consequence of undefined behavior is having your code
>>>>> appear to "work".
>>>>
>>>> Personally I think causing a missle launch that started a
>>>> worldwide thermonuclear war would be a worse consequence.
>>>> YMMV.
>>> I think I wouldn't code a missile control system in "C". ;-)
>>> Janis
>>
>> Per "Google AI Overview": "In 1987, the Department of Defense mandated
>> that Ada be the standard programming language for Defense computer
>> resources used in military command and control systems."
> 
> Please don't post AI-based misinformation.
> 
> The DOD Ada mandate was introduced in 1991, and effectively dropped in 1997.
> 

And of course the USA DoD (I assume, when DFS failed to mention the 
country, he meant the USA) is only for one country.  There are a great 
many other countries making missile control software around the world, 
and I know without doubt that Ada is not mandated in all of them.

The open-source RTEMS "Real-Time Executive for Missile Systems" RTOS is 
written in a mix of C and Ada, and supports at least C, Ada and C++ for 
user code.

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

#386136

On 17.06.2024 15:45, DFS wrote:
> On 6/17/2024 1:52 AM, Janis Papanagnou wrote:
>>
>> I think I wouldn't code a missile control system in "C". ;-)
> 
> Per "Google AI Overview": "In 1987, the Department of Defense mandated
> that Ada be the standard programming language for Defense computer
> resources used in military command and control systems."

This is actually what I'd have expected, that they might prefer Ada
(as in the aviation or space flight areas).

There's jokes existing[*] that illustrate the dilemma with safety in
engineering. Using specific (unsafe) languages as well as reducing
funds for QA measures or externalizing processes and components (or
many other possible sources for increased unreliability); there's
quite some tragic examples, sadly.

Janis

[*] e.g.
https://www.reddit.com/r/Jokes/comments/6a1czd/a_group_of_engineering_professors_were_invited_to/

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

#386148

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 17.06.2024 07:40, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> The worst consequence of undefined behavior is having your code
>>> appear to "work".
>>
>> Personally I think causing a missle launch that started a
>> worldwide thermonuclear war would be a worse consequence.
>> YMMV.
>
> I think I wouldn't code a missile control system in "C". ;-)

It's extremely unlikely that I will ever be working on a missile
control system, either in C or in any other language.  But that
doesn't change either the truth or the point of my comment.

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

#386060

On 17.06.2024 07:40, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
>> The worst consequence of undefined behavior is having your code
>> appear to "work".
> 
> Personally I think causing a missle launch that started a
> worldwide thermonuclear war would be a worse consequence.
> YMMV.

The standard doesn't say anything to prohibit such a consequence, but in
real life such an outcome is possible only if your program is executing
in an environment that allows it to send out launch messages to real
missiles. In such a context, a program that was intended to launch a
missile strike, and seemed to do so, but actually failed to do so, would
arguably be worse. If the enemy knows that you are running such
defective software, that enemy might not be deterred from attacking.

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

#386208

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

> On 17.06.2024 07:40, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> The worst consequence of undefined behavior is having your code
>>> appear to "work".
>>
>> Personally I think causing a missle launch that started a
>> worldwide thermonuclear war would be a worse consequence.
>> YMMV.
>
> The standard doesn't say anything to prohibit such a consequence, but in
> real life such an outcome is possible only if your program is executing
> in an environment that allows it to send out launch messages to real
> missiles.  In such a context, a program that was intended to launch a
> missile strike, and seemed to do so, but actually failed to do so, would
> arguably be worse.  If the enemy knows that you are running such
> defective software, that enemy might not be deterred from attacking.

None of that has any relevance to my comment.

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

#386052

On 17.06.2024 02:06, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> void main (int argc, char * argv[])
>> {
>>     int chunk = 10;
>>     int bufsize = chunk+1;
>>     char * buf = malloc(bufsize);
>>     char * anchor = buf;
>>     while (fgets(buf, chunk+1, stdin) != NULL)
>>         if (realloc(anchor, bufsize += chunk) != NULL)
>>             buf += chunk;
>>     puts(anchor);
>> }
> 
> realloc() can return the pointer you pass to it if there's enough room
> in the existing location.  (Or it can relocate the buffer even if there
> is enough room.)
> 
> But if realloc() moves the buffer (copying the existing data to it), it
> returns a pointer to the new location and invalidates the old one.  You
> discard the new pointer, only comparing it to NULL.
> 
> Perhaps you assumed that realloc() always expands the buffer in place.
> It doesn't.

No, I didn't assume that. I just missed that 'anchor' will get lost.
Thanks!

> 
> If the above program worked for you, I suspect that either realloc()
> never relocated the buffer, or you continued using the original buffer
> (and beyond) after realloc() invalidated it. [...]

Yes, that was certainly the case. (I did no thorough test with large
data sets, just a simple ad hoc test.)


Elsethread I suggested to merge the malloc() with the realloc() call.
The resulting code would be simpler (and might address that problem).

    int chunk = 10;
    int bufsize = 1;
    char *  anchor = NULL;
    while ((anchor = realloc (anchor, bufsize += chunk)) != NULL  &&
            fgets (anchor+bufsize-chunk-1, chunk+1, stdin) != NULL)
        ;
    puts (anchor);


Do you see the exposed problem (or any other issues) here, too?

Janis

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

#386058

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 17.06.2024 02:06, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> [...]
>>> #include <stdlib.h>
>>> #include <stdio.h>
>>>
>>> void main (int argc, char * argv[])
>>> {
>>>     int chunk = 10;
>>>     int bufsize = chunk+1;
>>>     char * buf = malloc(bufsize);
>>>     char * anchor = buf;
>>>     while (fgets(buf, chunk+1, stdin) != NULL)
>>>         if (realloc(anchor, bufsize += chunk) != NULL)
>>>             buf += chunk;
>>>     puts(anchor);
>>> }
>> 
>> realloc() can return the pointer you pass to it if there's enough room
>> in the existing location.  (Or it can relocate the buffer even if there
>> is enough room.)
>> 
>> But if realloc() moves the buffer (copying the existing data to it), it
>> returns a pointer to the new location and invalidates the old one.  You
>> discard the new pointer, only comparing it to NULL.
>> 
>> Perhaps you assumed that realloc() always expands the buffer in place.
>> It doesn't.
>
> No, I didn't assume that. I just missed that 'anchor' will get lost.
> Thanks!
>
>> 
>> If the above program worked for you, I suspect that either realloc()
>> never relocated the buffer, or you continued using the original buffer
>> (and beyond) after realloc() invalidated it. [...]
>
> Yes, that was certainly the case. (I did no thorough test with large
> data sets, just a simple ad hoc test.)
>
>
> Elsethread I suggested to merge the malloc() with the realloc() call.
> The resulting code would be simpler (and might address that problem).
>
>     int chunk = 10;
>     int bufsize = 1;
>     char *  anchor = NULL;
>     while ((anchor = realloc (anchor, bufsize += chunk)) != NULL  &&
>             fgets (anchor+bufsize-chunk-1, chunk+1, stdin) != NULL)
>         ;
>     puts (anchor);
>
>
> Do you see the exposed problem (or any other issues) here, too?

If stdin is empty, you never store anything in the buffer and
puts(anchor) has undefined behavior because there might be a terminating
'\0'.  If the first realloc() fails, anchor is a null pointer and again
puts(anchor) has undefined behavior.

If nothing goes wrong, puts() adds an extra newline to the output.

That's all that jumped out at me looking at the code, but did you test
it with multi-line input?  When I tried it it printed only the first
line of input (followed by that extra newline).

I'm still not entirely sure what the code is supposed to do.

```
$ ( echo one ; echo two ) | ./janis
one

$
```

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#386064

On 17.06.2024 08:29, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>[...]
>>
>> Elsethread I suggested to merge the malloc() with the realloc() call.
>> The resulting code would be simpler (and might address that problem).
>>
>>     int chunk = 10;
>>     int bufsize = 1;
>>     char *  anchor = NULL;
>>     while ((anchor = realloc (anchor, bufsize += chunk)) != NULL  &&
>>             fgets (anchor+bufsize-chunk-1, chunk+1, stdin) != NULL)
>>         ;
>>     puts (anchor);
>>
>>
>> Do you see the exposed problem (or any other issues) here, too?
> 
> If stdin is empty, you never store anything in the buffer and
> puts(anchor) has undefined behavior because there might be a terminating
> '\0'.  If the first realloc() fails, anchor is a null pointer and again
> puts(anchor) has undefined behavior.
> 
> If nothing goes wrong, puts() adds an extra newline to the output.

Yes, the purpose of puts() was to show whether the function that I
wanted to check works properly on a long line of data.

> 
> That's all that jumped out at me looking at the code, but did you test
> it with multi-line input?  When I tried it it printed only the first
> line of input (followed by that extra newline).
> 
> I'm still not entirely sure what the code is supposed to do.

I just wanted the realloc-append logic codified and verified. (As
a possible building block to create a function for the purpose of
the original task outlined by the OP.)

Janis

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

#386009

On 16/06/2024 04:41, Janis Papanagnou wrote:
> On 16.06.2024 05:26, Lawrence D'Oliveiro wrote:
>> On Sun, 16 Jun 2024 01:56:49 +0300, Michael S wrote:
>>
>>> If you want to preserve you sanity, never use fscanf().
>>
>> Quoth the man page <https://manpages.debian.org/3/scanf.3.en.html>:
>>
>>      It is very difficult to use these functions correctly, and it is
>>      preferable to read entire lines with fgets(3) or getline(3) and
>>      parse them later with sscanf(3) or more specialized functions such
>>      as strtol(3).
> 
> This would be also my first impulse, but you'd have to know
> _in advance_ how long the data stream would be; the function
> requires an existing buffer. So you'd anyway need a stepwise
> input. On the plus side there's maybe a better performance
> to read large buffer junks and compose them on demand? But
> a problem is the potential cut of the string of a number; it
> requires additional clumsy handling. So it might anyway be
> better (i.e. much more convenient) to use fscanf() ?
> 
> Janis
> 
Try this psuedo - code)

tempfp = tmpfile();

while ((ch = fgetc(fp) != EOF)
{
    if (isidigit(ch))
    {
       ungetc(ch, fp);
       x = parsenumber(fp);
       fwrite(&x, sizeof(int), 1, tenpfp);
       N++;
    }
}

answer = malloc(N * sizeof(int))
fessek(tempfp, 0, SEEK_SET);
fread(answer, N, sizeof(int), tempfp);
reverse(answer, N);
-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

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

#386010

On Sun, 16 Jun 2024 05:41:12 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 16.06.2024 05:26, Lawrence D'Oliveiro wrote:
> > On Sun, 16 Jun 2024 01:56:49 +0300, Michael S wrote:
> >   
> >> If you want to preserve you sanity, never use fscanf().  
> > 
> > Quoth the man page <https://manpages.debian.org/3/scanf.3.en.html>:
> > 
> >     It is very difficult to use these functions correctly, and it is
> >     preferable to read entire lines with fgets(3) or getline(3) and
> >     parse them later with sscanf(3) or more specialized functions
> > such as strtol(3).  
> 
> This would be also my first impulse, but you'd have to know
> _in advance_ how long the data stream would be; the function
> requires an existing buffer.

Define formats with sensible maximal line length (512 sounds about
right) and refuse any input that has longer lines.

> So you'd anyway need a stepwise
> input. On the plus side there's maybe a better performance
> to read large buffer junks and compose them on demand? But
> a problem is the potential cut of the string of a number; it
> requires additional clumsy handling. So it might anyway be
> better (i.e. much more convenient) to use fscanf() ?
> 

No, the behaviour of fsacnf() is too non-intuitive.

> Janis
> 

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

#386013

On 16.06.2024 09:44, Michael S wrote:
> On Sun, 16 Jun 2024 05:41:12 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 
>> On 16.06.2024 05:26, Lawrence D'Oliveiro wrote:
>>> On Sun, 16 Jun 2024 01:56:49 +0300, Michael S wrote:
>>>   
>>>> If you want to preserve you sanity, never use fscanf().  
>>>
>>> Quoth the man page <https://manpages.debian.org/3/scanf.3.en.html>:
>>>
>>>     It is very difficult to use these functions correctly, and it is
>>>     preferable to read entire lines with fgets(3) or getline(3) and
>>>     parse them later with sscanf(3) or more specialized functions
>>> such as strtol(3).  
>>
>> This would be also my first impulse, but you'd have to know
>> _in advance_ how long the data stream would be; the function
>> requires an existing buffer.
> 
> Define formats with sensible maximal line length (512 sounds about
> right) and refuse any input that has longer lines.

You're not serious, are you? - Or wasn't it clear that it was
about reading lines (of arbitrary lengths) in one go?

> 
>> So you'd anyway need a stepwise
>> input. On the plus side there's maybe a better performance
>> to read large buffer junks and compose them on demand? But
>> a problem is the potential cut of the string of a number; it
>> requires additional clumsy handling. So it might anyway be
>> better (i.e. much more convenient) to use fscanf() ?
>>
> 
> No, the behaviour of fsacnf() is too non-intuitive.

Maybe fsacnf() is non-intuitive.

Myself I've never problems with fscanf(), though. - To each
his own. :-)

Janis

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

#386024

On 6/15/2024 6:56 PM, Michael S wrote:
> On Sat, 15 Jun 2024 15:36:22 -0400

> If you want to preserve you sanity, never use fscanf().


ha!

You misspelled C.

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

#386029

On Sat, 15 Jun 2024 15:36:22 -0400, DFS wrote:

> I want to read numbers in from a file, say:
> 
> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 
> 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 
> 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 
> 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 
> 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
> 
> 
> This code:
> 1 opens the file
> 2 fscanf thru the file to count the number of data points
> 3 allocate memory
> 4 rewind and fscanf again to add the data to the int array
> 
> 
> Any issues with this method?

Others have (and will continue to) address this question.

> Any 'better' way?

Not so much "better", as "other".

ISTM that you waste an opportunity (and expose a common 'blind-spot')
in your first loop:

Here,
>  while(fscanf(datafile, "%d", &j) != EOF){
>    N++;
>  }
you discard a lot of work (done for you by fscanf() to determine the
value of each input number) just to be able to count the number of
numbers in your input. What if there were a way to put this (to you)
byproduct of fscanf() to use, and avoid using fscanf() entirely in
the second pass?

You /could/ create a temporary, binary, file, and write the fscanf()'ed
values to it as part of the first loop. Once the first loop completes,
you rewind this temporary file, and load your integer array by reading
the (now converted to native integer format) values from that file.

Still two passes, but using fscanf() in only one of those passes.

(BTW, the 'blind-spot' I mentioned is that we often forget that
we /can/ use temporary files to store intermediary results. Sometimes
we can manipulate a temporary file easier than we can manipulate
malloc()ed (or other) storage. )
-- 
Lew Pitcher
"In Skills We Trust"

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

#386032

On 16/06/2024 16:52, Lew Pitcher wrote:
> On Sat, 15 Jun 2024 15:36:22 -0400, DFS wrote:
> 
>> I want to read numbers in from a file, say:
>>
>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245
>> 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178
>> 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79
>> 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297
>> 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>>
>>
>> This code:
>> 1 opens the file
>> 2 fscanf thru the file to count the number of data points
>> 3 allocate memory
>> 4 rewind and fscanf again to add the data to the int array
>>
>>
>> Any issues with this method?
> 
> Others have (and will continue to) address this question.
> 
>> Any 'better' way?
> 
> Not so much "better", as "other".
> 
> ISTM that you waste an opportunity (and expose a common 'blind-spot')
> in your first loop:
> 
> Here,
>>   while(fscanf(datafile, "%d", &j) != EOF){
>>     N++;
>>   }
> you discard a lot of work (done for you by fscanf() to determine the
> value of each input number) just to be able to count the number of
> numbers in your input. What if there were a way to put this (to you)
> byproduct of fscanf() to use, and avoid using fscanf() entirely in
> the second pass?
> 
> You /could/ create a temporary, binary, file, and write the fscanf()'ed
> values to it as part of the first loop. Once the first loop completes,
> you rewind this temporary file, and load your integer array by reading
> the (now converted to native integer format) values from that file.
> 
> Still two passes, but using fscanf() in only one of those passes.
> 
> (BTW, the 'blind-spot' I mentioned is that we often forget that
> we /can/ use temporary files to store intermediary results. Sometimes
> we can manipulate a temporary file easier than we can manipulate
> malloc()ed (or other) storage. )
 >
Exactly. People complain that it is a hassle to realloc() a buffer.

So just use a temporary file.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

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

#386153

On Sun, 16 Jun 2024 15:52:16 -0000 (UTC), Lew Pitcher wrote:

> (BTW, the 'blind-spot' I mentioned is that we often forget that we /can/
> use temporary files to store intermediary results. Sometimes we can
> manipulate a temporary file easier than we can manipulate malloc()ed (or
> other) storage. )

Or we could use an “I/O stream”, basically a temporary file in RAM.

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

#386524

On Sun, 16 Jun 2024 15:52:16 +0000, Lew Pitcher wrote:

> On Sat, 15 Jun 2024 15:36:22 -0400, DFS wrote:
> 
>> I want to read numbers in from a file, say:
>> 
>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 
>> 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 
>> 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 
>> 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 
>> 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>> 
>> 
>> This code:
>> 1 opens the file
>> 2 fscanf thru the file to count the number of data points
>> 3 allocate memory
>> 4 rewind and fscanf again to add the data to the int array
>> 
>> 
[snip]
> You /could/ create a temporary, binary, file, and write the fscanf()'ed
> values to it as part of the first loop. Once the first loop completes,
> you rewind this temporary file, and load your integer array by reading
> the (now converted to native integer format) values from that file.
> 
> Still two passes, but using fscanf() in only one of those passes.
[snip]

For what it's worth, here's an example of what I suggest:

/*
The following code provides two examples of the approach I suggested.

Example 1: while counting input numbers, write temp file with int values
	   malloc() a buffer big enough for that count of int values
	   fread() the temp file into the malloc()'ed buffer
	   Note: conformant to ISO Standard C.

Example 2: while counting input numbers, write temp file with int values
	   mmap() the temp file, starting at the beginning, and sized to
	   include all the int values in the file.
	   Note: conformant to POSIX C extensions to ISO Standard C.

Note: compile with -DUSE_MMAP to obtain mmap() variant, otherwise
      this will compile the malloc()/fread() variant
*/

#include <stdio.h>
#include <stdlib.h>

#ifdef USE_MMAP
  #include <sys/mman.h>
  #define BANNER	"Example of array loading using mmap()"
  #define FREEALLOC(x)
#else
  #define BANNER	"Example of array loading using malloc() and fread()"
  #define FREEALLOC(x) free((x))
#endif

static int *LoadIntArray(FILE *fp, size_t *Count);

int main(void)
{
  int status = EXIT_FAILURE, *array;
  size_t count;

  puts(BANNER);

  if ((array = LoadIntArray(stdin,&count)))
  {
    printf("%zu elements loaded\n",count);
    for (size_t index = 0; index < count; ++index)
      printf("array[%3zu] == %d\n",index,array[index]);

    FREEALLOC(array);	/* if necessary, free() the malloc()'ed array */
    status = EXIT_SUCCESS;
  }
  return status;
}

static int *LoadIntArray(FILE *fp,size_t *Count)
{
  FILE *tmp;
  int *array = NULL;
  size_t count = 0;

  if ((tmp = tmpfile()))
  {
    int buffer;

    for (count = 0; fscanf(fp,"%d",&buffer) == 1; ++count)
      fwrite(&buffer,sizeof buffer, 1,tmp);

    if (count)
    {
#ifdef USE_MMAP
      /*
      ** USE mmap() to map temp_file data into process memory
      */
      array = mmap(NULL,
                   count * sizeof *array,
                   PROT_READ,MAP_PRIVATE,
                   fileno(tmp),
                   0);
      if (array == MAP_FAILED)
      {
	array = NULL;
	fprintf(stderr,"FAIL: Cannot mmap %zu element array\n",count);
      }
#else
      /*
      ** USE malloc() to reserve a big enough heap-space buffer,
      ** then fread() the temp_file data into that buffer
      */
      if ((array = malloc(count * sizeof *array)))
      {
	rewind(tmp);
	if (fread(array,sizeof *array,count,tmp) != count)
	{
	  free(array);
	  array = NULL;
	  fprintf(stderr,"FAIL: Cannot load %zu element array\n",count);
	}
      }
      else fprintf(stderr,"FAIL: Cant malloc() %zu element array\n",count);
#endif
    }
    fclose(tmp);

  }
  else fprintf(stderr,"FAIL: Cannot allocate temporary work file\n");

  *Count = count;	/* byproduct value that caller might find useful */
  return array;		/* either NULL (on failure) or pointer to array */
}



-- 
Lew Pitcher
"In Skills We Trust"

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

#386526

On 6/25/2024 1:37 PM, Lew Pitcher wrote:
> On Sun, 16 Jun 2024 15:52:16 +0000, Lew Pitcher wrote:
> 
>> On Sat, 15 Jun 2024 15:36:22 -0400, DFS wrote:
>>
>>> I want to read numbers in from a file, say:
>>>
>>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245
>>> 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178
>>> 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79
>>> 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297
>>> 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>>>
>>>
>>> This code:
>>> 1 opens the file
>>> 2 fscanf thru the file to count the number of data points
>>> 3 allocate memory
>>> 4 rewind and fscanf again to add the data to the int array
>>>
>>>
> [snip]
>> You /could/ create a temporary, binary, file, and write the fscanf()'ed
>> values to it as part of the first loop. Once the first loop completes,
>> you rewind this temporary file, and load your integer array by reading
>> the (now converted to native integer format) values from that file.
>>
>> Still two passes, but using fscanf() in only one of those passes.
> [snip]
> 
> For what it's worth, here's an example of what I suggest:
> 
> /*
> The following code provides two examples of the approach I suggested.
> 
> Example 1: while counting input numbers, write temp file with int values
> 	   malloc() a buffer big enough for that count of int values
> 	   fread() the temp file into the malloc()'ed buffer
> 	   Note: conformant to ISO Standard C.
> 
> Example 2: while counting input numbers, write temp file with int values
> 	   mmap() the temp file, starting at the beginning, and sized to
> 	   include all the int values in the file.
> 	   Note: conformant to POSIX C extensions to ISO Standard C.
> 
> Note: compile with -DUSE_MMAP to obtain mmap() variant, otherwise
>        this will compile the malloc()/fread() variant
> */
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> #ifdef USE_MMAP
>    #include <sys/mman.h>
>    #define BANNER	"Example of array loading using mmap()"
>    #define FREEALLOC(x)
> #else
>    #define BANNER	"Example of array loading using malloc() and fread()"
>    #define FREEALLOC(x) free((x))
> #endif
> 
> static int *LoadIntArray(FILE *fp, size_t *Count);
> 
> int main(void)
> {
>    int status = EXIT_FAILURE, *array;
>    size_t count;
> 
>    puts(BANNER);
> 
>    if ((array = LoadIntArray(stdin,&count)))
>    {
>      printf("%zu elements loaded\n",count);
>      for (size_t index = 0; index < count; ++index)
>        printf("array[%3zu] == %d\n",index,array[index]);
> 
>      FREEALLOC(array);	/* if necessary, free() the malloc()'ed array */
>      status = EXIT_SUCCESS;
>    }
>    return status;
> }
> 
> static int *LoadIntArray(FILE *fp,size_t *Count)
> {
>    FILE *tmp;
>    int *array = NULL;
>    size_t count = 0;
> 
>    if ((tmp = tmpfile()))
>    {
>      int buffer;
> 
>      for (count = 0; fscanf(fp,"%d",&buffer) == 1; ++count)
>        fwrite(&buffer,sizeof buffer, 1,tmp);
> 
>      if (count)
>      {
> #ifdef USE_MMAP
>        /*
>        ** USE mmap() to map temp_file data into process memory
>        */
>        array = mmap(NULL,
>                     count * sizeof *array,
>                     PROT_READ,MAP_PRIVATE,
>                     fileno(tmp),
>                     0);
>        if (array == MAP_FAILED)
>        {
> 	array = NULL;
> 	fprintf(stderr,"FAIL: Cannot mmap %zu element array\n",count);
>        }
> #else
>        /*
>        ** USE malloc() to reserve a big enough heap-space buffer,
>        ** then fread() the temp_file data into that buffer
>        */
>        if ((array = malloc(count * sizeof *array)))
>        {
> 	rewind(tmp);
> 	if (fread(array,sizeof *array,count,tmp) != count)
> 	{
> 	  free(array);
> 	  array = NULL;
> 	  fprintf(stderr,"FAIL: Cannot load %zu element array\n",count);
> 	}
>        }
>        else fprintf(stderr,"FAIL: Cant malloc() %zu element array\n",count);
> #endif
>      }
>      fclose(tmp);
> 
>    }
>    else fprintf(stderr,"FAIL: Cannot allocate temporary work file\n");
> 
>    *Count = count;	/* byproduct value that caller might find useful */
>    return array;		/* either NULL (on failure) or pointer to array */
> }
> 

$ gcc -Wall LewPitcher_readnums.c -o lprn
$ (no compile errors)
$ ./lprn nums.txt
Example of array loading using malloc() and fread()

(then it just hung)


$ gcc -Wall LewPitcher_readnums.c -o lprn -DUSE_MMAP
$ (no compile errors)
$ ./lprn nums.txt
Example of array loading using mmap()

(then it just hung)


Am I supposed to hardcode the filename in there somewhere?

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

#386528

On Tue, 25 Jun 2024 14:09:23 -0400, DFS wrote:

> On 6/25/2024 1:37 PM, Lew Pitcher wrote:
[snip]
> 
> $ gcc -Wall LewPitcher_readnums.c -o lprn
> $ (no compile errors)
> $ ./lprn nums.txt
> Example of array loading using malloc() and fread()

The program (both versions) take input from stdin.
Try
  ./lprn <nums.txt


-- 
Lew Pitcher
"In Skills We Trust"

[toc] | [prev] | [standalone]

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

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

csiph-web