Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #165626 > unrolled thread
| Started by | Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> |
|---|---|
| First post | 2022-04-12 18:05 +0000 |
| Last post | 2022-04-14 12:39 +0200 |
| Articles | 2 on this page of 22 — 10 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Memorizing C operator precedence Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-04-12 18:05 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-13 18:09 +0000
Re: Memorizing C operator precedence Siri Cruise <chine.bleu@yahoo.com> - 2022-04-13 15:23 -0700
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-13 23:36 +0000
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-13 23:48 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-14 10:38 +0000
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-14 21:05 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-16 14:27 +0000
Re: Memorizing C operator precedence Paul N <gw7rib@aol.com> - 2022-04-23 10:23 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-25 10:21 +0000
Re: Memorizing C operator precedence Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-25 16:43 +0100
Re: Memorizing C operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 03:02 -0700
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-26 13:58 +0000
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 14:48 -0700
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 15:16 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 10:34 +0000
Re: Memorizing C operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-26 13:13 +0100
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 17:25 +0000
Re: Memorizing C operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 06:12 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 17:17 +0000
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-30 07:05 -0700
Re: Memorizing C operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 12:39 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-04-30 07:05 -0700 |
| Message-ID | <86v8uq4qfg.fsf@linuxsc.com> |
| In reply to | #165939 |
Alan Mackenzie <acm@muc.de> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
[...]
I should note here that I have read through your previous
comments but don't have any response to them at this time.
>> .... but it's already way below threshold for any reasonable
>> standard of code review.
>
> This is simply untrue.
My statement is a statement of opinion, not a statement of fact,
and so it is neither true nor false -- it is just my opinion.
> That piece of code has been reviewed many times, including by
> me, and presents no particular difficulties in understanding.
>
> I don't think it could be written better.
Different people have different metrics for "better". I'm
interested to hear reactions from other people on this question.
To give some additional context, below is the function forw_comment,
taken from syntax.c in emacs 28.1, and which containts the if()
expression (or something very much like it) under discussion.
What do other comp.lang.c folks think of the code below? Does it
present any difficulties in understanding it? Can or should it
be revised to make it "better"? If yes, what kinds of changes
would make it better? Any other comments are also welcome.
(The excerpt below starts with a function-level comment, and after
that has one C function definition. There is no indentation except
what was present in the original code, and there is nothing more in
the posting after the excerpt.)
/* Jump over a comment, assuming we are at the beginning of one.
FROM is the current position.
FROM_BYTE is the bytepos corresponding to FROM.
Do not move past STOP (a charpos).
The comment over which we have to jump is of style STYLE
(either SYNTAX_FLAGS_COMMENT_STYLE (foo) or ST_COMMENT_STYLE).
NESTING should be positive to indicate the nesting at the beginning
for nested comments and should be zero or negative else.
ST_COMMENT_STYLE cannot be nested.
PREV_SYNTAX is the SYNTAX_WITH_FLAGS of the previous character
(or 0 if the search cannot start in the middle of a two-character).
If successful, return true and store the charpos of the comment's
end into *CHARPOS_PTR and the corresponding bytepos into
*BYTEPOS_PTR. Else, return false and store the charpos STOP into
*CHARPOS_PTR, the corresponding bytepos into *BYTEPOS_PTR and the
current nesting (as defined for state->incomment) in
*INCOMMENT_PTR. Should the last character scanned in an incomplete
comment be a possible first character of a two character construct,
we store its SYNTAX_WITH_FLAGS into *last_syntax_ptr. Otherwise,
we store Smax into *last_syntax_ptr.
The comment end is the last character of the comment rather than the
character just after the comment.
Global syntax data is assumed to initially be valid for FROM and
remains valid for forward search starting at the returned position. */
static bool
forw_comment (ptrdiff_t from, ptrdiff_t from_byte, ptrdiff_t stop,
EMACS_INT nesting, int style, int prev_syntax,
ptrdiff_t *charpos_ptr, ptrdiff_t *bytepos_ptr,
EMACS_INT *incomment_ptr, int *last_syntax_ptr)
{
unsigned short int quit_count = 0;
int c, c1;
enum syntaxcode code;
int syntax, other_syntax;
if (nesting <= 0) nesting = -1;
/* Enter the loop in the middle so that we find
a 2-char comment ender if we start in the middle of it. */
syntax = prev_syntax;
code = syntax & 0xff;
if (syntax != 0 && from < stop) goto forw_incomment;
while (1)
{
if (from == stop)
{
*incomment_ptr = nesting;
*charpos_ptr = from;
*bytepos_ptr = from_byte;
*last_syntax_ptr =
(code == Sescape || code == Scharquote
|| SYNTAX_FLAGS_COMEND_FIRST (syntax)
|| (nesting > 0
&& SYNTAX_FLAGS_COMSTART_FIRST (syntax)))
? syntax : Smax ;
return 0;
}
c = FETCH_CHAR_AS_MULTIBYTE (from_byte);
syntax = SYNTAX_WITH_FLAGS (c);
code = syntax & 0xff;
if (code == Sendcomment
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style
&& (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ?
(nesting > 0 && --nesting == 0) : nesting < 0)
&& !(comment_end_can_be_escaped && char_quoted (from, from_byte)))
/* We have encountered a comment end of the same style
as the comment sequence which began this comment
section. */
break;
if (code == Scomment_fence
&& style == ST_COMMENT_STYLE)
/* We have encountered a comment end of the same style
as the comment sequence which began this comment
section. */
break;
if (nesting > 0
&& code == Scomment
&& SYNTAX_FLAGS_COMMENT_NESTED (syntax)
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style)
/* We have encountered a nested comment of the same style
as the comment sequence which began this comment section. */
nesting++;
if (comment_end_can_be_escaped
&& (code == Sescape || code == Scharquote))
{
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
if (from == stop) continue; /* Failure */
}
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
forw_incomment:
if (from < stop && SYNTAX_FLAGS_COMEND_FIRST (syntax)
&& (c1 = FETCH_CHAR_AS_MULTIBYTE (from_byte),
other_syntax = SYNTAX_WITH_FLAGS (c1),
SYNTAX_FLAGS_COMEND_SECOND (other_syntax))
&& SYNTAX_FLAGS_COMMENT_STYLE (syntax, other_syntax) == style
&& ((SYNTAX_FLAGS_COMMENT_NESTED (syntax) ||
SYNTAX_FLAGS_COMMENT_NESTED (other_syntax))
? nesting > 0 : nesting < 0))
{
syntax = Smax; /* So that "|#" (lisp) can not return
the syntax of "#" in *last_syntax_ptr. */
if (--nesting <= 0)
/* We have encountered a comment end of the same style
as the comment sequence which began this comment section. */
break;
else
{
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
}
}
if (nesting > 0
&& from < stop
&& SYNTAX_FLAGS_COMSTART_FIRST (syntax)
&& (c1 = FETCH_CHAR_AS_MULTIBYTE (from_byte),
other_syntax = SYNTAX_WITH_FLAGS (c1),
SYNTAX_FLAGS_COMMENT_STYLE (other_syntax, syntax) == style
&& SYNTAX_FLAGS_COMSTART_SECOND (other_syntax))
&& (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ||
SYNTAX_FLAGS_COMMENT_NESTED (other_syntax)))
/* We have encountered a nested comment of the same style
as the comment sequence which began this comment section. */
{
syntax = Smax; /* So that "#|#" isn't also a comment ender. */
inc_both (&from, &from_byte);
UPDATE_SYNTAX_TABLE_FORWARD (from);
nesting++;
}
rarely_quit (++quit_count);
}
*charpos_ptr = from;
*bytepos_ptr = from_byte;
*last_syntax_ptr = Smax; /* Any syntactic power the last byte had is
used up. */
return 1;
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-04-14 12:39 +0200 |
| Message-ID | <t38tm6$hr6$1@dont-email.me> |
| In reply to | #165660 |
On 13/04/2022 20:09, Alan Mackenzie wrote: > Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> wrote: >> On 12 Apr 2022 13:03:39 GMT, Stefan Ram wrote: > >>> [...] > >> What for? Use parentheses - that's what they are there for. > > If you want to use parentheses, you should be writing in Lisp. ;-) > > Too many parentheses can make C code difficult to read. Difficult to > read translates to "more bugs". A knowledge of C's precedence levels, > at least to a moderate degree, can help avoid such bugs. > The challenge with "moderate degree" is that no one can agree where that lies. > Maybe some day we'll get the compiler warning "unnecessary parentheses". > Or more usefully (IMHO, of course), a warning for overly complicated expressions that would be better split up. If you are not sure whether parentheses are necessary or not, or would help some readers and annoy others, then that's a good clue that separate statements could be a better arrangement. Local variables are free, after all - mistakes and misunderstandings are not.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.c
csiph-web