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

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

Is this poor style?

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

Contents

  Is this poor style? "S.K.R. de Jong" <SKRdJ@nowhere.net> - 2015-01-04 00:46 +0000
    Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-03 16:58 -0800
      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-04 20:37 +1300
        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 02:32 -0800
          Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-05 09:39 +1300
            Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-04 22:53 +0000
    Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-04 01:29 +0000
    Re: Is this poor style? Morris Dovey <mrdovey@iedu.com> - 2015-01-04 00:00 -0600
      Re: Is this poor style? Morris Dovey <mrdovey@iedu.com> - 2015-01-04 02:20 -0600
    Re: Is this poor style? August Karlstrom <fusionfile@gmail.com> - 2015-01-04 15:46 +0100
      Re: Is this poor style? Ike Naar <ike@iceland.freeshell.org> - 2015-01-04 15:10 +0000
        Re: Is this poor style? August Karlstrom <fusionfile@gmail.com> - 2015-01-04 17:06 +0100
    Re: Is this poor style? Clark Smith <noaddress@nowhere.net> - 2015-01-04 15:30 +0000
      Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 07:44 -0800
        Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 00:35 +0000
          Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-05 01:02 +0000
            Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 01:43 +0000
              Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-05 11:35 +0000
              Re: Is this poor style? raltbos@xs4all.nl (Richard Bos) - 2015-01-05 12:58 +0000
                Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 13:14 +0000
            Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-05 22:02 +0000
              Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-05 14:24 -0800
                Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-06 12:26 +1300
                  Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-06 02:40 -0800
                Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-07 19:32 +0000
                  Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 20:03 +0000
                    Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-07 20:27 +0000
                      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 09:55 +1300
                        Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-07 18:13 -0600
                          Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 13:17 +1300
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 21:02 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:22 +0100
                          Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 11:33 +0000
                            Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:08 +0100
                              Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 12:54 +0000
                        Re: Is this poor style? David Brown <david.brown@hesbynett.no> - 2015-01-08 14:04 +0100
                      Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-07 13:57 -0800
                      Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-07 18:12 -0600
                    Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-07 20:56 +0000
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 21:18 +0000
                    Re: Is this poor style? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-07 21:28 +0000
              Re: Is this poor style? BartC <bc@freeuk.com> - 2015-01-06 11:28 +0000
                Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-07 20:19 +0000
                  Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-07 16:05 -0800
                    Re: Is this poor style? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-08 08:29 +0000
                    Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-12 22:08 +0000
                      Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 20:35 -0700
                        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 08:43 -0700
                          Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:38 -0700
                          Re: Is this poor style? Stephen Sprunk <stephen@sprunk.org> - 2015-03-26 15:43 -0500
                            Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 08:57 -0700
                  Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 13:23 +1300
                    Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-07 16:53 -0800
                      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 14:11 +1300
                Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-08 11:10 +1300
          Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-05 15:54 -0800
            Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-06 11:03 +0100
              Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-06 11:10 +0100
              Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-06 06:03 -0800
                Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-06 14:44 +0000
                  Re: Is this poor style? "Osmium" <r124c4u102@comcast.net> - 2015-01-06 09:10 -0600
                    Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:14 +0100
                      Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 11:31 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:06 +0100
                          Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 13:19 +0100
                          Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-08 12:53 +0000
                            Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-08 05:49 -0800
                      Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-08 08:18 -0800
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-09 07:58 +0100
                        Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:28 -0700
                          Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-03-24 13:57 -0700
                            Re: Is this poor style? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:28 -0700
                              Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-03-25 12:17 -0700
                            Re: Is this poor style? Öö Tiib <ootiib@hot.ee> - 2015-04-05 17:03 -0700
                      Re: Is this poor style? John Bode <jfbode1029@gmail.com> - 2015-01-14 11:25 -0800
                        Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-14 19:41 +0000
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-15 09:01 +0100
                        Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-15 09:35 +0100
      Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-04 11:15 -0500
        Re: Is this poor style? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-04 21:38 +0000
        Re: Is this poor style? Dr Nick <nospam-4@temporary-address.org.uk> - 2015-01-05 07:27 +0000
          Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-05 06:33 -0800
      Re: Is this poor style? Vincenzo Mercuri <nomail@yahoo.it> - 2015-01-04 18:56 +0100
      Re: Is this poor style? rouben@shady.(none) (Rouben Rostamian) - 2015-01-04 18:22 +0000
      Re: Is this poor style? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-04 21:35 +0000
      Re: Is this poor style? Ian Collins <ian-news@hotmail.com> - 2015-01-05 10:46 +1300
        Re: Is this poor style? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:36 -0800
      Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 12:05 -0800
        Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:18 -0800
          Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:32 -0800
            Re: Is this poor style? asetofsymbols@gmail.com - 2015-01-05 14:37 -0800
          Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-05 18:23 -0500
            Re: Is this poor style? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-05 23:32 +0000
        Re: Is this poor style? Keith Thompson <kst-u@mib.org> - 2015-01-05 15:31 -0800
      Re: Is this poor style? Phil Carmody <pc+usenet@asdf.org> - 2015-01-13 15:00 +0200
    Re: Is this poor style? Les Cargill <lcargill99@comcast.com> - 2015-01-04 15:07 -0600
    Re: Is this poor style? jadill33@gmail.com - 2015-01-05 15:03 -0800
    Re: Is this poor style? buja <buja66@gmail.com> - 2015-01-06 21:48 +0100
      Re: Is this poor style? Rosario193 <Rosario@invalid.invalid> - 2015-01-08 11:21 +0100
        Re: Is this poor style? buja <buja66@gmail.com> - 2015-01-08 12:42 +0100
    Re: Is this poor style? "S.K.R. de Jong" <SKRdJ@nowhere.net> - 2015-01-08 15:29 +0000
      Re: Is this poor style? James Kuyper <jameskuyper@verizon.net> - 2015-01-08 12:03 -0500

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

