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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#386374

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2024-06-17, Richard Harnden <richard.nospam@gmail.invalid> wrote:
>> If a function is defined to return an int, then you should return one.
>>
>> Anything else is just lazy/sloppy.  Just because main allows it as a 
>> special case doesn't mean it's a good idea.
>>
>> I mean: it's really not much extra to type.
>
> The misfeature of missing return being success was, I believe, not
> intended to make programs shorter. It was intendeda to correct the
> random termination statuses of countless numbers of programs in a single
> stroke.
>
> Deliberately relying on this in a new program is like relying ona a
> diaper. If you're of intermediate age, you don't do this.

Astronauts do this quite frequently. Some pilots too. And divers. And
crane operators. It's a well-established solution to a known problem.

However, I'd still put the explicit return in for a reason of
literal portability: were I to want to lift that code out into
a separate function called by main(), I'd want it to behave the
same.

Phil
-- 
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

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

#386147

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> Speaking of while, the do/while construct does not require parentheses
> in order to disambiguate anything, since it has a mandatory semicolon.
> Yet, it still has them.

It has them to allow an extension for a "loop-and-a-half" control
structure:

    do statement while ( expression ) statement

and so for example

    do  c = getchar();  while(  c != EOF  )  n++;

to count characters on standard input.

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

#386162

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> Speaking of while, the do/while construct does not require parentheses
>> in order to disambiguate anything, since it has a mandatory semicolon.
>> Yet, it still has them.
>
> It has them to allow an extension for a "loop-and-a-half" control
> structure:
>
>     do statement while ( expression ) statement
>
> and so for example
>
>     do  c = getchar();  while(  c != EOF  )  n++;
>
> to count characters on standard input.

Oh?  Do you have any evidence that that was the intent?  Does any
compiler provide such an extension?  (As you know it's a syntax error in
standard C.)

-- 
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]

#386211

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>
>>> Speaking of while, the do/while construct does not require parentheses
>>> in order to disambiguate anything, since it has a mandatory semicolon.
>>> Yet, it still has them.
>>
>> It has them to allow an extension for a "loop-and-a-half" control
>> structure:
>>
>>     do statement while ( expression ) statement
>>
>> and so for example
>>
>>     do  c = getchar();  while(  c != EOF  )  n++;
>>
>> to count characters on standard input.
>
> Oh?  Do you have any evidence that that was the intent? [...]

I think you're reading something into my remark that it
didn't say.

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

#386213

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>
>>>> Speaking of while, the do/while construct does not require parentheses
>>>> in order to disambiguate anything, since it has a mandatory semicolon.
>>>> Yet, it still has them.
>>>
>>> It has them to allow an extension for a "loop-and-a-half" control
>>> structure:
>>>
>>>     do statement while ( expression ) statement
>>>
>>> and so for example
>>>
>>>     do  c = getchar();  while(  c != EOF  )  n++;
>>>
>>> to count characters on standard input.
>>
>> Oh?  Do you have any evidence that that was the intent? [...]
>
> I think you're reading something into my remark that it
> didn't say.

Or at least that you didn't mean.

What did you actually meant by "It has them to allow an extension
..."?  It seemed very clear to me that you meant to imply an intent,
and I can't think of any other sensible interpretation of your words.

do-while *could* have been specified without required parentheses.
The only reason I can think of that it wasn't is consistency
with other constructs (if, for, while), and in my opinion that's
a perfectly valid reason.  If you're seriously suggesting that
there's another reason, I'd be interested in learning about it.
If any existing compiler has the loop-and-a-half extension you
mentioned, or anyone even considered such an extension, I'd be
interested in learning about that as well.  (If it was a joke,
just say so and we can drop this.)

Of course you could have explained what you meant in the first place.

-- 
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]

#386214

On 2024-06-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>
>>>>> Speaking of while, the do/while construct does not require parentheses
>>>>> in order to disambiguate anything, since it has a mandatory semicolon.
>>>>> Yet, it still has them.
>>>>
>>>> It has them to allow an extension for a "loop-and-a-half" control
>>>> structure:
>>>>
>>>>     do statement while ( expression ) statement
>>>>
>>>> and so for example
>>>>
>>>>     do  c = getchar();  while(  c != EOF  )  n++;
>>>>
>>>> to count characters on standard input.
>>>
>>> Oh?  Do you have any evidence that that was the intent? [...]
>>
>> I think you're reading something into my remark that it
>> didn't say.
>
> Or at least that you didn't mean.

FWIW, it would seem that the phrase pattern:

    do statement while expression ;

may be compatible with the proposed extension in a way
manageable via LALR(1) parsing.

