[SOLVED] Stuck on a c problem. Things happening out of order.

jmgibson1981 · 04-07-2023, 05:41 PM

Code:

char * scan_data(char * str)
{
  // declare & initialize
  char temp[64];

  clear_stdout();

  // prompt for name of new account holder
  if (strcmp(str, "name")) {
    printf("enter name of new account holder --> ");
    fgets(temp, 64, stdin);
    no_more_newline(temp);
  }

  // prompt for deposit value
  if (strcmp(str, "deposit")) {
    printf("enter amount of deposit --> ");
    scanf("%s", temp);
  }

  return(validate_data(str, temp));
}

I'm calling these from a do while loop.

Code:

  // declare and initialize
  char * name = NULL;
  char * deposit = NULL;

  do {
    name = scan_data("name");
  } while (name == NULL);

  do {
    deposit = scan_data("deposit");
  } while (deposit == NULL);

The problem is that for some reason it fires the deposit option first. I can't figure why that is?

If I reverse which one is first in the do while loops it works correctly.

astrogeek · 04-07-2023, 06:17 PM

I think your string comparison tests are the reverse sense they should be.

As shown in your example those will test true when they are not equal.

I suspect that what you intend is like this (changes shown in red):

Code:

  // prompt for name of new account holder
  if (strcmp(str, "name")==0) {
   ...
  }

  // prompt for deposit value
  if (strcmp(str, "deposit")==0) {
   ...
  }

rknichols · 04-07-2023, 06:24 PM

Also, you are sending those prompt strings to stdout, which is line-buffered by default, and you would need to call "fflush(stdout)" to force the unterminated line to be displayed. Prompt strings are more commonly sent to stderr, which is less likely to be redirected away from the terminal, and which is, by default, unbuffered.

jmgibson1981 · 04-07-2023, 06:36 PM

Thank you both.

Changing strcmp to test == 0 worked.

I will look into redirecting to stderr.

sundialsvcs · 04-11-2023, 07:57 PM

Very long ago in a "C" project I finally got tired of this nonsense and created a one-liner str_is() function ... "Boom. That's what I mean."

I went through the project – which as usual I did not originate – identified repetitive sections of logic (any one of which, in "C", could be "not-obviously tpyo'd...")

and spun them off into "what I mean is ..." functions. (Along the way, I found quite a few bugs that hadn't been discovered yet.)

pan64 · 04-12-2023, 05:19 AM

I guess reading the man page can help:

Quote:

RETURN VALUE
The strcmp() and strncmp() functions return an integer less than, equal to, or greater than zero if s1 (or the first n bytes thereof) is found, respectively, to be less than, to match, or be greater than s2.

not that difficult, and works in most cases.

sundialsvcs · 04-12-2023, 09:45 AM

This is one reason why I have come to prefer [compiled ...] languages that are "higher level" than good ol' "C." Yes, "it's a damned sight better than assembler language, but not by much." You can very(!) easily "typo" something, and it still compiles. You are constantly obliged to write source code to suit the language, not to express your intent.

Fortunately, we now have well-developed "compiler suites," such as the immortal gcc family, which now give you many ways to "express yourself on the front end," and they will all result in an efficient program file produced by the same "back end" technology. No matter how you choose to write it, it all comes out very much the same and it all runs very fast.

Of course, interpreters have also come a very long way. Internally, they're based on the same "compiler" technology but they "do it on the fly." And they're easily fast enough now to be useful.