#55987

"Richard Heathfield" wrote:

> John Bode wrote:
>
>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>> [snip]
>>>
>>> #include <stdlib.h>
>>> #include <string.h>
>>> #include  <stdio.h>
>>> #define  G     goto
>>> #define  P     printf
>>> #define  u8    unsigned char
>>> #define  u32   unsigned int
>>>
>>
>> *Please* don't do this.
>
> He's been doing this for about 15 years, despite closely reasoned 
> arguments
> against it, repeated frequently. Realistically, do you really think he's
> suddenly going to develop some kind of cluefulness at this point?

And after all that he still doesn't know how many bits are in a u32. 

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

#56041

On Tue, 6 Jan 2015 09:10:39 -0600, "Osmium" wrote:
>"Richard Heathfield" wrote:
>
>> John Bode wrote:
>>
>>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>>> [snip]
>>>>
>>>> #include <stdlib.h>
>>>> #include <string.h>
>>>> #include  <stdio.h>
>>>> #define  G     goto
>>>> #define  P     printf
>>>> #define  u8    unsigned char
>>>> #define  u32   unsigned int
>>>>
>>>
>>> *Please* don't do this.
>>
>> He's been doing this for about 15 years, despite closely reasoned 
>> arguments
>> against it, repeated frequently. Realistically, do you really think he's
>> suddenly going to develop some kind of cluefulness at this point?
>
>And after all that he still doesn't know how many bits are in a u32. 

it could be...

but the big error i did was not use the malloc function that see
double free or free of wrong pointers....

your error is not see that the key words in a language has to be one
simbol because it is easier to indent
 and eye see it better
 and indentation is the key point in readability
    and the readability is the key point in informatic
      it is not the cpu it is not portability etc

the long names are for routines and varible for self decrive itself

than possibly you not see 95% function has to return a value or a way
to signal the error if present so it has to have 2 exit points
one for all ok one for error

than possibly not see that all arg of function can not have type as
"size_t" or "int"... if good way of programming because each arg has
to be one type of know bits len

and each variable in arg has to be in a range allow not overflow
follows calculations in routine


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

#define  G     goto
#define  P     printf
#define  R     return
#define  F     for

#define  u8    unsigned char
#define  u32   unsigned int

/* 
  This function double cat the arg string x in res
  return  0 for all ok
           in the other case [error] 
           a pointer to a string that say what goes wrong
  in the case all ok the caller has free what res point...

  2 exit point one for error one for all ok
  no exceptions use 
*/
u8*  catcat(u8**  res, u8* x)
{u8   *a, *b, *c, *r;
 u32             len;
 
 r="Error Arg"; 
 if(res==0) {ex: return r; }
 *res=0;
 if(x==0) G  ex; 
      
 r="Error strlen";
 len=strlen(x);

/* all has its limit all routine that not take 
   in count limits are wrong by design... */
      // if(len>0x7FFFFF00)       G ex;
 if(len>0x7F)             G ex;

 r="Error malloc";
 if((a=malloc(len+1))==0) G ex;
 if((b=malloc(2*len+2))==0)
          {ex1: free(a);  G ex;}

 strcpy(a, x); strcpy(b, x); strcpy(b+len, a);
  
 free(a); *res=b; R  0;
}


int main(void)
{u8  *r, *res,  big[1024];
 u32                    i;

 if(sizeof(u32)!=4 || CHAR_BIT!=8)
       {P("Sys not supported\n"); R  0;}

 if(r=catcat(&res, "test"))
       P("catcat(\"test\") failed with error %s\n", r);
 else {P("Result catcat(\"test\")=%s\n",  res);
       if(res) {free(res); res=0;}
      }

 if(r=catcat(0, "test"))
       P("catcat(0, \"test\") failed with error %s\n", r);
 else {P("Result catcat(\"test\")=%s\n",  res);
       if(res) {free(res); res=0;}
      }

 if(r=catcat(&res, 0 ))
       P("catcat(0) failed with error %s\n", r);
 else {P("Result catcat(\"test\")=%s\n",  res);
       if(res) {free(res); res=0;}
      }

 F(i=0;i<1000; ++i)
        big[i]='c';
 big[i]=0;

 if(r=catcat(&res, big ))
        P("catcat(\"big\") failed with error %s\n", r);
 else  {P("Result catcat(\"test\")=%s\n",  res);
        if(res) {free(res); res=0;}
       }

 R  0;
}

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

#56045

Rosario193 wrote:

<snip>

> your error is not see that the key words in a language has to be one
> simbol because it is easier to indent

It's really easy
    to indent
    words with
        more than
        one
        character
        as this
    example
    plainly
shows.

>  and eye see it better

No, it really doesn't. The eye is very good at its job, and can see half a 
dozen characters just as easily as one. Changes from 1995 onwards have 
increased the number of keywords in C, but I think it's still true to say 
that it would be possible for each C keyword to be a single character. The 
reason this is not done is twofold:

1) the eye likes redundancy - bigger tokens are easier to recognise than 
smaller tokens (up to a point);
2) the brain likes meaning - return x; conveys something that R x; doesn't.