I don't see difficulties in recursive descent, either.

The near minimal Yacc grammar pasted below produces no conflicts,
and is only slightly contorted. We treat the ')' token as the
lowest prededence operator, and ';' as highest, which eliminates
conflicts in way that we want.

I can explain why; another way is to remove the %nonassoc declarations,
use "yacc -v", and study the confict details y.output file.

It's not clear whether the grammar can be nicely factored into the form
used in the standard, which makes no use of precedence or associativity.
(But would that be a requirement for leaving room for an extension.)

%{

%}

%nonassoc ')'
%token DO WHILE NUM
%left '+'
%nonassoc ';'

%%

while_statement : DO statement WHILE expr ';'
                | DO statement WHILE '(' expr ')' statement

statement : ';'
          | expr ';'
          | '{' expr '}'
          | '{' '}'
          ;

expr : '(' expr ')'
     | expr '+' expr
     | '+' expr
     | NUM
     ;

%%

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386086

On 6/16/2024 10:41 PM, James Kuyper wrote:
> On 6/16/24 12:20, DFS wrote:
>> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>>> DFS <nospam@dfs.com> writes:
> ...
>>>> 	return(0);
>>>
>>> A minor style point: a return statement doesn't require parentheses.
>>> IMHO using parentheses make it look too much like a function call.  I'd
>>> write `return 0;`, or more likely I'd just omit it, since falling off
>>> the end of main does an implicit `return 0;` (starting in C99).
>>
>> Can't omit it.  It's required by my brain.
> 
> The parentheses you're putting in are completely unrelated to the use of
> parentheses in _Generic(), function calls, compound literals,
> sizeof(type name), alignof(), _BitInt(), _Atomic(), typeof(),
> typeof_unqual(), alignas(), function declarators, static_assert(), if(),
> switch(for(), while(), do ... while(), function-like macro definitions
> and invocations or cast expressions. In all of those cases, the
> parentheses are part of the grammar.
> 
> The parentheses that you put in return(0) serve only for grouping
> purpose. They are semantically equivalent to the parentheses in "i =
> (0);"; they are just as legal, and just as pointless.
> 
> If your brain doesn't immediately understand why what I said above is
> true, I recommend retraining it.


I meant omit a return altogether.

But looking around, I rarely see return(0).  Don't know why it became a 
thing for me.

Moving forward, return 0 it is.

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

#386100

DFS <nospam@dfs.com> writes:

> On 6/16/2024 10:41 PM, James Kuyper wrote:
>> On 6/16/24 12:20, DFS wrote:
>>> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>>>> DFS <nospam@dfs.com> writes:
>> ...
>>>>> 	return(0);
>>>>
>>>> A minor style point: a return statement doesn't require parentheses.
>>>> IMHO using parentheses make it look too much like a function call.  I'd
>>>> write `return 0;`, or more likely I'd just omit it, since falling off
>>>> the end of main does an implicit `return 0;` (starting in C99).
>>>
>>> Can't omit it.  It's required by my brain.
>> The parentheses you're putting in are completely unrelated to the use of
>> parentheses in _Generic(), function calls, compound literals,
>> sizeof(type name), alignof(), _BitInt(), _Atomic(), typeof(),
>> typeof_unqual(), alignas(), function declarators, static_assert(), if(),
>> switch(for(), while(), do ... while(), function-like macro definitions
>> and invocations or cast expressions. In all of those cases, the
>> parentheses are part of the grammar.
>> The parentheses that you put in return(0) serve only for grouping
>> purpose. They are semantically equivalent to the parentheses in "i =
>> (0);"; they are just as legal, and just as pointless.
>> If your brain doesn't immediately understand why what I said above is
>> true, I recommend retraining it.
>
> I meant omit a return altogether.
>
> But looking around, I rarely see return(0).  Don't know why it became a
> thing for me.
>
> Moving forward, return 0 it is.

By the way, you might have retained return (exp); from old C.  C
originally required the parentheses, but they got dropped quite early
on.  The syntax in K&R (1st edition) does not require them, but almost
all the code example in the book still have them!

I took a while to drop them as I came to C from B where they were always
required so I'd got the habit.

-- 
Ben.

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

#386142

On 17.06.2024 16:41, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
>>
>> Moving forward, return 0 it is.
> 
> By the way, you might have retained return (exp); from old C.  C
> originally required the parentheses, but they got dropped quite early
> on.  The syntax in K&R (1st edition) does not require them, but almost
> all the code example in the book still have them!

This is an interesting observation! (That I can confirm.)

That's probably why originally I also used parenthesis.
I saw the examples but didn't inspect the syntax appendix.

But how did the early compiler behave?
Did they follow the code samples' syntax or the formal syntax?

> I took a while to drop them as I came to C from B where they were always
> required so I'd got the habit.

I dropped them as soon as I noticed that it's possible.

Janis

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

#386161

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 17.06.2024 16:41, Ben Bacarisse wrote:
>> DFS <nospam@dfs.com> writes:
>>> Moving forward, return 0 it is.
>> 
>> By the way, you might have retained return (exp); from old C.  C
>> originally required the parentheses, but they got dropped quite early
>> on.  The syntax in K&R (1st edition) does not require them, but almost
>> all the code example in the book still have them!
>
> This is an interesting observation! (That I can confirm.)
>
> That's probably why originally I also used parenthesis.
> I saw the examples but didn't inspect the syntax appendix.
>
> But how did the early compiler behave?
> Did they follow the code samples' syntax or the formal syntax?

The syntax in the 1975 C reference manual required parentheses as part
of the syntax of a return statement:
    return ;
    return ( expression ) ;
By 1978, when K&R1 was published, the syntax had changed to:
    return ;
    return expression ;

If you write `return (42);`, even in modern C, it's still syntactically
valid.  The parentheses are simply part of the expression, not part of
the syntax of the return statement.

>> I took a while to drop them as I came to C from B where they were always
>> required so I'd got the habit.
>
> I dropped them as soon as I noticed that it's possible.

My personal preference (which I don't follow entirely consistently) is
to try to avoid making things that aren't function calls look too much
like function calls.

-- 
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]

#386047

On 6/16/24 12:20, DFS wrote:
> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
...
>>> 	return(0);
>>
>> A minor style point: a return statement doesn't require parentheses.
>> IMHO using parentheses make it look too much like a function call.  I'd
>> write `return 0;`, or more likely I'd just omit it, since falling off
>> the end of main does an implicit `return 0;` (starting in C99).
> 
> Can't omit it.  It's required by my brain.

What behavior does your brain expect of the following code?:

	return(a+b)*2;

If you have any trouble with interpreting that code, you need to retrain
your brain.

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

#385993

On Sat, 15 Jun 2024 15:36:22 -0400
DFS <nospam@dfs.com> 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?
> 
> Any 'better' way?
> 
> Thanks
> 
> 
> ----------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char *argv[]) {
> 
> 	int N=0, i=0, j=0;
> 	int *nums;
> 	
> 	FILE* datafile = fopen(argv[1], "r");
> 	while(fscanf(datafile, "%d", &j) != EOF){
> 		N++;
> 	}
> 	
> 	nums = calloc(N, sizeof(int));
> 	rewind(datafile);
> 	while(fscanf(datafile, "%d", &j) != EOF){
> 		nums[i++] = j;
> 	}
> 	fclose (datafile);
> 	printf("\n");
> 	
> 	for(i=0;i<N;i++) {
> 		printf("%d. %d\n", i+1, nums[i]);
> 	}
> 	printf("\n");
> 	free(nums);
> 	return(0);
> 				
> }
> ----------------------------------------------------------
> 
> 


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

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

#385999

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).

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

