puts(get_string(i)); /*adds \n */

printf ("%s", get_string(1));

David Chapman
San Jose, CA

A

Thanks for your reply. As I suggested in my original article, if one needs to sort a linked list, it might be just as simple to keep an array of pointers to the data items and sort that instead.

Thanks also for pointing out the potential problem with the format specifier. Most likely, the percent character (%) will not appear in text followed by any character other than a space. This will be an invalid conversion specifier whose behavior is undefined by the ANSI standard. This is another "little gotcha" of the type described in the answer to the next question.

On some machine/compiler combinations, the percent sign will show up on the output. On others, it will disappear. Of course if % is followed by a legitimate conversion character, garbage will appear on the output or the program may bomb.

If the specifier was for a float number (e.g. %f), then it is possible that the value picked up will be an invalid floating-point number and a floating-point exception will occur.

In practice, the return value of get_string will not usually be passed to printf. Instead, it will be a parameter to some display function that will display it with an attribute and/or in some window.

For those further interested in making programs portable, you might want to investigate the internationalization functions that are specified under the Xopen Portability Guidelines (XPG). These functions are available under OSF UNIX, and probably are available on several other systems. Xopen is a consortium of European computer vendors.

A brief description of the design of the functions may help you develop your own if you are on a system that does not support them.

The functions use a message catalog file that is specific to a single language. The catalog file contains all strings that need to be translated to another language. The files for each language are kept in a separate directory. The strings in the catalog are arranged in sets. Each set has an identifying number and each string within the set has a unique number within that set.

The initial function, catopen, opens the appropriate file corresponding to the filename passed to it. The directory for the file (i.e. the language of the file) is derived using the environment variables NLSPATH and LANG. catopen returns a catalog identifier used by the remainder of the functions.

The function corresponding to the get_string example is catgets. Its four parameters are the catalog identifier, a set number within the catalog, a string number with the set, and a default string. It returns a pointer to the corresponding string. If the routine is unable to access the particular string, it returns a pointer to the default string.

Regarding the answer you gave to reader Willi Fleischer of Moerfelden, Germany (CUJ, September 1992, page 114) on the use of variable parameter list, I have tried to solve a problem of the same kind: to pass the variable arguments from a function to a function (which can be nested). The solution I found, though it needs to be verified on different platforms (I tested on SGI and IBM UNIX workstations), is to call the function that needs the variable argument list and to prevent it from adding any element to the calling function's stack.

Jeff Dragovich
Urbana, Illinois

A

The answer is as you have just described it. The BSD functions can play games with the inode (which contains the length of the file and data block-allocation information). Obviously you can run out of space when you truncate the file, as you will be making a copy of it.

Since our theme is portability this month, let me suggest how to make functions like these portable. You can create a compatibility library of functions that you commonly use. For example, instead of using ftruncate, you might make up functions as:

int file_truncate_by_fd(int file_descriptor, unsigned int size);
int file_truncate_by_name(char *file_name, unsigned int size);

In your BSD version of the library, these functions could call truncate and ftruncate. Alternatively, you could #define them in the header file to be the appropriate call, so the functions will be called inline, without an extra function call layer. For the MS-DOS version, the functions would perform the operations you listed.

For all versions, the functions should return an error indication if the truncation was unable to be performed. Note that it is logically impossible for the BSD version to fail to truncate, while the MS-DOS version may fail if there is insufficient disk space.

According to my reading of Harbison and Steele, (I don't have a copy of the ANSI Standard document), sscanf should return 4 on string[0], and 5 on string[1]. I suspect the return of 4 may be the result of an error in the code as published (should string[0] b e garbageR A 3 0 4 ?), but, as you pointed out, string[1] scanning using the [^PR] conversion operator will stop immediately upon seeing the R; no conversion will take place. Since the assignment-suppression operator is involved, this won't affect the rest of the conversion. No pointers would be consumed in either case. Conversion will then pick up at the first %c, and continue with the other char and the three ints, all of which are present in string[1]. Am I correct in this, or am I missing yet one more subtlety in sscanf formatting?

By the way, sscanf behaves this way in Borland C++ version 3.1; previous versions of Turbo C/C++ would, believe it or not, cause a null-pointer error with this usage of sscanf.

Thanks for your attention in this.

Dan Rempel
Victoria, B.C. Canada

A

Thank you for your sharp eye in catching the code error. I'll repeat the relevant code here, so our readers won't have to go back. The strings (with your correction) are:

char *string[] = {
   "some garbageR A 3 0 4",
   "R A 3 0 4"
   };

const char *format = "%*[^PR]%c %c %d %d %d";
ret = sscanf (string[i], format, &l, &q, &k, &m, &n);

For string[1], there is no sequence of characters that match the initial [^PR] specifier. The directive fails with a matching failure (inappropriate input, according to the standard). When that directive fails, sscanf returns with a zero value as no assignments have taken place.

As I read the C Standard, if a match to a directive fails, even if there is assignment suppression, the function terminates at that point. The order of the operations as specified by the C Standard is to match the specifier and convert it to the corresponding type. It then checks for assignment suppression.