>  and indentation is the key point in readability

No, it's one important aspect of readability, but it's by no means the only 
one.

<line noise snipped>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56048

On Thu, 08 Jan 2015 11:31:44 +0000, Richard Heathfield
<invalid@see.sig.invalid> wrote:

>Rosario193 wrote:
>
><snip>
>
>> your error is not see that the key words in a language has to be one
>> simbol because it is easier to indent
>
>It's really easy
>    to indent
>    words with
>        more than
>        one
>        character
>        as this
>    example
>    plainly
>shows.

my code with all the indentation fill good in a 5 or 6 ''
smartphone...  using printf return for while etc it not be so good

this means that there is enought space for one other level of
indentation one other level of complexity

>>  and eye see it better
>
>No, it really doesn't. 

no it really does it

>The eye is very good at its job, and can see half a 
>dozen characters just as easily as one. Changes from 1995 onwards have 
>increased the number of keywords in C, but I think it's still true to say 
>that it would be possible for each C keyword to be a single character. The 
>reason this is not done is twofold:
>
>1) the eye likes redundancy 

ok with one symbol key words is easier rendundance

>- bigger tokens are easier to recognise than 
>smaller tokens (up to a point);

no

>2) the brain likes meaning - return x; conveys something that R x; doesn't.

no

>>  and indentation is the key point in readability
>
>No, it's one important aspect of readability, but it's by no means the only 
>one.

no 

><line noise snipped>

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

#56050

On Thu, 08 Jan 2015 13:06:56 +0100, Rosario193
<Rosario@invalid.invalid> wrote:

>On Thu, 08 Jan 2015 11:31:44 +0000, Richard Heathfield
><invalid@see.sig.invalid> wrote:

>>No, it's one important aspect of readability, but it's by no means the only 
>>one.
>
>no 

ok is not the only aspect... so yes

>><line noise snipped>

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

#56051

Rosario193 wrote:

> On Thu, 08 Jan 2015 11:31:44 +0000, Richard Heathfield
> <invalid@see.sig.invalid> wrote:
> 
>>Rosario193 wrote:
>>
>><snip>
>>
>>> your error is not see that the key words in a language has to be one
>>> simbol because it is easier to indent
>>
>>It's really easy
>>    to indent
>>    words with
>>        more than
>>        one
>>        character
>>        as this
>>    example
>>    plainly
>>shows.
> 
> my code with all the indentation fill good in a 5 or 6 ''
> smartphone...  using printf return for while etc it not be so good

A smartphone is no doubt a fine environment in which to run programs, but 
it's a lousy environment in which to write them. You will be far more 
productive if you develop your programs in a more usable environment.

> 
> this means that there is enought space for one other level of
> indentation one other level of complexity
> 
>>>  and eye see it better
>>
>>No, it really doesn't.
> 
> no it really does it

Then you must have very strange eyes.

> 
>>The eye is very good at its job, and can see half a
>>dozen characters just as easily as one. Changes from 1995 onwards have
>>increased the number of keywords in C, but I think it's still true to say
>>that it would be possible for each C keyword to be a single character. The
>>reason this is not done is twofold:
>>
>>1) the eye likes redundancy
> 
> ok with one symbol key words is easier rendundance

Redundancy is about providing *more* information than is strictly necessary, 
and it's useful because it makes text quicker for humans to read.

Redundancy can be measured. One way to measure it is to present a text one 
character at a time, and invite the user to guess the next character. The 
more successful he or she is, the greater the redundancy in the text. The 
greater the redundancy (up to a point), the easier the text is to read.

It would be possible to define a written language of, say, a million 
different words, such that only 20 bits would be required to express any 
word. That is, we could remove ALL redundancy from the language. We could 
extend the alphabet to 32 letters (to keep the math simple). One letter 
would then encode 5 bits, so every single word in the language would consist 
of just four letters. A sentence in that language would like something like 
this:

Agxt frre gwsn clpd gccd qzne frre aqzi.

I am not convinced that this language would be easier to read than English. 
What's more, there would be no room whatsoever for mistakes. Someone with 
spelling as appalling as yours would run the risk of being misunderstood 
with every word you typed.

>>- bigger tokens are easier to recognise than
>>smaller tokens (up to a point);
> 
> no

A denial is not an argument.

> 
>>2) the brain likes meaning - return x; conveys something that R x;
>>doesn't.
> 
> no

There are none so blind as those who will not see.

>>>  and indentation is the key point in readability
>>
>>No, it's one important aspect of readability, but it's by no means the
>>only one.
> 
> no

Are you seriously arguing that indentation is the only factor in 
readability?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56056

On Thursday, January 8, 2015 12:53:40 PM UTC, Richard Heathfield wrote:
>
> It would be possible to define a written language of, say, a million 
> different words, such that only 20 bits would be required to express any 
> word. That is, we could remove ALL redundancy from the language. We could 
> extend the alphabet to 32 letters (to keep the math simple). One letter 
> would then encode 5 bits, so every single word in the language would consist 
> of just four letters. A sentence in that language would like something like 
> this:
> 
There's also inter-word and inter-sentence coherence.

If I give you the string "Baa baa black sheep", you know that there's a high probability that
the next string will be "have you any wool?". But only if you grew up in a culture where that
nursery rhyme was taught.

Now if we could remove all redundancy from the language, such that no-one could guess
with probability greater that change what the next letter would be, we'd have an extremely
powerful function. It could only produce meaningful utterances.

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

#56060