#386001

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

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

#386002

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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() ?

I advise never using any of the *scanf() functions for numeric input
unless you have control over what appears on the input stream.
They have undefined behavior if the input value is out of range.
(I consider this a bug in the language.)  Typical behavior is to
store some arbitrary integer value with no error indication.

As for reading lines, getline() can allocate a buffer long enough
to hold the line, but it's defined by POSIX, not by ISO C.

For the original problem, where the input consists of digits and
whitespace, you could read a character at a time and accumulate the
value of each number.  (You probably want to handle leading signs as
well, which isn't difficult.)  That is admittedly reinventing the
wheel, but the existing wheels aren't entirely round.  You still
have to dynamically allocate the array of ints, assuming you need
to store all of them rather than processing each value as it's read.

-- 
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]

#386003

On Sat, 15 Jun 2024 21:17:57 -0700, Keith Thompson wrote:

> .. but it's defined by POSIX, not by ISO C.

Dang. There’s another reset of the days-since-last-mention-of-POSIX-on-
this-list counter.

Has it ever actually reached 1?

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

#386004

On 16.06.2024 06:17, Keith Thompson wrote:
> 
> For the original problem, where the input consists of digits and
> whitespace, you could read a character at a time and accumulate the
> value of each number.  (You probably want to handle leading signs as
> well, which isn't difficult.) 

Yes. Been there, done that. Sometimes it's good enough to go back
to the roots if higher-level functions are imperfect or quirky.

> That is admittedly reinventing the
> wheel, but the existing wheels aren't entirely round.  You still
> have to dynamically allocate the array of ints, assuming you need
> to store all of them rather than processing each value as it's read.

A subclass of tasks can certainly process data on the fly but for
the general solution there should be a convenient way to handle it.

I still prefer higher-level languages that take the burden from me.

Janis

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

#386026

On 6/16/2024 12:44 AM, Janis Papanagnou wrote:
> On 16.06.2024 06:17, Keith Thompson wrote:
>>
>> For the original problem, where the input consists of digits and
>> whitespace, you could read a character at a time and accumulate the
>> value of each number.  (You probably want to handle leading signs as
>> well, which isn't difficult.)
> 
> Yes. Been there, done that. Sometimes it's good enough to go back
> to the roots if higher-level functions are imperfect or quirky.
> 
>> That is admittedly reinventing the
>> wheel, but the existing wheels aren't entirely round.  You still
>> have to dynamically allocate the array of ints, assuming you need
>> to store all of them rather than processing each value as it's read.
> 
> A subclass of tasks can certainly process data on the fly but for
> the general solution there should be a convenient way to handle it.
> 
> I still prefer higher-level languages that take the burden from me.

nums = []
with open('data.txt','r') as f:
	for nbr in f.read().split():
		nums.append(int(nbr))
	print(*sorted(nums))

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

#386031

On 16/06/2024 17:09, DFS wrote:
> On 6/16/2024 12:44 AM, Janis Papanagnou wrote:
>> On 16.06.2024 06:17, Keith Thompson wrote:
>>>
>>> For the original problem, where the input consists of digits and
>>> whitespace, you could read a character at a time and accumulate the
>>> value of each number.  (You probably want to handle leading signs as
>>> well, which isn't difficult.)
>>
>> Yes. Been there, done that. Sometimes it's good enough to go back
>> to the roots if higher-level functions are imperfect or quirky.
>>
>>> That is admittedly reinventing the
>>> wheel, but the existing wheels aren't entirely round.  You still
>>> have to dynamically allocate the array of ints, assuming you need
>>> to store all of them rather than processing each value as it's read.
>>
>> A subclass of tasks can certainly process data on the fly but for
>> the general solution there should be a convenient way to handle it.
>>
>> I still prefer higher-level languages that take the burden from me.
> 
> nums = []
> with open('data.txt','r') as f:
>      for nbr in f.read().split():
>          nums.append(int(nbr))
>      print(*sorted(nums))
> 

nums = sorted(map(int, open('data.txt', 'r').read().split()))

But you'll learn more doing it with C :-)  And it's nice to see someone 
starting on-topic threads here.

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

#386034

On 16/06/2024 16:56, David Brown wrote:
> On 16/06/2024 17:09, DFS wrote:
>> On 6/16/2024 12:44 AM, Janis Papanagnou wrote:
>>> On 16.06.2024 06:17, Keith Thompson wrote:
>>>>
>>>> For the original problem, where the input consists of digits and
>>>> whitespace, you could read a character at a time and accumulate the
>>>> value of each number.  (You probably want to handle leading signs as
>>>> well, which isn't difficult.)
>>>
>>> Yes. Been there, done that. Sometimes it's good enough to go back
>>> to the roots if higher-level functions are imperfect or quirky.
>>>
>>>> That is admittedly reinventing the
>>>> wheel, but the existing wheels aren't entirely round.  You still
>>>> have to dynamically allocate the array of ints, assuming you need
>>>> to store all of them rather than processing each value as it's read.
>>>
>>> A subclass of tasks can certainly process data on the fly but for
>>> the general solution there should be a convenient way to handle it.
>>>
>>> I still prefer higher-level languages that take the burden from me.
>>
>> nums = []
>> with open('data.txt','r') as f:
>>      for nbr in f.read().split():
>>          nums.append(int(nbr))
>>      print(*sorted(nums))
>>
> 
> nums = sorted(map(int, open('data.txt', 'r').read().split()))

OK, a bit of a challenge for my scripting language. I managed this first:

   nums := sort(mapv(toval, splitstring(readstrfile("data.txt"))))

It needed a change to 'splitstring' to allow a default separator 
consisting of white space of any length. And a one-line helper function 
'toval' since the usual candidates, special built-ins, were not valid 
for 'mapv'.

It also works like this:

   nums := readstrfile("data.txt") -> splitstring -> mapv(toval) -> sort

But only by chance since the 'piped' argument is the last one of 
multi-parameter functions, rather than the first.

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

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

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

csiph-web