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


Groups > comp.lang.c > #382988

Re: getOpsFromSelf() (Long Post)

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: getOpsFromSelf() (Long Post)
Date 2024-02-25 00:48 +0000
Organization A noiseless patient Spider
Message-ID <87le799xnr.fsf@bsb.me.uk> (permalink)
References <ur1ie5$2cgfo$1@dont-email.me> <jh8EdBXIFQu4WLaKt@bongo-ra.co> <urdmnf$1d3vr$2@dont-email.me>

Show all headers | View raw


porkchop@invalid.foo (Mike Sanders) writes:

> Spiros Bousbouras <spibou@gmail.com> wrote:
>
>> Compared to other options like command line options or configuration files or
>> environmental variables or asking the user interactively to set the values ,
>> this approach seems very much worse. It is a lot less practical *and* fragile.
>> How can you know that this specific string will exist at a certain position
>> in the executable ?
>
> Because it checks that does...
>
>>>     // ensure last 3 bytes are digits, else return
>>>     for (int i = 0; i < 2; i++) if (!isdigit(bytes[i])) return;
>  
>> What happens if  getpath()  returns NULL ?
>
> Ouch busted...
>  
>> You keep writing 3 .Best to use a symbolic constant.
>
> Why? 3 is always 3. Maybe I dont undestand what you mean...

And 3 != 2.  Maybe using "CODE_LENGTH" everywhere would have prevented
the (probable) bug above where the loop tests only two characters.
After

  #define CODE_LENGTH 3

would you have written

  for (int i = 0; i < CODE_LENGTH - 1; i++) ...

?  I don't know, but I think you might have thought twice about that -1.

>> I take it  ops  is a global variable ?
>
> In this example, yes.
>
>> On Unix , if you just want to test for the existence of a file , access()
>> is a simpler way to do it.
>> 
>>>     char *path_env = getenv("PATH");
>>>     if (!path_env) return NULL;
>>> 
>>>     char path_env_copy[MAX_SIZE];
>>>     strncpy(path_env_copy, path_env, sizeof(path_env_copy));
>>>     path_env_copy[sizeof(path_env_copy) - 1] = '\0';
>>> 
>>>     char full_path[MAX_SIZE];
>>>     char *dir = strtok(path_env_copy, PATH_SEPARATOR);
>>> 
>>>     while (dir) {
>>>         snprintf(full_path, sizeof(full_path), "%s%s%s", dir, 
>>>             (dir[strlen(dir) - 1] == DIR_SEPARATOR[0] ? "" :
>>>                 DIR_SEPARATOR), fname);
>>>         if (stat(full_path, &buffer) == 0) {
>>>             char *result = strdup(full_path);
>>>             if (!result) return NULL; // memory allocation error <--
>
>> This line is redundant.
>
> Please explain why you think so.

Given the following line (return result;) there is no point in returning
NULL is the special case where result is NULL since NULL will be
returned when result is NULL.  In fact, the whole three-line compound
statement is (semantically) equivalent to

  return strdup(full_path);

>> I wouldn't use  strtok()  at all for this but rather  strchr()  and keep
>> track myself of the position in the string and not modify the string at
>> all. This way
>> 
>> - you can use the string returned by  getenv()  directly instead of having
>>   to copy it.
>> 
>> - you don't have to call  strlen()  when you have already traversed the
>>   string to find the separator. Traversing the string for a second time
>>   probably won't have a noticeable effect for performance in this context
>>   but this kind of thing where the code has done a certain somewhat costly
>>   computation (traversing part of the string) and then immediately does
>>   again almost the same computation instead of using the result found by
>>   the first computation , grates me.
>
> I dunno, is it perfect? Nah. Is it a good start? Well, yeah =)

I could not tell what it was supposed to do so I didn't comment, but
there's definitely a "let's just try" sense to the code.  For example,
you examine and use three characters, but you don't test if three
characters were actually read.

One specific C issue did jump out at me:

  "A binary stream need not meaningfully support fseek calls with a
  whence value of SEEK_END."

-- 
Ben.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-20 06:56 +0000
  Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-24 16:19 +0000
    Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-24 17:06 +0000
      Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-24 21:25 +0000
        Re: getOpsFromSelf() (Long Post) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-24 17:59 -0800
          Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-25 11:49 +0000
            Re: getOpsFromSelf() (Long Post) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-25 14:54 -0800
              Re: getOpsFromSelf() (Long Post) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-25 22:58 +0000
              Re: getOpsFromSelf() (Long Post) dave_thompson_2@comcast.net - 2024-03-01 18:37 -0500
                Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-03-02 01:10 +0000
                Re: getOpsFromSelf() (Long Post) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-03-02 02:36 +0000
                Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-03-02 12:13 +0000
        Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-26 15:07 +0000
          Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-03-02 12:16 +0000
    Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-24 21:22 +0000
      Re: getOpsFromSelf() (Long Post) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-25 00:48 +0000
        Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-25 01:51 +0000
      Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-26 14:50 +0000
        Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-26 15:15 +0000
        Re: getOpsFromSelf() (Long Post) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-26 13:38 -0800
        Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-26 21:40 +0000
        Re: getOpsFromSelf() (Long Post) scott@slp53.sl.home (Scott Lurndal) - 2024-02-27 16:17 +0000
        Re: getOpsFromSelf() (Long Post) Spiros Bousbouras <spibou@gmail.com> - 2024-02-27 17:04 +0000
        Re: getOpsFromSelf() (Long Post) David Brown <david.brown@hesbynett.no> - 2024-02-27 18:20 +0100
    Re: getOpsFromSelf() (Long Post) scott@slp53.sl.home (Scott Lurndal) - 2024-02-25 18:42 +0000
      Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-02-26 15:20 +0000
  Re: getOpsFromSelf() (Long Post) immibis <news@immibis.com> - 2024-02-28 22:21 +0100
    Re: getOpsFromSelf() (Long Post) porkchop@invalid.foo (Mike Sanders) - 2024-03-01 00:38 +0000

csiph-web