Rosario193 <Rosario@invalid.invalid> writes:
[...]
>>> John Bode wrote:
>>>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>>>> [snip]
>>>>>
>>>>> #include <stdlib.h>
>>>>> #include <string.h>
>>>>> #include  <stdio.h>
>>>>> #define  G     goto
>>>>> #define  P     printf
>>>>> #define  u8    unsigned char
>>>>> #define  u32   unsigned int
>>>>
>>>> *Please* don't do this.

[...]

> your error is not see that the key words in a language has to be one
> simbol because it is easier to indent
>  and eye see it better
>  and indentation is the key point in readability
>     and the readability is the key point in informatic
>       it is not the cpu it is not portability etc

Your error is your use of these silly one-letter macros, and in your
stubborn refusal to listen to multiple people telling you that they may
your code less readable.

When I see something like

    #define G goto

in your code, I simply stop reading.  It's not worth my time and effort
to wade through the obfuscation and figure out what the code actually
does.

Now there are two possibilities;

1. You're right that these one-letter macros make your code better.
Everyone else (and I do mean very nearly *everyone*; I don't think I've
ever seen anyone here agree with you on this point) just doesn't
understand the superiority of your coding style.  You're right and
everyone else is wrong.

2. Your macros really don't help anyone other than you.

Which do you think is more likely?

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

#56085

On Thu, 08 Jan 2015 08:18:23 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Rosario193 <Rosario@invalid.invalid> writes:
>[...]
>>>> John Bode wrote:
>>>>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>>>>> [snip]
>>>>>>
>>>>>> #include <stdlib.h>
>>>>>> #include <string.h>
>>>>>> #include  <stdio.h>
>>>>>> #define  G     goto
>>>>>> #define  P     printf
>>>>>> #define  u8    unsigned char
>>>>>> #define  u32   unsigned int
>>>>>
>>>>> *Please* don't do this.
>
>[...]
>
>> your error is not see that the key words in a language has to be one
>> simbol because it is easier to indent
>>  and eye see it better
>>  and indentation is the key point in readability
>>     and the readability is the key point in informatic
>>       it is not the cpu it is not portability etc
>
>Your error is your use of these silly one-letter macros, and in your
>stubborn refusal to listen to multiple people telling you that they may
>your code less readable.
>
>When I see something like
>
>    #define G goto
>
>in your code, I simply stop reading.  It's not worth my time and effort
>to wade through the obfuscation and figure out what the code actually
>does.
>
>Now there are two possibilities;
>
>1. You're right that these one-letter macros make your code better.
>Everyone else (and I do mean very nearly *everyone*; I don't think I've
>ever seen anyone here agree with you on this point) just doesn't
>understand the superiority of your coding style.  You're right and
>everyone else is wrong.

yes in how i see 1

quello che siamo, quello che vediamo dipende dalle nostre passate
esperienze... non dico che tutti possano vedere in un insieme di
istruzioni quello che io vedo...
quindi se nessuno ha le mie esperienze nessuno potra' vedere quello
che vedo...

che io abbia ragione o torto in assoluto...
io non sono infallibile, ho fatto poche migliai di linee di codice 
nella mia vita in asm C C++ pascal maple, 

**sarebbe strano che malgrado questo io abbia ragione**

[forse dovrei aggiungere che ho studiato fisica, matematica e
non proficuamente ho scritto un libro
di simboli e logica di diverse pagine in cui probabilmente nessun
matematico avrebbe interesse a leggere in cui credo di aver ricavato
tutte le basi della matematica *tramite calcolo proposizionale*
e operazioni permesse sui simboli]

translated:

what we are, what we see depends on our past experience ... 
I do not say that everyone can see in a set of instructions 
what I see ...

so if no one has my experience, no one will 'see what I see ...

On "I am right or wrong in absolute" ...

I am not infallible, I made a few thousand of lines of code
in my life in asm C C ++ pascal maple,

** would be strange that despite this I am right **

[I should add that I have studied physics, mathematics and
not profitably I wrote a book
on symbols and logic of several pages where probably no mathematician
would have interest in reading in which I think I've made
all the foundations of mathematics through calculus propositional
and allowed operations on symbols]

>2. Your macros really don't help anyone other than you.
>
>Which do you think is more likely?

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

#58846

Keith Thompson <kst-u@mib.org> writes:

> When I see something like
>
>     #define G goto
>
> in your code, I simply stop reading.  It's not worth my time and
> effort to wade through the obfuscation and figure out what the
> code actually does.
>
> Now there are two possibilities;
>
> 1. You're right that these one-letter macros make your code
> better.  Everyone else (and I do mean very nearly *everyone*;  I
> don't think I've ever seen anyone here agree with you on this
> point) just doesn't understand the superiority of your coding
> style.  You're right and everyone else is wrong.
>
> 2. Your macros really don't help anyone other than you.
>
> Which do you think is more likely?

There is a third possibility:  a fair number of people like or
don't mind them, and a fair number of people dislike or do mind
them.  In fact I believe this is the most likely possibility (ie,
of the three).

Don't get me wrong, I don't really like them myself, but I think
the "two possibilities" above represent a false dichotomy.

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

#58878

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> When I see something like
>>
>>     #define G goto
>>
>> in your code, I simply stop reading.  It's not worth my time and
>> effort to wade through the obfuscation and figure out what the
>> code actually does.
>>
>> Now there are two possibilities;
>>
>> 1. You're right that these one-letter macros make your code
>> better.  Everyone else (and I do mean very nearly *everyone*;  I
>> don't think I've ever seen anyone here agree with you on this
>> point) just doesn't understand the superiority of your coding
>> style.  You're right and everyone else is wrong.
>>
>> 2. Your macros really don't help anyone other than you.
>>
>> Which do you think is more likely?
>
> There is a third possibility:  a fair number of people like or
> don't mind them, and a fair number of people dislike or do mind
> them.  In fact I believe this is the most likely possibility (ie,
> of the three).
>
> Don't get me wrong, I don't really like them myself, but I think
> the "two possibilities" above represent a false dichotomy.

We're not going to settle this, but given the complete lack of
disgreement by anyone else to the vehement and repeated criticisms
of these macros, I strongly suspect that #2 is correct.

If someone wants to defend `#define G goto`, I wouldn't mind having
that discussion.

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

#58916

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> When I see something like
>>>
>>>     #define G goto
>>>
>>> in your code, I simply stop reading.  It's not worth my time and
>>> effort to wade through the obfuscation and figure out what the
>>> code actually does.
>>>
>>> Now there are two possibilities;
>>>
>>> 1.  You're right that these one-letter macros make your code
>>> better.  Everyone else (and I do mean very nearly *everyone*;  I
>>> don't think I've ever seen anyone here agree with you on this
>>> point) just doesn't understand the superiority of your coding
>>> style.  You're right and everyone else is wrong.
>>>
>>> 2.  Your macros really don't help anyone other than you.
>>>
>>> Which do you think is more likely?
>>
>> There is a third possibility:  a fair number of people like or
>> don't mind them, and a fair number of people dislike or do mind
>> them.  In fact I believe this is the most likely possibility (ie,
>> of the three).
>>
>> Don't get me wrong, I don't really like them myself, but I think
>> the "two possibilities" above represent a false dichotomy.
>
> We're not going to settle this, but given the complete lack of
> disgreement by anyone else to the vehement and repeated criticisms
> of these macros, I strongly suspect that #2 is correct.

I will gladly agree that #2 may actually be so if you
will also agree that #3 is at least a possibility.  That's
the most important part of what I was saying.

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

#58947

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> When I see something like
>>>>
>>>>     #define G goto
>>>>
>>>> in your code, I simply stop reading.  It's not worth my time and
>>>> effort to wade through the obfuscation and figure out what the
>>>> code actually does.
>>>>
>>>> Now there are two possibilities;
>>>>
>>>> 1.  You're right that these one-letter macros make your code
>>>> better.  Everyone else (and I do mean very nearly *everyone*;  I
>>>> don't think I've ever seen anyone here agree with you on this
>>>> point) just doesn't understand the superiority of your coding
>>>> style.  You're right and everyone else is wrong.
>>>>
>>>> 2.  Your macros really don't help anyone other than you.
>>>>
>>>> Which do you think is more likely?
>>>
>>> There is a third possibility:  a fair number of people like or
>>> don't mind them, and a fair number of people dislike or do mind
>>> them.  In fact I believe this is the most likely possibility (ie,
>>> of the three).
>>>
>>> Don't get me wrong, I don't really like them myself, but I think
>>> the "two possibilities" above represent a false dichotomy.
>>
>> We're not going to settle this, but given the complete lack of
>> disgreement by anyone else to the vehement and repeated criticisms
>> of these macros, I strongly suspect that #2 is correct.
>
> I will gladly agree that #2 may actually be so if you
> will also agree that #3 is at least a possibility.  That's
> the most important part of what I was saying.

Agreed.  (I don't really see the importance, but I don't think judging
the level of importance is important.)

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

#59669

On Tuesday, 24 March 2015 22:57:31 UTC+2, Keith Thompson  wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> When I see something like
> >>
> >>     #define G goto
> >>
> >> in your code, I simply stop reading.  It's not worth my time and
> >> effort to wade through the obfuscation and figure out what the
> >> code actually does.
> >>
> >> Now there are two possibilities;
> >>
> >> 1. You're right that these one-letter macros make your code
> >> better.  Everyone else (and I do mean very nearly *everyone*;  I
> >> don't think I've ever seen anyone here agree with you on this
> >> point) just doesn't understand the superiority of your coding
> >> style.  You're right and everyone else is wrong.
> >>
> >> 2. Your macros really don't help anyone other than you.
> >>
> >> Which do you think is more likely?
> >
> > There is a third possibility:  a fair number of people like or
> > don't mind them, and a fair number of people dislike or do mind
> > them.  In fact I believe this is the most likely possibility (ie,
> > of the three).
> >
> > Don't get me wrong, I don't really like them myself, but I think
> > the "two possibilities" above represent a false dichotomy.
> 
> We're not going to settle this, but given the complete lack of
> disgreement by anyone else to the vehement and repeated criticisms
> of these macros, I strongly suspect that #2 is correct.
> 
> If someone wants to defend `#define G goto`, I wouldn't mind having
> that discussion.

I have seen several of programming languages or scriptable tools
or the like where: 
Each line consists of one command. 
Line starts with "command word" followed with arguments.
The "command words" may be abbreviated while unambiguous.

Number of users of such did mostly use shortest form that was 
often one letter. Terseness was desirable for them and gentleness
towards readers was unimportant. 

Perhaps author of `#define G goto` shares such views. May be
because he works alone. However posting such cryptic code feels
rude. May be he wants to be rude, maybe because he does not
feel it as rude.

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

#56241

On Thursday, January 8, 2015 at 4:14:49 AM UTC-6, Rosario193 wrote:
> On Tue, 6 Jan 2015 09:10:39 -0600, "Osmium" wrote:
> >"Richard Heathfield" wrote:
> >
> >> John Bode wrote:
> >>
> >>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
> >>> [snip]
> >>>>
> >>>> #include <stdlib.h>
> >>>> #include <string.h>
> >>>> #include  <stdio.h>
> >>>> #define  G     goto
> >>>> #define  P     printf
> >>>> #define  u8    unsigned char
> >>>> #define  u32   unsigned int
> >>>>
> >>>
> >>> *Please* don't do this.
> >>
> >> He's been doing this for about 15 years, despite closely reasoned 
> >> arguments
> >> against it, repeated frequently. Realistically, do you really think he's
> >> suddenly going to develop some kind of cluefulness at this point?
> >
> >And after all that he still doesn't know how many bits are in a u32. 
> 
> it could be...
> 
> but the big error i did was not use the malloc function that see
> double free or free of wrong pointers....
> 
> your error is not see that the key words in a language has to be one
> simbol because it is easier to indent
>  and eye see it better
>  and indentation is the key point in readability
>     and the readability is the key point in informatic
>       it is not the cpu it is not portability etc
> 
> the long names are for routines and varible for self decrive itself
> 
> than possibly you not see 95% function has to return a value or a way
> to signal the error if present so it has to have 2 exit points
> one for all ok one for error
> 
> than possibly not see that all arg of function can not have type as
> "size_t" or "int"... if good way of programming because each arg has
> to be one type of know bits len
> 
> and each variable in arg has to be in a range allow not overflow
> follows calculations in routine
> 
> 
> #include <stdlib.h>
> #include <string.h>
> #include  <stdio.h>
> #include <limits.h>
> 
> #define  G     goto
> #define  P     printf
> #define  R     return
> #define  F     for
> 
> #define  u8    unsigned char
> #define  u32   unsigned int
> 
> /* 
>   This function double cat the arg string x in res
>   return  0 for all ok
>            in the other case [error] 
>            a pointer to a string that say what goes wrong
>   in the case all ok the caller has free what res point...
> 
>   2 exit point one for error one for all ok
>   no exceptions use 
> */
> u8*  catcat(u8**  res, u8* x)
> {u8   *a, *b, *c, *r;
>  u32             len;
>  
>  r="Error Arg"; 
>  if(res==0) {ex: return r; }
>  *res=0;
>  if(x==0) G  ex; 
>       
>  r="Error strlen";
>  len=strlen(x);
> 
> /* all has its limit all routine that not take 
>    in count limits are wrong by design... */
>       // if(len>0x7FFFFF00)       G ex;
>  if(len>0x7F)             G ex;
> 
>  r="Error malloc";
>  if((a=malloc(len+1))==0) G ex;
>  if((b=malloc(2*len+2))==0)
>           {ex1: free(a);  G ex;}
> 
>  strcpy(a, x); strcpy(b, x); strcpy(b+len, a);
>   
>  free(a); *res=b; R  0;
> }
> 
> 
> int main(void)
> {u8  *r, *res,  big[1024];
>  u32                    i;
> 
>  if(sizeof(u32)!=4 || CHAR_BIT!=8)
>        {P("Sys not supported\n"); R  0;}
> 
>  if(r=catcat(&res, "test"))
>        P("catcat(\"test\") failed with error %s\n", r);
>  else {P("Result catcat(\"test\")=%s\n",  res);
>        if(res) {free(res); res=0;}
>       }
> 
>  if(r=catcat(0, "test"))
>        P("catcat(0, \"test\") failed with error %s\n", r);
>  else {P("Result catcat(\"test\")=%s\n",  res);
>        if(res) {free(res); res=0;}
>       }
> 
>  if(r=catcat(&res, 0 ))
>        P("catcat(0) failed with error %s\n", r);
>  else {P("Result catcat(\"test\")=%s\n",  res);
>        if(res) {free(res); res=0;}
>       }
> 
>  F(i=0;i<1000; ++i)
>         big[i]='c';
>  big[i]=0;
> 
>  if(r=catcat(&res, big ))
>         P("catcat(\"big\") failed with error %s\n", r);
>  else  {P("Result catcat(\"test\")=%s\n",  res);
>         if(res) {free(res); res=0;}
>        }
> 
>  R  0;
> }

Why not go for the brass ring and get rid of all that extraneous whitespace
like this dude:

http://code.kx.com/wsvn/code/kx/kdb%2B/c/2.3/c.java  

Production code, written by a lunatic.

The problem with these schemes is no two people can ever agree on what the
short names should be.  You use P for printf, but some other dude uses it
for popen, while someone else uses it for malloc (because they already used 
M for something else).  Everybody's creating their own special versions of C
with almost no commonality between them.  

I have been in this movie.  It ends in tears for everybody.

C keywords tend to be short; they're the same for everybody; syntax-
aware editors can highlight them for you; nobody has to go digging through
reams of header files to see what they map to.  There simply
is no compelling reason to create preprocessor macros for C keywords.  
None.  

Typedefs, sure, sometimes you want a simpler type name, or you want to
abstract away implementation details.  

Keyword synonyms, not even once.  

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

#56242

John Bode wrote:

<snip>

> Why not go for the brass ring and get rid of all that extraneous
> whitespace like this dude:
> 
> http://code.kx.com/wsvn/code/kx/kdb%2B/c/2.3/c.java
> 
> Production code, written by a lunatic.

He is far too wasteful - look at all those newlines!

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#56274

On Wed, 14 Jan 2015 11:25:25 -0800 (PST), John Bode
<jfbode1029@gmail.com> wrote:

>On Thursday, January 8, 2015 at 4:14:49 AM UTC-6, Rosario193 wrote:
>> On Tue, 6 Jan 2015 09:10:39 -0600, "Osmium" wrote:
>> >"Richard Heathfield" wrote:
>> >
>> >> John Bode wrote:
>> >>
>> >>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>> >>> [snip]
>> >>>>
>> >>>> #include <stdlib.h>
>> >>>> #include <string.h>
>> >>>> #include  <stdio.h>
>> >>>> #define  G     goto
>> >>>> #define  P     printf
>> >>>> #define  u8    unsigned char
>> >>>> #define  u32   unsigned int
>> >>>>
>> >>>
>> >>> *Please* don't do this.

>Why not go for the brass ring and get rid of all that extraneous whitespace
>like this dude:
>
>http://code.kx.com/wsvn/code/kx/kdb%2B/c/2.3/c.java  
>
>Production code, written by a lunatic.
>
>The problem with these schemes is no two people can ever agree on what the
>short names should be.  You use P for printf, but some other dude uses it
>for popen, 

popen does not need a new name as a macro of one letter because it is
not used much in code... the words that are candidates to have macro
of one letter are only the ones that are always used: for() while()
goto printf malloc free and return. type names associated with their
size as u32 f64 i32 etc too and no other

i not say this is miraculous

>while someone else uses it for malloc (because they already used 
>M for something else).  Everybody's creating their own special versions of C
>with almost no commonality between them.  
>
>I have been in this movie.  It ends in tears for everybody.

so not use them... i'm just one and i used in some small code always
the same macro...
than i follow one convenction: names in uppercase are macro

>C keywords tend to be short; they're the same for everybody; syntax-
>aware editors can highlight them for you; nobody has to go digging through
>reams of header files to see what they map to.  There simply
>is no compelling reason to create preprocessor macros for C keywords.  
>None.  
>
>Typedefs, sure, sometimes you want a simpler type name, or you want to
>abstract away implementation details.  
>
>Keyword synonyms, not even once.  

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

#56277

On Wed, 14 Jan 2015 11:25:25 -0800 (PST), John Bode wrote:

>On Thursday, January 8, 2015 at 4:14:49 AM UTC-6, Rosario193 wrote:
>> On Tue, 6 Jan 2015 09:10:39 -0600, "Osmium" wrote:
>> >"Richard Heathfield" wrote:
>> >
>> >> John Bode wrote:
>> >>
>> >>> On Tuesday, January 6, 2015 4:03:46 AM UTC-6, Rosario193 wrote:
>> >>> [snip]
>> >>>>
>> >>>> #include <stdlib.h>
>> >>>> #include <string.h>
>> >>>> #include  <stdio.h>
>> >>>> #define  G     goto
>> >>>> #define  P     printf
>> >>>> #define  u8    unsigned char
>> >>>> #define  u32   unsigned int
>> >>>>
>> >>>
>> >>> *Please* don't do this.
>Why not go for the brass ring and get rid of all that extraneous whitespace
>like this dude:
>
>http://code.kx.com/wsvn/code/kx/kdb%2B/c/2.3/c.java  

I seen the code... for me it is wrong because i have convenction that
name library function or routine [different from printf() malloc free]
has to have a [short]name that say what these functions and routines
does example  getu32FromConsole()

i have not know java so i can not criticize too much
but it seems to me too many little routines

>Production code, written by a lunatic.

>The problem with these schemes is no two people can ever agree on what the
>short names should be.  You use P for printf, but some other dude uses it
>for popen, while someone else uses it for malloc (because they already used 
>M for something else).  Everybody's creating their own special versions of C
>with almost no commonality between them.  
>
>I have been in this movie.  It ends in tears for everybody.

i use only the same macros i not find problems
i use convenction uppercase names are macro and viceversa

>C keywords tend to be short; they're the same for everybody; syntax-
>aware editors can highlight them for you; nobody has to go digging through
>reams of header files to see what they map to.  There simply
>is no compelling reason to create preprocessor macros for C keywords.  
>None.  

none in how you see

>Typedefs, sure, sometimes you want a simpler type name, or you want to
>abstract away implementation details.  
>
>Keyword synonyms, not even once.  

than all you continue your way i know what is ok and what not...

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

#55820

On 01/04/2015 10:30 AM, Clark Smith wrote:
> On Sun, 04 Jan 2015 00:46:44 +0000, S.K.R. de Jong wrote:
> 
>> I would like the opinion of people in this forum as to whether or not
>> the following is poor style:
>>
>> 	int f(char *x)
>> 	{
>> 		int diagnostic = 0;
>>
>> 		do {
>> 			if (x == NULL)
>> 				break;
>>
>> 			...
>>
>> 			diagnostic = 1;
>>
>> 		} while(0);
>>
>> 		return diagnostic;
>> 	}
>>
>> The same could be accomplished with goto, of course. Which kind of
>> construct is more acceptable for dealing with error conditions: the
>> empty while loop? goto with labels? Something else?
> 
> 	I thought that the ellipsis would convey what I meant, but that 
> does not seem to have been the case. Here is a nonsensical, toy example 
> that illustrates better what I have in mind:
> 
> 	int f(char *x, int l)
> 	{
> 		char *a = NULL, *b = NULL;
> 		int diagnostic = 0;
> 
> 		do {
> 			if (x == NULL)
> 				break;
> 
> 			if (l > 255)
> 				break;
> 
> 			a = malloc(256);
> 			if (a == NULL)
> 				break;
> 
> 			b = malloc(2*256);
> 			if (b == NULL)
> 				break;
> 
> 			strcpy(a, x);
> 			strcpy(b, x);
> 			strcpy(&b[255], a);
> 
> 			diagnostic = 1;
> 		} while(0);
> 
> 		if (diagnostic == 0) {
> 			if (a != NULL)
> 				free(a);
> 			if (b != NULL)
> 				free(b);
> 		}
> 
> 		return diagnostic;
> 	}
> 
> 
> The idea is that some actions must be taken that must be correctly undone 
> in case of error.

That is an essential point; the fact that it's missing from your
original example is why the answers you received were not to the point.

Here's how I would have handled your toy example:

	int f(char *x, int l)
	{
                if(x==NULL || l > 255)
                    return 0;

		int diagnostic = 0;
                char *a = malloc(256);

                if(a==NULL)
                    return 0;

                char *b = malloc(2*256);

                if(b)
                {
			strcpy(a, x);
			strcpy(b, x);
			strcpy(&b[255], a);
                        free(b);
                        diagnostic = 1;
                }
                free(a);

		return diagnostic;
	}

This structure makes it easy to verify that a is free()d only if
successfully allocated, b is free()d only if successfully allocated, and
the core part of the code is executed only if both are successfully
allocated.
-- 
James Kuyper

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

#55843

On Sun, 2015-01-04, James Kuyper wrote:
> On 01/04/2015 10:30 AM, Clark Smith wrote:
>> On Sun, 04 Jan 2015 00:46:44 +0000, S.K.R. de Jong wrote:
>> 
>>> I would like the opinion of people in this forum as to whether or not
>>> the following is poor style:
>>>
>>> 	int f(char *x)
>>> 	{
>>> 		int diagnostic = 0;
>>>
>>> 		do {
>>> 			if (x == NULL)
>>> 				break;
>>>
>>> 			...
>>>
>>> 			diagnostic = 1;
>>>
>>> 		} while(0);
>>>
>>> 		return diagnostic;
>>> 	}
>>>
>>> The same could be accomplished with goto, of course. Which kind of
>>> construct is more acceptable for dealing with error conditions: the
>>> empty while loop? goto with labels? Something else?
>> 
>> 	I thought that the ellipsis would convey what I meant, but that 
>> does not seem to have been the case. Here is a nonsensical, toy example 
>> that illustrates better what I have in mind:
>> 
>> 	int f(char *x, int l)
>> 	{
>> 		char *a = NULL, *b = NULL;
>> 		int diagnostic = 0;
>> 
>> 		do {
>> 			if (x == NULL)
>> 				break;
>> 
>> 			if (l > 255)
>> 				break;
>> 
>> 			a = malloc(256);
>> 			if (a == NULL)
>> 				break;
>> 
>> 			b = malloc(2*256);
>> 			if (b == NULL)
>> 				break;
>> 
>> 			strcpy(a, x);
>> 			strcpy(b, x);
>> 			strcpy(&b[255], a);
>> 
>> 			diagnostic = 1;
>> 		} while(0);
>> 
>> 		if (diagnostic == 0) {
>> 			if (a != NULL)
>> 				free(a);
>> 			if (b != NULL)
>> 				free(b);
>> 		}
>> 
>> 		return diagnostic;
>> 	}
>> 
>> 
>> The idea is that some actions must be taken that must be correctly undone 
>> in case of error.
>
> That is an essential point; the fact that it's missing from your
> original example is why the answers you received were not to the point.
>
> Here's how I would have handled your toy example:
>
> 	int f(char *x, int l)
> 	{
>                 if(x==NULL || l > 255)
>                     return 0;
>
> 		int diagnostic = 0;
>                 char *a = malloc(256);
>
>                 if(a==NULL)
>                     return 0;
>
>                 char *b = malloc(2*256);
>
>                 if(b)
>                 {
> 			strcpy(a, x);
> 			strcpy(b, x);
> 			strcpy(&b[255], a);
>                         free(b);
>                         diagnostic = 1;
>                 }
>                 free(a);
>
> 		return diagnostic;
> 	}

My version (without looking at JK's first):

    bool f(char *x, int m)
    {
        if (m > 255 || !x) return false;
    
        char* const a = malloc(256);
        char* const b = malloc(2*256);
    
        if(!a || !b) {
    	    free(a);
    	    free(b);
    	    return false;
        }
    
        strcpy(a, x);
        strcpy(b, x);
        strcpy(&b[255], a);
        return true;
    }

If I have a point, it is that much of the time you don't have to do
weird things with control flow.  But I agree this much: when you /do/
have to, I prefer the do ... while(0) and break idiom to goto.

And in case noone mentioned it yet: it /is/ an idiom.  I remember we
had it in our style guidelines at a previous job.  (We had to use a
weird library which forced us to do a lot of resource allocation, so
we sadly had to have specific guidelines around cleanup.)

The "goto err" thing is another idiom, popular e.g. in the Linux
kernel.

I don't mind either of them much, but I /do/ mind when people fall in
love with them and give every function an advanced error-handling
framework, no matter if one is needed.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

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

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

csiph-web